Юнит-дампики
(фишечка из старенького)

Одним из ключевых вопросов техподдержки является стабильный алгоритм воспроизведение бага, который надо передать разработчикам.

У кого-то это получается, у кого-то нет, а в некоторых случаях разработчики вообще встраивают в систему фундаментальную систему всеобъемлющих логов, по которым можно восстановить все действия пользователей, - удовольствие недешёвое, но полезное. Если команда упоролась, эта система логов ещё обладает возможностью откатывать действия, - фундаментально более дорогая разработка. Все эти варианты требуют постоянной ручной подпилки. Эдакий налог на разработку любого экшна в системе.

Одной из относительно дешёвых разработок, позволяющих помочь в воспроизведении проблемы является точечный дамп, извлекающие данные только одного пользователя и всех его артефактов.

Основной кейс использования дампов, - в дебаге системы на одном конкретно взятом пользователей. Чтобы его взять, очень удобно иметь инструмент по дампу его на продакшне и загрузке на тестовый стенд.

При поиске проблемы берём дамп пользователя, переносим его на стенд и далее играемся с ним на стенде до тех пор, пока не воспроизведём и исправим баг.

Как построить такую систему? Самый дешёвый способ, взять sql дамп вообще всей БД (обычно они очень тяжёлые) и тупо погрепать по колонке с user_id. Функционально такой греп можно запустить мгновенно (лучше всё же zgrep, чтобы не распаковывать дамп), хотя и работать он будет много минут, дав в результате sql юнит-дамп

На таких "грепах" можно выстроить небольшой mvp для дампа/загрузки на продакшн-тест-стейдж-дев средах, а позже, если такая система себя оправдает, можно запланировать полноценный функционал по работе с дампами, к которой уже прикручивать обезличивание дампов, архивирование, версионирование и тд и тп.

В геймдеве таким балуются при подготовке перед бета-тестированием новых сложных фичей в pvp с десятком VIP пользователей, выявляя порой самые неожиданные баги.

> не все мыслят генериками

правильно! переписывать один и тот же код под разные типы - это не только приятно, но еще и поддерживаемо!

> и аннотациями

То-то библиотека JSON не пыхтит, пытаясь уместить метаданные в struct tags

В пыхах и питонах есть catch / except, который позволяет перехватить ошибку только когда надо и какую надо, так что, пожалуйста, не надо тут. Одно может полностью эмулировать другое, а вот го подход без проверки ошибок - нет.

Какой-то прям радикально сложный способ написать select * where user_id=@whatever. Зачем такое делать через, спаси яхве элохимович, дамп всей зеттабайтной базы, например, гугеля или NSA, или других 3х буквенных контор под обсчим названием ХВЗ(Хочу Всё Знать)? Это ж прям как правым задним дальним тентаклем левый джагон через боцманский загиб сквозь wormhole чесать какой-то. Мы на нашем Нибиру такое не понимать, у нас 15ти половый секас попроще

> У кого-то это получается, у кого-то нет, а в некоторых случаях разработчики вообще встраивают в систему фундаментальную систему всеобъемлющих логов, по которым можно восстановить все действия пользователей, - удовольствие недешёвое, но полезное. Если команда упоролась, эта система логов ещё обладает возможностью откатывать действия, - фундаментально более дорогая разработка. Все эти варианты требуют постоянной ручной подпилки. Эдакий налог на разработку любого экшна в системе.

Ну вообще-то с event sourcing жизнь наоборот становится гораздо проще и отлаживаемей, если только нет кроссс-энтити транзакций. И дампать для воспроизведения надо всего ничего, если вообще надо - там все в структуре ивента видно будет.

Так-то оно конечно да, но Тебе ж надо двумя-тремя командами перекинуть всю инфу из продакшна на тестовый стенд.

Ну так селекты да инсерты ж. Я реально не понимаю за что такая сложность с дампом. Прям фантазии не хватает, в каком случае такое может быть проще

Ну вот извлеки пользователя с продакшна, перетащи его на тестовый стенд, внеси изменения и перетащи эти изменения обратно в продакшн. Причём сделай это не сам, а тремя джунами. 1й джун стаскивает дамп, 2й исправляет, 3й заправляет обратно.

И засеки время.

Я имею в виду все-все-все метаданные из всех таблиц по одному пользователю.

Данные по таймингу давай сюда, - посмотрим.

Учти здесь время на то, сколько джуны будут собирать просто список таблиц, где хранятся данные по пользователю. И как их апдейтить.

По что ж так джунов тиранить? Ещё скажи, свеженьких, только пришедших

Примерно 1-30 минут на всё, в зависимости от размера ящика. НО ЗАЧЕМ??? ЧТОБЫ ЧТО?

Чтобы ковыряться в проблеме не на проде

Это лишено смысла.

говорю вам, ивент сорсинг проблем суть всех решение

Если вам, чтобы ковыряться с юзером, надо мигрировать его профайл - дело плохо

Ты помнишь, чем закончился один Твой отпуск, когда на проде для исправления проблемы поменяли префиксы ключей на кластере мемкешевом? Сколько кеш потом прогревался?

Это потому, что техдир был некомпетентным идиотои-хипстером.

Ты был тогда техдиром.