Плохой разбор инцидента ищет виноватого. Нормальный — восстанавливает цепочку событий: что сломалось, где сработал отказ, почему автоматика не остановила распространение. Без этого постмортем превращается в ритуал для галочки, а прод не становится устойчивее.
В хорошем отчете должны быть 4 блока: — таймлайн с фактами, без интерпретаций; — пользовательский и системный эффект; — первопричина и условия, которые сделали сбой возможным; — список действий с владельцами и сроками. Если в документе есть только «исправили», это не постмортем, а заметка в таск-трекере.
Отдельно фиксируйте, что не сработало: мониторинг, алертинг, rollback, лимиты, runbook, права доступа. Код работает, но есть нюансы: один и тот же баг часто возвращается не из-за логики, а из-за дыр в процессе. Поэтому в разборе полезно писать не только «почему упало», но и «почему это не поймали раньше».
Финальный критерий полезного постмортема простой: после него должен измениться чек-лист эксплуатации, а не настроение команды. Автоматизация — это не опция, а необходимость. Если выводы не превращаются в действия, значит инцидент уже забыли, просто в красивой обертке.
Трекер: конфиги
@tracker_configs_arb
Постмортем без театра: как разбирать инцидент так, чтобы он не повторился
Этот пост опубликован в Telegram-канале Трекер: конфиги. Подписаться можно по ссылке: @tracker_configs_arb.