Петля инцидента: от пейджера до постмортема до предотвращения

Полная петля инцидента от начала до конца

Правильно разрешённый production-инцидент выглядит так:

T+0: Срабатывает SLO burn-rate алерт, пейджируя дежурного. Payload алерта содержит: имя сервиса, SLO id, текущую скорость сгорания, временное окно и четыре deeplink’а — RED-дашборд, trace view, отфильтрованный по окну сгорания, profile view, отфильтрованный по тому же окну, runbook.

T+30 с: Дежурный ackует через PagerDuty. Первый deeplink (RED) открывается автоматически.

T+1 мин: Дежурный читает три панели RED и определяет, какой из показателей Rate / Errors / Duration изменился и по какому паттерну (спайк vs дрейф vs плато).

T+1 мин 30 с: Дежурный кликает deeplink трейсов, видит 5–10 репрезентативных медленных или ошибочных трейсов, определяет, в каком сервисе и в каком span’е сосредоточена большая часть задержки.

T+2 мин: Дежурный кликает deeplink профиля (предфильтрованный по trace-id из предыдущего шага), видит flame graph, определяет самый широкий листовой фрейм — функцию, которая поглотила время.

T+2 мин 30 с: git blame на функцию показывает коммит, автора, дату. Сверка с таймлайном деплоев; причина подтверждена.

T+3 мин: Инициирован откат или drafted hotfix.

T+5–10 мин: Скорость сгорания возвращается к baseline. Алерт снимается.

T+1 ч: Создан blameless postmortem-документ с таймлайном и корневой причиной. Пункты действий поданы.

T+1 день: Пункты действий начинают выполняться. Runbook обновлён новым паттерном.

T+1 неделя: Пункты действий выполнены. Следующий инцидент этого класса предотвращён.

Петля воспроизводима. Она ускоряется с практикой. Она не требует героизма.

Пять культурных механизмов

Каждая техническая часть этого юнита окупается только тогда, когда команда имеет следующее.

1. Подписанный error budget policy. Письменное соглашение — подписанное на уровне директора — замораживающее некритические деплои при исчерпании error budget. Без него инженеры всё равно деплоят «на этот раз» и SLO превращается в метрику, на которую никто не реагирует. Policy — это то, что делает SLO реальным контрактом между инженерией и бизнесом.

2. Культура blameless postmortem. Каждый SEV-1 и SEV-2 инцидент порождает постмортем в течение 24–48 часов. Документ фиксирует: таймлайн, корневую причину (системный сбой, не личный) и конкретные пункты действий. Пункты действий отслеживаются и выполняются как продуктовая работа. Без этого те же инциденты повторяются. С этим каждый инцидент делает следующий класс инцидентов либо невозможным, либо быстро диагностируемым.

3. Runbook’и на каждый алерт. Каждый алерт ведёт к runbook’у, за которым закреплён конкретный инженер и который пересматривается ежеквартально. Runbook содержит: что означает алерт, что дежурный должен проверить сначала, какие вероятные причины и как каждую исправить. Дежурный, получивший пейдж в 3 ночи и открывший хороший runbook на повторяющийся инцидент, решает его за несколько минут. Дежурный без runbook’а каждый раз исследует с нуля.

4. Game day’и. Запланированные упражнения, где инженерия инжектирует реалистичный сбой (убивает pod, замедляет downstream, взрывает регион) и наблюдает реакцию дежурного: следует ли воронка? Помог ли runbook? Достаточно ли быстро сработал алерт? Каждый game day порождает обновления runbook’а и улучшения дашборда. Команды, проводящие ежемесячные game day’и, формируют мышечную память, превращающую 3-ночные инциденты в 10-минутные разрешения.

5. Ревью стоимости. Расходы на observability проверяются ежеквартально так же, как проверяются infra-расходы. Каждая команда видит свой объём сигналов, кардинальность и стоимость. Команды, допускающие утечку бюджета, получают инженерное внимание до того, как стать следующей историей в духе Datadog 2021 ($680k → $2M за неделю из-за одной неправильно настроенной метрики).

Все пять механизмов усиливают друг друга: без error budget policy пункты действий постмортема не имеют силы; без runbook’ов game day ничего действенного не выявляет; без ревью стоимости весь стек деградирует до тех пор, пока тулинг больше не поддерживает культуру. Отсутствие хоть одного оставляет брешь, которую остальные не закроют.

Маховик пунктов действий

Пункты действий каждого постмортема — самый ценный reliability-актив org, а не сам инцидент. Паттерн за 12 месяцев:

• Пункты действий, повторяющиеся в нескольких постмортемах, становятся работой над политикой с высоким приоритетом («мы постоянно деплоим схемные изменения без обратной совместимости» → «обратная совместимость теперь обязательна в CI»).
• Выявление паттернов в постмортемах («60% инцидентов из deploy pipeline одной команды») направляет архитектурные инвестиции.
• Процент выполнения пунктов действий становится метрикой здоровья команды — отслеживается на уровне VP, пересматривается ежемесячно.

Org, запускающая этот маховик год, видит: MTTR вдвое (45 → 20 мин), число инцидентов снизилось на 30%, стоимость observability не растёт или снижается несмотря на 2x рост трафика, удовлетворённость команды выросла (меньше пейджей в 3 ночи).