Безвинные постмортемы: превращать аварии в системы, что чинишь, а не в людей, кого винишь

Деплой кладёт checkout на 40 минут. На ретро директор спрашивает «кто его запушил?». Инженер, что зашипил, замолкает, таймлайн вычищается, и отчёт заключает «человеческая ошибка — добавили чеклист деплоя». Шесть недель спустя тот же класс аварии повторяется, потому что настоящая история — CI-гейт, что тихо пропустился на флейки-тесте, конфиг-флаг без покрытия в staging, алерт, что пейджил не ту команду, — так и не попала в комнату. Вина не сделала систему безопаснее. Она сделала следующий инцидент тише.

Почему безвинность — инженерное решение, не просто доброта

Аргумент за безвинность не в том, что люди заслуживают избавления от дискомфорта. Он в том, что вина уничтожает информацию. В момент, когда инженер верит, что ретро охотится за кем-то для наказания, он перестаёт добровольно выдавать детали, что важны: полупонятый воркэраунд, алерт, что замьютил на прошлой неделе, нутряное чувство, что проигнорил под дедлайном. SRE-книга Google излагает предпосылку прямо — безвинный постмортем «предполагает, что все вовлечённые в инцидент имели добрые намерения и делали правильное с информацией, что у них была». John Allspaw из Etsy формулирует ту же идею как справедливую культуру (just culture): ты трактуешь инцидент «как источник данных, не что-то стыдное, от чего надо шарахаться».

Механизм прост и жесток. Накажи гонца — и натренируешь лучших инженеров молчать о риске. Данные всплывают не как меньше инцидентов, а как меньше отчётных инцидентов — пока один, что не спрятать, не кладёт checkout. Сеньор читает подозрительно чистую историю инцидентов как запах, не трофей: обычно это значит, что организация загнала отказ в подполье, а не вон из системы.

Структура: таймлайн, импакт, способствующие факторы, action items

Постмортем, что окупает свою цену, имеет четыре несущих секции. Таймлайн — нейтральный, с временными метками отчёт — детект, эскалация, митигация, восстановление — написанный в прошедшем времени без прилагательных о компетентности. Импакт квантифицирует радиус поражения: минуты простоя, проваленные запросы, затронутые клиенты, сожжённая выручка или бюджет SLO. Размытый импакт («некоторые пользователи видели ошибки») — это как авария получает заниженный приоритет, а фикс так и не получает людей.

Третья секция — где безвинность и наивная практика расходятся: способствующие факторы, во множественном, не «корневая причина». Руководство Google — два-пять системных причин: брешь процесса, ограничение тулинга, недостающий тест, неверно смаршрутизированный алерт, дыра в документации — каждая сформулирована как свойство системы, не человека. Четвёртая секция, action items, — единственная часть, что меняет будущее. Каждый пункт должен быть конкретным, иметь единственного именованного владельца и нести срок; action item без владельца — это пожелание.

Почему «5 почему» и единственная корневая причина — неверная модель

Народный метод — «5 почему»: спроси «почему» пять раз и дойдёшь до той самой корневой причины. Для сложных систем это активно вводит в заблуждение. Эссе Allspaw The Infinite Hows — опираясь на Sidney Dekker и Nancy Leveson — доказывает, что спрашивать «почему» раз за разом тащит тебя к единственной линейной цепи, ретроспективному искажению и в итоге вине, потому что каждое «почему» требует оправдания, а оправдания указывают на людей. Реальные аварии многопричинны: деплой, флейки-тест, что дал гейту пропуститься, конфиг-флаг без покрытия в staging и неверный маршрут алерта — все должны были выстроиться в ряд. Ни один в одиночку не «вызвал» это; вызвало их взаимодействие.

Рефрейм Allspaw — спрашивать «как» вместо «почему» — бесконечные как. Вопросы «как» поднимают условия, что сделали действие разумным на тот момент, скрытое экспертное знание, что люди использовали, трейдоффы эффективность-против-тщательности, в которых они лавировали под давлением. Сдвиг от «почему ты это сделал?» к «как это действие имело смысл при том, что ты знал?» — разница между допросом и расследованием. Ты не можешь починить человека; ты можешь починить систему, что сделала опасный путь лёгким.

Трейдофф сеньора: ретро стоят времени и окупаются, только если пункты шипятся

Тщательный постмортем дорог: часы времени инженеров на написание таймлайна, кросс-командная ревью-встреча, трекинг последующих действий. Эта цена оправдана, только если action items реально делаются — и индустриальные данные тут мрачны. Отчётные нормы ставят выполнение action items ниже 50%, у многих команд под 40% выполнено за 90 дней, а частота повторных инцидентов приземляется около 35–50%. Когда пункты написаны и подшиты с нулевым доведением до конца, ты заплатил полную цену ретро и купил ничего: та же авария повторяется, и теперь твои инженеры ещё и верят, что постмортемы — театр.

Так что ход сеньора — нормировать церемонию и защищать доведение до конца. Не каждый сбой заслуживает полного постмортема — команды ставят триггер по severity (нарушение SLO, видимый клиенту простой дольше N минут, sev1/sev2). SRE-воркбук Google рекомендует публиковать быстро (цель — под 48 часов, пока память свежа) и трекать action items до закрытия как любую другую приоритизированную работу, с проверками на 30/60/90 дней и целью выполнения заметно выше 85%. Документ постмортема — дешёвая часть; дорогая, ценная часть — работа, на которую он тебя обязывает.