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

Две команды используют одинаковый observability-тулинг. MTTR команды А — 45 минут. Команды Б — 8 минут. Разница не в дашбордах, не в вендоре, не в количестве людей. У команды Б есть культура blameless postmortem, runbook на каждый алерт, подписанный error budget policy и ежемесячные game day’и. Инструменты собирают данные; культура определяет, что с ними делать.

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

Правильно разрешённый 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 за неделю из-за одной неправильно настроенной метрики).

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

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

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

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