Условие

В 03:47 alert: «Conversion упала на 40%». Ты on-call. Что делать в первые 30 минут?

Решение

Минута 0-5: подтвердить инцидент

Открыть дашборд → метрика реально упала, не глитч.
Дублируется ли в других метриках (revenue, transactions)? Если только в conversion — может быть проблема трекинга.
Не сломан ли источник данных (Kafka lag, ETL last_run)?

Минута 5-15: классифицировать

Срочно (Sev1): revenue падает, юзеры жалуются, конкурентный риск. Будить команду.
Подождём до утра (Sev3): ночное затишье, мало транзакций, бизнес не страдает. Документируем, утром разберёмся.

Принять решение быстро, не зависать.

Минута 15-25: диагностика

-- Что упало конкретно
SELECT
  EXTRACT(HOUR FROM ts) AS hour,
  platform, region,
  COUNT(*) AS attempts,
  COUNT(CASE WHEN converted THEN 1 END) / COUNT(*)::float AS conv
FROM events
WHERE ts >= now() - INTERVAL '6 hours'
GROUP BY 1, 2, 3
ORDER BY hour DESC, conv;

Сегменты:

Платформа.
Регион.
Способ оплаты.
Версия билда.

Минута 25-30: первичная гипотеза

Что	Кому писать
Релиз сломан	backend on-call → rollback
ETL врёт	data eng on-call
Платёжный провайдер	payments team
3rd-party API down	вендор support
DDoS / outage	infrastructure

Чек-лист первого часа

Подтвердить, что метрика правда упала (а не дашборд).
Severity (Sev1/2/3).
Сегментация по 3-5 осям.
Status page вендоров проверить.
Slack #incidents канал создать (если Sev1).
Назначить incident commander.
Communicate stakeholders.

Что не делать в 3 ночи

Менять прод без согласования.
Будить весь стафф из-за Sev3.
Без данных запускать «давайте откатим».
Писать в общий канал спекуляции до понимания.

Post-mortem

После incident — blameless post-mortem:

Timeline.
Root cause.
Что сработало в response.
Action items: что улучшить в alerting, runbook, рассказать команде.

Подводные камни

Alerts по фиксированному порогу шумят ночью (низкий трафик = высокая вариативность). Используйте z-score или Prophet.
«Откатил релиз — стало лучше» ≠ root cause; может быть совпадением.
Сначала mitigate (восстановить сервис), потом fix (найти и исправить корень). Не наоборот.
Без timeline нельзя восстановить, что произошло. Логи всех изменений (deploy, config, feature flag) обязательны.
Ложные срабатывания — это плохо: команда перестаёт реагировать на alerts. Калибруйте.

Эталонный ответ

Первые 30 мин: 1) подтвердить, что метрика правда упала (не дашборд). 2) Severity. 3) Сегментация. 4) Status pages вендоров. 5) Первичная гипотеза → нужный on-call. 6) Mitigate сначала, fix потом, post-mortem утром.

Сценарий: внезапная просадка ночью — runbook для on-call