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

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

Инцидент — это не повод искать виноватого. Это повод собрать факты, восстановить цепочку событий и зафиксировать, где система дала сбой: в коде, конфиге, доступах или процессе. Если разбор превращается в обмен догадками, он быстро деградирует до ритуала для отчёта, а прод не становится стабильнее.

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

Полезно сразу отделять причину от триггера. Триггер — это падение сервиса, переполнение диска, истёкший сертификат. Причина — отсутствие алерта, неверный лимит, ручной деплой без проверки, слабая схема отката. Если пишете только про триггер, вы лечите симптом и оставляете багу место для возвращения.

Фиксируйте не только технические детали, но и процесс: кто принял решение, сколько занял детект, был ли runbook, где потерялась коммуникация. Для каждого пункта нужен конкретный action item: владелец, срок, критерий готовности. Иначе постмортем живёт дольше инцидента, но пользы от него столько же, сколько от пустого графика в дашборде.

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