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

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

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

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

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

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

После инцидента задайте один вопрос: «Что должно было сработать раньше?» Если ответа нет, значит, разбор еще не закончен.