Blameless-постмортем: почему вопрос «кто виноват» мешает найти причину сбоя
Команда KAI Lab · · 11 мин чтения
Blameless-постмортем — это разбор инцидента, в котором ищут условия, позволившие ошибке случиться, а не человека, которого можно наказать. Дело не в вежливости: инженер, который ждёт наказания, умалчивает детали, без них причину не найти, и сбой повторится — с тем же человеком или со следующим.
Ниже — откуда взялся подход и почему он работает, как пользоваться методом «пять почему» и где он ломается, как формулировать выводы без обвинений и как это выглядит в публичных постмортемах GitLab, Atlassian и AWS.
Что значит blameless
В книге Google SRE blameless-постмортем определён так: он ищет факторы, которые привели к инциденту, не обвиняя ни человека, ни команду в плохих или неуместных действиях. Разбор исходит из того, что все участники действовали с добрыми намерениями и делали то, что считали правильным, исходя из информации, которая у них была. Мысль главы укладывается в одну фразу: людей «починить» нельзя, а системы и процессы, которые помогают людям принимать верные решения, — можно.
Подход пришёл не из IT. Та же глава напоминает, что культура разбора без поиска виноватых сложилась в здравоохранении и авиации, где ошибка стоит жизни.
В IT его популяризировал Джон Оллспоу из Etsy статьёй 2012 года о blameless-постмортемах и «справедливой культуре». Он описывает цель так: инженер, чьи действия привели к аварии, может подробно рассказать, что и когда он делал, что видел, чего ожидал, какие допущения у него были и как он понимал ход событий, — и не бояться наказания.
Почему «кто виноват» мешает найти причину
Оллспоу описывает цикл, в который попадает компания, где ищут виноватых:
- Инженер совершает действие, которое способствует сбою.
- Его наказывают, стыдят или отправляют переучиваться.
- Падает доверие между инженерами, которые работают с продом, и руководством, которое ищет, на кого переложить вину.
- Инженеры замолкают о деталях и начинают прикрывать себя.
- Руководство всё хуже понимает, как на самом деле идёт работа, а инженеры не узнают о скрытых условиях для следующей аварии.
- Ошибки становятся вероятнее, и всё начинается сначала.
Книга Google SRE говорит о том же короче: атмосфера поиска виноватых приучает заметать инциденты под ковёр, а это повышает риск для всей организации. В справочнике Atlassian механизм назван прямо: когда под угрозой репутация или карьера, человек защищает себя, а не интересы компании, и начинает недоговаривать. Поэтому вопрос нужно задавать другой. Не «почему инженер это сделал?», а «почему система позволила ему это сделать или заставила поверить, что так правильно?».
Ловушки мышления
Даже в команде, где никто не хочет никого наказывать, поиск виноватых пробирается в разбор сам. PagerDuty перечисляет искажения, которые его подпитывают, и способы им противостоять:
| Искажение | В чём суть | Что помогает |
|---|---|---|
| Фундаментальная ошибка атрибуции | чужие действия объясняем характером, свои — обстоятельствами | сознательно искать обстоятельства, а не черты человека |
| Предвзятость подтверждения | замечаем факты, которые подтверждают уже готовую версию | назначить «адвоката дьявола», позвать человека из другой команды |
| Ошибка знания задним числом | зная исход, считаем его очевидным | строить хронологию от событий до инцидента вперёд, а не назад от развязки |
| Склонность к негативу | плохое весит больше хорошего | отдельно записывать, что в реагировании сработало |
Первая и вторая история
У Оллспоу есть полезное различение из исследований безопасности. Первая история — очевидная, вторая — та, ради которой пишут разбор.
| Первая история | Вторая история |
|---|---|
| причина сбоя — ошибка человека | ошибка человека — следствие уязвимостей глубже в системе и организации |
| достаточно сказать, как нужно было поступить | важно понять, почему действие казалось человеку разумным в тот момент |
| призыв «быть внимательнее» решит проблему | безопасность растёт, только если постоянно искать уязвимости |
Действие казалось разумным тому, кто его совершал, иначе он бы его не совершил. Постмортем выясняет, почему.
Метод «пять почему»
Метод пришёл из производственной системы Toyota: от проблемы спрашивают «почему это случилось?», потом «почему случилось это?» — и так, пока не дойдут до причины, которую можно исправить. Хороший пример — постмортем GitLab 2017 года, где инженер удалил рабочую базу. Цепочка для первой проблемы там такая:
- Почему GitLab.com не работал? Каталог основной базы удалили по ошибке вместо каталога резервной.
- Почему каталог удаляли? Репликация остановилась, и реплику нужно было пересоздать с пустым каталогом, а процедура была ручной и плохо описанной.
- Почему остановилась репликация? Из-за всплеска нагрузки основной сервер удалил сегменты журнала WAL раньше, чем реплика их забрала.
- Почему выросла нагрузка? Совпали спам и процесс удаления аккаунта сотрудника GitLab.
- Почему аккаунт удаляли? После жалобы тролля: система обработки жалоб позволяла легко пропустить детали.
Вторая цепочка, о том, почему восстановление заняло 18 часов, заканчивается выводом, что у проверки бэкапов не было владельца. Ни один ответ не звучит как «инженер ошибся». Подробнее — в разборе сбоя GitLab 2017.
Где «пять почему» ломается
У метода есть известные ограничения, и Atlassian, которая его защищает, разбирает их сама.
- Цепочка линейная, а сбой — нет. PagerDuty ссылается на работу Ричарда Кука о сложных системах: крупная авария складывается из нескольких факторов, и единственной корневой причины обычно нет. Даже у GitLab две цепочки. Рисуйте дерево, а не линию.
- «Почему» подталкивает к «кто». Оллспоу в эссе «The Infinite Hows» 2014 года замечает, что вопрос «почему?» слишком легко приводит к ответу на вопрос «кто?». Человек, которого спрашивают «почему ты так сделал», начинает оправдываться. Вопросы «как» и «что» дают описание обстановки: что было на экране, чего ожидали, что отличалось от обычного.
- Где остановиться — решает тот, кто спрашивает. Если цепочка упёрлась в «человеческий фактор», копнули недостаточно. Atlassian прямо запрещает называть корневой причиной человека.
- Найдёшь только то, что знаешь. Один человек не увидит всех факторов. Ответ Atlassian — разбирать командой, вместе с теми, кто был в инциденте, и с руководителями.
- «Пять» — не норма. Иногда хватает трёх вопросов, иногда нужно больше.
Вывод простой: метод полезен, если пользоваться им как деревом, задавать вопросы «как» и «что» и никогда не останавливаться на человеке.
Как формулировать без обвинений
Правила из справочников Atlassian и PagerDuty:
- Роли вместо имён. «Дежурный инженер платформы», а не имя. Факты при этом остаются точными.
- Что человек знал в тот момент. Хронология описывает, что участник видел и чего ожидал, а не то, что стало ясно потом.
- Вопросы «как» и «что». «Что было на экране, когда пришёл алерт?» вместо «почему ты не посмотрел?».
- Без оценочных слов. «Забыл», «не удосужился», «по невнимательности», «должен был» из текста убираются.
- Причина — свойство системы. Чего не хватило: проверки, ограничения, сигнала, документации, времени.
PagerDuty предлагает ещё один приём: спросить себя, почему разумный, толковый и порядочный человек мог сделать то, что выглядит причиной аварии. Ответ почти всегда указывает на систему.
| Обвиняющая формулировка | Без обвинений |
|---|---|
| Инженер удалил не тот каталог | Команда удаления выполнилась на основном сервере: приглашение командной строки на обоих серверах выглядело одинаково, а процедура не требовала проверить роль сервера |
| Дежурный проигнорировал алерт | Алерт пришёл в канал, где за неделю было 300 срабатываний, и ничем не отличался от шума |
| Команда опять выкатила без тестов | Пайплайн позволял выкатить изменение в прод, пропустив этап тестов |
| Разработчик закоммитил ключ | В репозитории не было проверки на секреты до коммита, а у ключа не было срока действия |
| Оператор ввёл неверный параметр | Инструмент позволял вывести из работы больше серверов, чем выдерживает подсистема |
Как это выглядит в публичных постмортемах
GitLab, 2017
В постмортеме GitLab инженер не назван. Компания отдельно объяснила: во внутреннем документе имя было, его добавил сам инженер и не возражал против публикации, но в будущем имена будут скрывать, потому что другим это может быть неприятно. Главный вывод GitLab — улучшать восстановление и делать очевидным, на каком хосте ты работаешь, а не запрещать инженерам команды. Безопасный алиас для rm защитил бы от одной ошибки, но не от сбоя диска и десятка других способов потерять данные. Идеальная среда, по словам GitLab, — та, где можно ошибиться и быстро восстановиться почти без последствий.
Atlassian, 2022
5 апреля 2022 года скрипт Atlassian удалил 883 сайта 775 клиентов, восстановление у части из них заняло до 14 дней. Разбор описывает две проблемы, и обе системные. Первая — разрыв в коммуникации: команда, которая запросила удаление, передала идентификаторы целых сайтов вместо идентификаторов приложения. Вторая — API удаления принимал оба вида идентификаторов и считал ввод верным. Ревью скрипта проверяло, какой метод API вызывается и как, но не сами идентификаторы. В разборе сказано прямо: «люди не вызывают инциденты — системы позволяют ошибкам случиться» (Atlassian, Post-Incident Review, 2022). А ответственность сооснователи компании взяли на себя в первых строках документа. Исправления тоже системные: мягкое удаление для всех систем, поэтапная раскатка и проверенный откат. Подробности — в разборе сбоя Atlassian 2022.
AWS S3, 2017
Инженер AWS по утверждённому плейбуку выводил из работы несколько серверов S3, но ввёл один параметр неверно, и серверов ушло гораздо больше. В разборе AWS сказано, что инструмент позволил вывести слишком много мощности слишком быстро. Исправили инструмент: теперь он выводит мощности медленнее и не даёт опустить подсистему ниже минимально необходимого уровня. Заодно AWS взялась проверить на такие же защиты другие операционные инструменты. Подробнее — в разборе сбоя AWS S3 2017.
Blameless не значит безответственно
Оллспоу специально оговаривает: разбор без поиска виноватых не снимает с инженера ответственности. Инженер, который ошибся и может говорить об этом спокойно, лучше всех знает свою ошибку. Поэтому именно он помогает придумать исправления и отвечает за то, чтобы компания стала надёжнее. «Справедливая культура» — это баланс безопасности и ответственности, а не всепрощение.
Факты тоже не размываются. Atlassian просит называть людей по ролям, но оставаться точными и однозначными в том, что произошло. Ответственность руководства никуда не девается, пример Atlassian это показывает.
Как ввести blameless-разборы в команде
- Открывайте каждую встречу напоминанием, что разбор без поиска виноватых и зачем это нужно. Так делает Atlassian. PagerDuty предлагает для этого установку Нормана Керта из ретроспектив: все сделали лучшее, что могли, с теми знаниями, навыками, ресурсами и в той ситуации, что у них были.
- Благодарите за сообщения о проблемах. В книге Google SRE это отдельная практика: заметно поощрять людей, которые поступили правильно, например сами подняли тревогу.
- Зовите человека со стороны. Коллега из другой команды задаёт вопросы, которые участникам кажутся очевидными, и ломает готовую версию.
- Проверяйте текст на обвинения на ревью. Оценочные слова и имена в причинах — повод вернуть черновик.
- Делитесь разборами. В Google есть рассылка «постмортем месяца» и клубы чтения постмортемов. Чем больше людей видят, что за ошибки не наказывают, тем честнее следующие разборы.
Как оформить сам документ — разделы, хронология, задачи с владельцами — разобрано в статье как писать постмортем.
Навык формулировать причину через систему тренируется на практике. В симуляторе DevOps KAI Lab каждый месяц заканчивается постмортемом по фактам, которые собрала команда, — и там быстро видно, где текст скатывается в «инженер не проверил». Начать можно с бесплатных первых заданий первого месяца.
Частые вопросы
Blameless значит, что за ошибки никто не отвечает? Нет. Разбор не ищет, кого наказать, но инженер, который ошибся, участвует в поиске исправлений и отвечает за то, чтобы система стала надёжнее. Руководство отвечает за условия, в которых ошибка стала возможной.
Можно ли называть имена в постмортеме? Лучше называть роли: «дежурный», «инженер базы данных». Atlassian так и делает, а GitLab после 2017 года пообещала скрывать имена в публичных разборах. Факты при этом описываются точно.
Метод «пять почему» устарел? Нет, но у него есть пределы. Он хорош, чтобы не остановиться на поверхностной причине. Плох, если превращается в допрос «почему ты это сделал» и сводит всё к одной линии. Используйте дерево и вопросы «как» и «что».
Что делать, если руководитель после инцидента ищет виноватого? Показать, чего компания лишится: подробностей, без которых причину не найти. Предложить мерить результат разбора закрытыми задачами, а не выговорами. Хорошо работают публичные примеры — Atlassian, GitLab и AWS разбирали свои крупнейшие сбои без поиска виноватых.
Источники
- Google. Site Reliability Engineering, глава 15: Postmortem Culture: Learning from Failure — определение blameless-постмортема, происхождение из медицины и авиации, практики внедрения.
- John Allspaw, Etsy. Blameless PostMortems and a Just Culture, 22.05.2012 — цикл поиска виноватых, первая и вторая история, ответственность инженера.
- John Allspaw. The Infinite Hows, O'Reilly Radar, 13.11.2014 — критика вопроса «почему».
- Atlassian. Incident Management Handbook: Postmortems — раздел Blameless postmortems: роли вместо имён, вопрос о системе.
- Atlassian. In defense of 5 whys — возражения к методу и ответы на них.
- PagerDuty. Blameless Culture и The Postmortem Process — когнитивные искажения, вопросы «как» и «что», работа Ричарда Кука.
- GitLab. Postmortem of database outage of January 31, 10.02.2017 — «пять почему», решение скрывать имена.
- Atlassian. Post-Incident Review on the Atlassian April 2022 outage, 29.04.2022.
- AWS. Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region, 2017.