Blameless postmortem: разбор инцидентов без поиска виноватых

Почему именно blameless

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

Что даёт отказ от поиска виноватых:

• Честные данные. Если за ошибку наказывают, люди скрывают детали и не сообщают о near-miss. Без честной картины невозможно найти настоящую причину.
• Фокус на системе. «Почему это было возможно?» вместо «кто это сделал?». Первый вопрос ведёт к защите от повторения, второй — к смене стрелочника.
• Доверие. Команда, которую не наказывают за честность, быстрее эскалирует и быстрее учится.

Blameless не означает «без ответственности». Ответственность есть — но коллективная и направленная на исправление системы, а не на наказание исполнителя.

Структура документа постмортема

Хороший постмортем — это документ с предсказуемой структурой, который можно прочитать через год и понять, что произошло:

1. Краткое резюме. Что случилось, кого затронуло, сколько длилось — в 3–4 предложениях.
2. Влияние (impact). Сколько пользователей, какие услуги, потери (время, деньги, репутация).
3. Хронология (timeline). Минута за минутой: когда началось, когда заметили, когда взяли в работу, ключевые действия, когда восстановили. Это самая ценная часть — она вскрывает, где терялось время.
4. Первопричина (root cause). Не «упал сервер», а почему упал и почему это вообще было возможно. Техника «5 почему» помогает дойти до системного уровня.
5. Что сработало / что нет. Честно: где процесс помог, а где мешал.
6. Action items. Конкретные задачи с владельцами и сроками.

Связка с управлением инцидентами прямая: постмортем делают для значимых инцидентов (P1, повторяющиеся), а найденная первопричина уходит в Problem Management.

Как вести разбор

Постмортем — это встреча, и от фасилитации зависит, будет он честным или превратится в трибунал:

• Сроки. Проводить через 1–3 дня после инцидента — пока детали свежи, но эмоции улеглись.
• Состав. Все причастные + фасилитатор, который не был участником инцидента и следит за тоном.
• Язык. «Команда задеплоила без проверки» вместо «Иван задеплоил без проверки». Системные формулировки, не персональные.
• Без «надо было». Задним числом всё очевидно. Разбираем, что человек знал в тот момент, а не что было бы правильно с высоты знания исхода (hindsight bias).
• Факты, потом выводы. Сначала восстанавливаем timeline по логам и фактам, и только потом обсуждаем причины.

Чтобы за разбором следовали изменения

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

• Action items с владельцем и сроком. «Улучшить мониторинг» — не задача. «Добавить алерт на заполнение диска >85%, владелец — Петров, до 15-го» — задача.
• Action items уходят в реестр улучшений. И отслеживаются как любая другая работа, а не теряются в документе.
• Публичность. Постмортемы доступны команде (и часто — пользователям в смягчённом виде). Это и обучение, и сигнал «мы серьёзно относимся к сбоям».
• Метрика follow-up. Доля выполненных action items по постмортемам. Если она низкая — разборы превратились в ритуал без последствий.

Хороший постмортем стоит дорого (час времени нескольких инженеров), но один предотвращённый повторный P1 окупает десяток разборов.