Привет, Хабр!

Blameless post‑mortem — подход к разбору инцидентов, при котором фокус смещается с вопроса «Кто виноват?» на вопрос «Что в системе позволило инциденту произойти?». Не потому что Вася не виноват (может, и виноват). А потому что наказание Васи не предотвращает следующий инцидент, а изменение системы — предотвращает.

Подход пришёл из авиации, где после каждой катастрофы расследование ведётся не для наказания пилота, а для изменения процедур, конструкции самолёта и правил полётов.

Почему blame не работает: три механизма

1. Эффект замалчивания. Если за ошибку наказывают, люди перестают сообщать об ошибках. Не перестают ошибаться — перестают сообщать. Инцидент, о котором узнали через 5 минут, стоит $500. Инцидент, о котором узнали через 5 часов (потому что Вася боялся признаться), стоит $50 000.

2. Hindsight bias. После инцидента причина кажется очевидной. «Ну конечно нельзя было деплоить в пятницу вечером!». Но в момент принятия решения у Васи была информация X (тикет с пометкой «критично», просьба от бизнеса, успешный прогон на стейджинге). С учётом информации, доступной в тот момент, решение выглядело разумно. Оценивать решение с позиции знания результата — фундаментальная ошибка рассуждения.

3. Proximate vs root cause. «Вася задеплоил баг» — ближайшая причина (proximate cause). Но почему Вася мог задеплоить баг? Потому что CI‑пайплайн не содержит интеграционных тестов. Почему? Потому что тестовое окружение нестабильно. Почему? Потому что на него нет бюджета. Ближайшая причина всегда находится в человеке, но фундаментальная причина заключается почти всегда в процессе, инструменте или организационном решении.

Формат: что должно быть в post‑mortem документе

Конкретных шаблонов десятки, но все рабочие post‑mortem содержат пять блоков:

• Таймлайн. Хронология событий с точными временами. Не «утром произошёл сбой», а «09:12 UTC — алерт, 09:15 — дежурный подключился, 09:23 — определили, что проблема в сервисе X, 09:41 — откат деплоя, 09:47 — сервис восстановлен». Точный таймлайн — фундамент разбора. Без него обсуждение превращается в спор воспоминаний.

• Влияние (impact). Что именно сломалось и для кого. «5200 пользователей не могли оформить заказ в течение 35 минут. Расчётные потери — 420 заказов на сумму ~1.2 млн руб.». Без цифр влияние непонятно, и приоритет исправлений не определить.

• Корневая причина и contributing factors. Не одна причина, а цепочка. Инцидент — всегда комбинация факторов, каждый из которых по отдельности был бы безвреден. «Конфиг содержал ошибку (фактор 1) + ревью конфига не проводится (фактор 2) + canary deployment не настроен (фактор 3) + алерт на error rate сработал с задержкой 12 минут (фактор 4)». Каждый фактор — потенциальная точка улучшения.

• Action items. Конкретные задачи с ответственными и сроками. Не «улучшить мониторинг», а «настроить алерт на error rate > 5% с порогом 2 минуты, ответственный — Петров, срок — 15 апреля». Action item без ответственного и срока — это пожелание, а не задача.

• Lessons learned. Что команда узнала нового. «Мы обнаружили, что наш canary deployment проверяет только HTTP 200, но не проверяет бизнес‑метрики (конверсию, среднее время ответа). Баг прошёл canary, потому что эндпоинт отвечал 200, но с неправильными данными».

Проведение встречи: как не скатиться в blame

Модератор встречи — не руководитель и не участник инцидента. Его задача — удерживать фокус на системе, а не на людях. Несколько конкретных приёмов.

Говорим «мы», а не «ты/он». Не «Вася задеплоил без тестов». А «деплой произошёл без прогона интеграционных тестов». Субъект — действие, а не человек. Это не политкорректность,а переключение фокуса с наказания на предотвращение.

Вопросы направлены на систему. Не «почему ты не проверил?», а «что мешало проверке?», «какой информации не хватало?», «какой инструмент мог бы поймать это автоматически?».

Five Whys, но аккуратно. Классическая техника «5 почему» работает, но с оговоркой: цепочка должна останавливаться на уровне системы, а не на уровне «потому что Вася невнимательный». «Невнимательный» — не причина, это следствие: длинная смена, отсутствие чеклиста, усталость после третьего инцидента за неделю.

Участвуют все, кто был вовлечён. Включая тех, кто допустил ошибку. Особенно тех, кто допустил ошибку — у них самая ценная информация о контексте решений. Если человек боится прийти на post‑mortem, культура blameless ещё не работает.

Action items: что отличает рабочие от бесполезных

Большинство post‑mortem генерируют action items, которые никогда не выполняются. «Улучшить процесс code review» — висит в Jira полгода, потому что непонятно, что конкретно делать.

Рабочий action item отвечает на четыре вопроса: что именно (конкретное действие), кто (один ответственный, не «команда»), когда (дата, не «скоро»), как проверить (критерий завершения).

Плохо: «Улучшить мониторинг». Хорошо: «Добавить алерт в Grafana: если error_rate в сервисе orders превышает 5% в течение 2 минут, отправить в #alerts и PagerDuty. Ответственный: Иванов. Срок: 21 марта. Проверка: прогнать chaos test и убедиться, что алерт срабатывает в течение 3 минут».

Плохо: «Написать тесты». Хорошо: «Добавить интеграционный тест на сценарий „оплата при недоступности платёжного шлюза“ в CI‑пайплайн сервиса checkout. Тест должен блокировать деплой при падении. Ответственный: Смирнова. Срок: 28 марта».

Action items делятся на три категории по характеру:

Detect — обнаружить быстрее. Алерты, метрики, health checks. «Чтобы в следующий раз мы узнали за 2 минуты, а не за 15».

Mitigate — уменьшить ущерб. Canary deployment, feature flags, circuit breakers, автоматический откат. «Чтобы в следующий раз пострадали 1% пользователей, а не 100%».

Prevent — предотвратить. Тесты, валидация конфигов, автоматические проверки. «Чтобы в следующий раз баг не дошёл до прода».

Баланс между тремя категориями — база для зрелого подхода. Только «prevent» — утопия (все баги предотвратить невозможно). Только «detect» — пожарная команда (быстро тушим, но всё время горит). Зрелая команда инвестирует во все три.

Метрики: работает ли подход

Бесполезно внедрять blameless post‑mortem и не измерять результат.

• Repeat incident rate. Доля инцидентов, вызванных причиной, которая уже была в post‑mortem. Если 40% инцидентов — повторы, action items не выполняются или неэффективны.

• MTTR (Mean Time To Recovery). Среднее время от обнаружения до восстановления. Хорошие post‑mortem с категорией «detect» снижают MTTR: команда учится быстрее диагностировать.

• Action item completion rate. Какой процент action items из post‑mortem выполнен в срок. Если ниже 70% — проблема не в инцидентах, а в приоритизации. Action items конкурируют с фичами за время разработчиков, и без поддержки руководства проигрывают.

• Количество post‑mortem без action items. Если встреча проведена, документ написан, но action items — ноль или «будем внимательнее», post‑mortem не выполнил свою функцию.

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

Когда у команды случается инцидент, ей нужно не просто «разобрать аварию», а быстро понять, что именно улучшить в мониторинге, деплое, тестах и архитектуре, чтобы это не повторилось. Поэтому в календаре — темы, которые помогают делать post‑mortem не формальностью, а источником конкретных изменений. ➡ [Посмотреть календарь мероприятий]