Пост-инцидентные разборы

1) Зачем нужны пост-инцидентные разборы

Пост-инцидентный разбор (post-mortem / AAR) — это структурированный процесс обучения организации после сбоя. Цель — не поиск виноватых, а выявление корневых и способствующих причин и закрепление измеримых действий (CAPA), которые снижают риск повторения и стоимость инцидентов, улучшая SLO, MTTR и доверие клиентов/регуляторов.

2) Принципы (Just Culture)

Без обвинений: анализируем системы, решения и контекст, а не персоналии.
Факты важнее мнений: таймлайн, логи, метрики, трейсы, артефакты изменений.
E2E-взгляд: от симптомов на клиенте до внутренних зависимостей и внешних провайдеров.
Проверяемость: каждая гипотеза подтверждается экспериментом/данными.
Замыкание цикла: разбор → CAPA → контрольные точки → ретест.

3) Когда запускать разбор и какие бывают форматы

Обязательный: SEV-0/1; нарушение SLA/регуляторных требований; утечка данных; значимый PR-риск.
Ускоренный (light): SEV-2 с заметным влиянием или повторяющимися симптомами.
Коммуникационный AAR: если сбой затронул статус-страницу/поддержку, проверяем SLAs апдейтов и качество сообщений.

Сроки: черновик за 48–72 часа, финальная версия — до 5 рабочих дней (если не оговорено иначе).

4) Роли и ответственность

Владелец разбора (RCA Lead): организует процесс, ведет встречу, отвечает за качество отчета и CAPA.
Incident Commander (IC): предоставляет фактологию инцидента и решения.
Tech Leads (по системам): анализ причин, подтверждающие артефакты.
Comms/Support/Legal: оценка коммуникаций и требований комплаенса.
Scribe: протокол, сбор доказательств, соблюдение структуры.
Стейкхолдеры продукта/бизнеса: влияние на клиентов/оборот, приоритизация CAPA.

5) Подготовка: что собрать до встречи

Таймлайн (UTC): T0 обнаружение → Tn восстановление; релизы/фич-флаги/конфиги, статус провайдеров.
Данные наблюдаемости: графики SLI/SLO, error-rate, перцентили, логи, трассировки, скриншоты.
Контекст изменений: ссылки на PR/деплой, миграции БД, фич-флаги, планы работ.
Импакт: затронутые когорты/регионы/провайдеры, минуты простоя, кредиты по SLA.
Коммуникации: черновики/посты на статус-странице, ответы саппорта, внутренние анонсы.
Политики/плейбуки: что должно было произойти по процессу, где были отклонения.

6) Методики анализа (выберите комбинацию)

5 Why: быстрое вскрытие причинной цепочки (риск — чрезмерное упрощение).
Диаграмма Исикавы (Fishbone): People / Process / Platform / Policy / Partner / Product.
Fault Tree Analysis (FTA): дедукция от события к множеству причин (AND/OR).
Change Analysis: что изменилось в период инцидента vs стабильное состояние.
Causal Graph: граф причинно-следственных связей для сложных микросервисов и внешних зависимостей.
Human Factors Review: усталость, информационный шум, неактуальные runbook’и.

7) Структура отчета (шаблон)

1. Резюме (Executive Summary): что, когда, на кого повлияло, итоговый статус.
2. Импакт: SLI/SLO, пользователи, регионы/провайдеры, мин. простоя, финансовые/регуляторные эффекты.
3. Таймлайн (UTC): ключевые события, релизы, решения IC, коммуникации.
4. Наблюдения и данные: графики, логи, трейсы, диффы конфигов/схем.
5. Гипотезы и проверки: принятые/отвергнутые, ссылки на эксперименты/симуляции.
6. Корневые причины: системные/процессные/технические (ясные формулировки).
7. Способствующие факторы: почему не заметили/не остановили раньше.
8. Что сработало / что не сработало: процессы, инструменты, люди.
9. CAPA: корректирующие и предупреждающие меры с владельцами/сроками/метриками успеха.
10. План верификации: контрольные точки D+14/D+30, критерии закрытия.
11. Версии для внешних сторон: клиентская/регуляторная (без чувствительных данных).
12. Приложения: артефакты, ссылки на тикеты/PR, скриншоты дашбордов.

