Постмортем без театра: как разбирать инцидент и не плодить мифы

Постмортем без театра: как разбирать инцидент и не плодить мифы

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

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

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

Полезный постмортем всегда заканчивается action items с владельцем и сроком. Иначе через месяц этот документ читают как литературный жанр. Безопасность начинается с доступа, а надежность — с повторяемых улучшений.

Если после разбора у вас остался только «человеческий фактор», значит, вы не докопались до системы. Разбирайте процесс, а не оправдания — так инциденты перестают быть сюрпризом.