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

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

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

Нормальный постмортем отвечает на 4 вопроса:
— какой был симптом и как его заметили;
— какой был корень проблемы, а не триггер;
— почему мониторинг, алерты или процессы не сработали раньше;
— какие изменения закрывают класс отказа, а не один частный случай.

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

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

Если после инцидента нет изменений в автоматизации, наблюдаемости или доступах — значит, инцидент еще не разобран.