Как проводить постмортем после инцидента

Цель и принципы

Постмортем — это системный, blameless-анализ инцидента с целью понять, что произошло, почему, как уменьшить вероятность повторения и проверить, что исправления работают. Основные принципы: фокус на фактах (данные>мнения), отсутствие обвинений, конкретные корректирующие действия с владельцами и сроками.

Подготовка

1. Собрать артефакты: алерты, метрики (SLI/SLO), логи, трассы, конфигурации, релиз-хэши, скриншоты, записи on-call-чата, команды, выполненные в процессе.

2. Зафиксировать timeline — точное время срабатывания, ответов, mitigation, восстановления. Хронологию восстанавливать по временным меткам (UTC) и correlation/trace IDs.

3. Назначить фасилитатора/модератора постмортема (не necessarily IC) и ответственного за документ.

Проведение сессии

• Открыть сессию в формате blameless: цель — улучшение процессов и систем.

• Пройти по timeline: кто что видел и делал, какие гипотезы проверяли, какие данные собрали. Запись всех фактов и временных меток.

• Проверить SLI/SLO: произошло ли нарушение, каков был импакт (пользователи, деньги, данные).

• Идентифицировать root cause и contributing factors с помощью методов RCA.

Методы анализа причин

• 5 Whys — быстро выявляет цепочку причин («почему это случилось?» ×5). Хорош для простых инцидентов.

• Fishbone (Ishikawa) — структурирует возможные факторы (people, process, tools, environment, code, config).

• Causal factor charting / timeline analysis — строит событие→событие диаграмму, помогает отделить первопричину от вторичных эффектов.

• Post-incident hypothesis testing — формулируются гипотезы и проверяются данными (логи, трассы, метрики).

Формирование action items

Каждое исправление должно быть SMART:

• что сделать (коротко),

• владелец (имя/команда),

• критерий успеха / как проверить (verification step),

• срок (deadline),

• приоритет.
  Примеры: «Добавить alert на burn-rate >X с дедупликацией»; «Автоматизировать rollback для deployment → тест: имитировать фейл и проверить откат».

Структура постмортем-документа (рекомендация)

• Заголовок + дата + incident id

• Краткая сводка (what happened — 1 абзац)

• Timeline (timestamped events)

• Impact (пользователи, SLO, финансово)

• Root cause и contributing factors

• Action items (таблица: action / owner / deadline / verification)

• Lessons learned (процессы, monitoring gaps, runbooks)

• Attachments (queries, логи, dash, chat transcript)

Валидация и follow-up

• После реализации действий — обязательно проверить (test restore, load test, индикаторы) и пометить action как «verified».

• Планировать ретроспективу через 2–4 недели для оценки эффективности изменений.

• Автоматизировать те исправления, которые можно (alert → auto-mitigate, health checks, CI safety gates).

Коммуникация

• Публикация в общем доступном месте (wiki, repo, Confluence) с открытым доступом для заинтересованных сторон.

• Короткое уведомление для внешних стейкхолдеров/пользователей при значимом влиянии (status page + changelog).

Что нельзя делать

• Оставлять действия без владельцев/сроков.

• Делать «общее» действие типа «улучшить надежность» без конкретики.

• Игнорировать верификацию — закрытый action без проверки бесполезен.

• Искать виновных — это подрывает культуру тревоги и мешает честному разбору.

Метрики эффективности постмортемов

• % действий, закрытых с верификацией;

• снижение сходных инцидентов;

• улучшение MTTR/MTTA;

• уменьшение burn-rate при релизах.

Постмортем — это цикл: инцидент → анализ → действия → проверка → обновлённые процессы. Чем быстрее и конкретнее команда превращает выводы в проверяемые изменения, тем ценнее постмортем для надёжности системы.