Что проверять после релиза: первые сутки на проде глазами аналитика

Выкладка прошла ночью, мониторинг зелёный, в чате тишина. К обеду поддержка приносит третье обращение: у части пользователей подписка закрылась на день раньше. Мониторинг говорил, что система работает. Он не говорил, что она делает то, что заказывали.

После выкладки за системой смотрят многие: ошибки, нагрузка, время ответа. Почти никто не смотрит, совпадает ли её поведение с постановкой на настоящих данных. Это последнее место в цепочке, где требование ещё можно сверить с реальностью до того, как расхождение найдут пользователи, — и оно достаётся аналитику просто потому, что больше некому.

Выкладка — ещё не релиз

В речи это одно слово, в работе — два события. Деплой — код на сервере. Релиз — поведение дошло до пользователя. Если их разделяет фича-флаг, первых суток тоже двое, и проверки у них разные.

После выкладки, флаг выключен. Проверяется, что не изменилось ничего. Код лежит на сервере молча, и если поведение всё-таки поменялось — флаг покрывает не всё.
После включения флага. Проверяется, что изменилось ровно то, что описано в постановке, и только у тех, у кого должно.

План проверки пишется заранее

Список того, что смотреть после релиза, составляют не в ночь выкладки, а когда пишутся критерии приёмки. Ночью уже поздно вспоминать, какие данные затронуты и где искать подтверждение.

Что смотреть	Где	Признак, что всё в порядке
Ключевой сценарий по критерию приёмки	Контрольная запись на проде	Поведение совпадает с формулировкой в постановке
Массовый результат	Выборка из базы за первые часы	Нет записей, обработанных по старому правилу
Данные, созданные до релиза	Выборка старых записей	Поведение соответствует решению о старых данных
Нефункциональные требования	Метрики ключевой операции	Время и нагрузка в пределах описанного
Смежные системы	Отчёт, выгрузка, сверка на следующий день	Цифры сходятся с источником

Последняя строка — та, про которую забывают чаще всего. Смежная система часто забирает данные раз в сутки, и расхождение в ней видно только на следующее утро. Первые сутки поэтому и называются сутками, а не первым часом.

Старые данные — главный источник сюрпризов

На тестовом стенде данные свежие и аккуратные. На проде лежат записи, созданные по прошлым правилам, с годами накопленных краевых случаев: незакрытые периоды, ручные правки, поля, которые раньше были необязательными.

В примере с подпиской правило продления поменялось. Вопрос, который обязательно всплывёт: что с подписками, оплаченными до релиза? Продлевать их по новому правилу, по старому или по дате оплаты? Если постановка молчит, это недосказанность, и найдёт её не тестировщик, а первый пользователь со старой подпиской.

Спросите про старые данные на постановке. Одна строка «записи, созданные до релиза, обрабатываются так-то» снимает большую часть сюрпризов первых суток. Если такой строки нет, первым пунктом плана проверки становится выборка старых записей.

Про откат решают до выкладки

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

У аналитика здесь особый вопрос, потому что откат отменяет код, но не данные. Если при выкладке данные уже преобразовали, возврат кода их не вернёт. Обратимо ли изменение — это надо знать до релиза, а не выяснять после.

Если вместо отката делается хотфикс, его правка должна вернуться в постановку. Иначе следующая плановая версия затрёт исправление, и история повторится.

Карточка релиза

Всё это умещается в короткую запись рядом с задачей. Её ведут в течение первых суток, а не пишут по памяти в конце:

РЕЛИЗ 2026-09-24   подписки, REQ-114 ред. 3
  флаг       renewal_from_period_end, включён 09:00
  проверено  09:15  контрольная подписка продлена от даты окончания
             12:00  выборка: продлено 214, по старому правилу 0
             след. день 10:00  отчёт по выручке сходится с биллингом
  старые     оплаченные до 24.09 продлеваются по новому правилу
             (решение владельца продукта, 22.09)
  откат      если есть продления по старому правилу — выключить флаг
  итог       обращений по теме за сутки: 0

Строка «откат» записана до включения флага. Строка «итог» — единственная, которую можно заполнить только в конце.

Предупредите поддержку

Поддержка — датчик, который нельзя поставить никаким мониторингом: она видит, как поведение воспринимают люди. Но работает этот датчик, только если знает, что изменилось.

Иначе первые сутки поддержка отвечает «это ошибка, передали разработчикам» на то, что задумано, а настоящую ошибку не отличает от нового поведения. Короткого сообщения до релиза достаточно: что поменялось, как выглядит правильное новое поведение, куда нести вопросы.

Задача закончена не тогда, когда код выложен, а когда кто-то посмотрел, что он делает с настоящими данными.

Чем заканчиваются первые сутки

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

Каждый сюрприз первых суток оформляется как дефект с видом и ссылкой на требование. Недосказанности среди них — прямой материал для следующей постановки.

Проверка за пятнадцать минут

Вспомните последний релиз и ответьте на три вопроса. Был ли записан план того, что смотреть после выкладки? Кто конкретно смотрел? При каком наблюдении откатывали бы? Там, где ответ «никто» или «не знаю», и стоит начинать.

Что дальше

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