Blameless Postmortems

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

Продакшен лежал два часа, клиенты заваливали поддержку, CTO писал злые сообщения в корпоративный чат. Через пару дней — разбор. И тут начинается знакомое: кто задеплоил этот коммит, почему никто не проверил, кто вообще одобрил 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». Последняя секция заставляет посмотреть на риски, которые в этот раз не выстрелили, но могут выстрелить в следующий. База упала ночью, а трафика почти не было? Это не «повезло». Это незакрытый риск, который в пиковый час превратится в полноценный кризис.

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

Постмортем без структуры превращается в часовой пересказ переписки в чате. Структура — единственное, что превращает разбор в инструмент.

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

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

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

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

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

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

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

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

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

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