8) CAPA: как сделать действия рабочими

Каждое действие имеет владельца, дедлайн и KPI эффекта (например, снижение change-failure-rate на X%, нулевой повтор 90 дней, уменьшение burn-rate в пиках).
Разделяйте Corrective (исправить) и Preventive (не допустить) меры.
Привязывайте к policy-as-code: алерты, SLO-гейты, автоскейл/лимиты, GitOps.
CAPA попадает в публичный бэклог с обзорами на еженедельных операционных встречах.

9) Проверка эффекта и закрытие

Контрольные точки: D+7 (промежуточно), D+14/D+30 (основные), D+90 (итог).
Верификация: тесты/симуляции (game day), shadow-трафик, наблюдаемость (стабильные SLI в зеленой зоне), отсутствие рецидивов.
Закрытие возможено только при выполненных CAPA и подтвержденных метриках.

10) Коммуникации и комплаенс

Внутренние: понятный статус для продуктовых/поддержки/менеджмента, SLA апдейтов соблюдены.
Внешние: статус-страница, рассылки клиентам/партнерам; язык без обвинений, четкий план предотвращения.
Регуляторика: сроки уведомлений, деперсонализация примеров, неизменяемое хранение отчетов и артефактов.

11) Метрики зрелости процесса

Время публикации отчета: факт vs SLA (например, ≤5 рабочих дней).
CAPA completion rate: % действий, закрытых в срок.
Reopen rate: доля инцидентов-повторов за 90 дней.
Доля системных причин vs “человеческая ошибка”.
Алерт-гигиена: снижение ложных пейджей, рост покрытых runbook’ами алертов.
Изменение DORA-метрик: MTTR, change-failure-rate до/после.

12) Чек-листы

Перед разбором

• Определен владелец RCA и состав участников.
• Собран таймлайн и артефакты (логи/графики/релизы/флаги).
• Оценен импакт по когортам/региону/провайдерам.
• Подготовлены черновики разделов “Импакт” и “Таймлайн”.
• Релевантные политики/плейбуки сопоставлены с фактическими действиями.

Во время

• Зафиксированы принятые/отклоненные гипотезы и основания.
• Определены корневые и способствующие причины.
• Сформирован CAPA-план с KPI и сроками.
• Согласованы версии отчета для внешних сторон (при необходимости).

После

• Отчет опубликован в срок, доступ по ролям.
• CAPA занесены в бэклог, владельцы подтверждены.
• Назначены контрольные точки и мини-симуляция для проверки.
• Обновлены runbook/SOP/алерты/документация.

13) Анти-паттерны

“Виноват человек X” — без системных причин → повтор.
Отчет без CAPA или без владельцев/сроков — бумага ради бумаги.
Нет фактов/артефактов — выводы на ощущениях.
Слишком общий язык (“перегрузка БД”) без конкретных изменений.
Игнорирование коммуникаций и комплаенса — репутационные риски.
Закрытие без проверки эффектов — рецидивы спустя недели.

14) Мини-шаблоны

Шапка отчета

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

Формулировка корневой причины (пример)

CAPA (фрагмент)

Включить canary-маршрутизацию к PSP-A (1%→5%→25%), владелец: @payments-tl, до: 2025-11-07, KPI: нулевые P1 инциденты при релизах провайдеров 30 дней.
Перенастроить таймауты/ретраи с общим временем ≤ SLA 800 мс, владелец: @platform-sre, до: 2025-11-05, KPI: p99<600 мс под нагрузкой N.
Добавить бизнес-SLI по BIN-когортам, владелец: @data-lead, до: 2025-11-10, KPI: детекция деградаций < 5 мин.

15) Встраивание в ежедневную практику

Еженедельные RCA-ревью: статус CAPA, новые уроки, обновления процессов.
Каталог пост-мортемов в wiki с тегами (сервис, SEV, причины) и поиском.
Симуляции по мотивам инцидента через 2–4 недели для проверки мер.
Включение уроков в онбординг on-call и обновление учебных сценариев.

16) Итог

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