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

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

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

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

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

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

Автоматизация — это не опция, а необходимость: если после инцидента не изменился чек-лист, мониторинг или процесс выкладки, значит, инцидент просто записали, но не разобрали.