Blameless Postmortems

Инцидент произошёл — что дальше

У вас упал продакшен на два часа, клиенты писали в поддержку, CTO нервничал в Slack. Через пару дней вы собираетесь на разбор инцидента — и тут начинается: кто задеплоил этот коммит, почему никто не проверил, кто вообще одобрил этот PR. Инженер, который внёс изменение, чувствует себя на скамье подсудимых. В следующий раз он будет деплоить реже, вносить изменения меньшего размера не потому, что так лучше, а потому что так безопаснее лично для него. Или вообще перестанет брать на себя рискованные задачи. Вы получите команду, которая боится деплоить, и это гораздо хуже, чем один двухчасовой аутейдж.

John Allspaw, бывший CTO Etsy, в 2012 году описал подход, который Etsy практиковал к тому моменту несколько лет: blameless postmortems. Ключевая идея — инженер, чьи действия привели к инциденту, остаётся «on the hook», но за другое. Его задача — подробно рассказать, что он видел, что думал в тот момент, почему принял те решения, которые принял. Его не наказывают за ошибку, но и не отпускают домой с чистой совестью — он помогает всей команде понять, как система допустила сбой.

Что значит «blameless» на практике

Blameless — означает, что вы убираете из разбора вопрос «кто виноват» и заменяете его вопросом «какие условия в системе сделали эту ошибку возможной». Это разные вопросы с разными последствиями. Первый заканчивается наказанием одного человека. Второй заканчивается изменениями в системе, которые снижают вероятность повторения для всех.

Allspaw ссылается на концепцию Just Culture из авиации и медицины: баланс между безопасностью и ответственностью. В авиации пилоты обязаны сообщать об ошибках и near-misses без страха наказания, потому что альтернатива — пилоты скрывают ошибки, и следующий инцидент становится катастрофой. В разработке ПО ставки ниже, но механизм тот же: если инженеры боятся признавать ошибки, вы перестаёте получать информацию о том, что происходит в вашей системе.

Google в книге Site Reliability Engineering формализовал подход дальше. Их постмортем-шаблон включает секции «What went well», «What went badly» и — ключевой пункт — «Where we got lucky». Последняя секция заставляет команду думать о рисках, которые не реализовались в этот раз, но могут реализоваться в следующий. Если ваша база упала, но при этом случайно оказалось, что в тот момент был низкий трафик — это не «повезло», это незакрытый риск, который в пиковый час превратится в полноценный кризис.

Как проводить разбор

Постмортем работает, когда у него есть структура. Без структуры он превращается в часовой пересказ Slack-переписки.

Начните с таймлайна. Восстановите хронологию событий с точностью до минут: когда появился первый сигнал, кто его увидел, какие действия предпринял, когда эскалировал, когда нашли причину, когда починили. Таймлайн — это фундамент разбора, без него все будут вспоминать разные версии событий.

Дальше — контекст решений. Для каждого ключевого решения в таймлайне задайте вопрос: что этот человек знал в тот момент? Часто в ретроспективе кажется очевидным, что нужно было откатить деплой, но в момент инцидента инженер видел противоречивые метрики и обоснованно решил, что проблема в другом. Etsy выпустила целое «Debriefing Facilitation Guide» — руководство для фасилитаторов, где описаны техники вытаскивания этого контекста из участников.

Завершите action items. Google настаивает на конкретных формулировках: каждый action item должен быть actionable, specific и bounded. «Улучшить мониторинг» — плохой action item. «Добавить алерт на рост error rate выше 5% в сервисе X с порогом срабатывания 2 минуты, владелец: Петя, срок: 15 апреля» — хороший. Минимум один action item должен быть P0 или P1, и у каждого должен быть владелец.

Что делать с результатами

Постмортем, который написали и положили в Confluence, где его никто не прочтёт — пустая трата времени. Google рассылает постмортемы на широкую инженерную рассылку. Etsy публикует их внутри компании открыто. Nora Jones, основательница Jeli (позже приобретённой PagerDuty), построила целую платформу вокруг идеи, что ценность постмортема — в паттернах, которые проявляются при анализе множества инцидентов, а не одного. Когда вы видите, что за квартал три инцидента произошли из-за отсутствия canary-деплоя в одном и том же сервисе, у вас появляется аргумент для приоритизации этой работы, подкреплённый данными.

Google использует стандартизированный шаблон постмортема ещё и для трендового анализа: когда корневые причины и триггеры записаны в единообразном формате, можно агрегировать данные и выявлять системные проблемы — например, что 40% инцидентов за полгода связаны с конфигурационными изменениями, а значит, пора вкладываться в инфраструктуру config-as-code.

Типичные ошибки

Самая частая: blameless на словах, blame на деле. Формально никого не наказывают, но тон встречи, взгляды руководства, последующие решения о распределении задач — всё сигнализирует команде, что ошибка запомнена и будет стоить карьерных очков. Blameless culture — это культура, а культура строится годами и разрушается одним неосторожным комментарием менеджера.

Вторая ошибка: фокус на «root cause». Сложные системы редко ломаются по одной причине. Обычно к инциденту приводит стечение нескольких факторов: изменение в коде, совпавшее с пиком нагрузки, совпавшее с тем, что дежурный инженер был на созвоне и заметил алерт на 15 минут позже. Поиск единственной «корневой причины» — упрощение, которое маскирует системные проблемы. Learning from Incidents community продвигает подход «contributing factors» — перечень условий, каждое из которых по отдельности было бы безобидным, но вместе создали инцидент.

Третья ошибка: action items без follow-up. По данным Google, action items из постмортемов исполняются стабильно только когда за ними закреплён владелец, установлен срок и есть процесс проверки. Без этого через месяц половина пунктов будет забыта, и следующий аналогичный инцидент произойдёт ровно по тому же сценарию. Невыполненные action items превращаются в toil — ручную повторяющуюся работу, которая съедает инженерное время.