<b>Постмортем без воды: как разбирать инцидент, чтобы он не повторился</b>

<b>Постмортем без воды: как разбирать инцидент, чтобы он не повторился</b>

Постмортем — это не отчет для галочки, а инструмент снижения повторных отказов. Если после инцидента остались только виноватые и туманное «надо внимательнее», значит разбор провалился.

Структура рабочего разбора простая:
— таймлайн: что произошло и в каком порядке;
— триггер и цепочка отказов, а не один «корневой баг»;
— impact: кого задело, что сломалось, где был запас прочности;
— detection: как инцидент был замечен и почему не раньше.

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

В финале нужны конкретные action items с владельцем и сроком: убрать ручной шаг, добавить проверку, пересобрать алерт, обновить runbook, прогнать сценарий в тесте. Без этого постмортем превращается в литературный жанр. Мониторинг должен быть проактивным, а не реактивным.