Поверхностная безвиновность
В 2012 году John Allspaw (тогда CTO Etsy) написал программное эссе про blameless post-mortems. Идея проста: при разборе инцидента мы фокусируемся на системе, а не на человеке. «Какие условия позволили этой ошибке произойти?» вместо «кто это сделал?».
Прошло больше десяти лет. Сегодня blameless — почти стандарт в зрелых инженерных организациях. Шаблоны post-mortem-документов содержат явный пункт «blameless». Тренинги для новых сотрудников включают раздел про безвиновный разбор. На конференциях про это рассказывают повсюду.
И при этом настоящих blameless-практик меньше, чем кажется.
Что я наблюдаю в полевых условиях
Я много раз проводил workshop-ы по incident review в больших организациях, которые формально «blameless». И почти всегда вижу один и тот же паттерн:
-
В документе нет имён.
-
Используется страдательный залог: «была развёрнута новая версия», «был принят неверный конфиг».
-
Слово «blame» избегают как такового.
-
Действия описываются в обезличенной форме: «команда» вместо «Иван и Анна».
-
В разделе «contributing factors» — пункты вроде «недостаточный мониторинг», «слабые тесты».
Всё это лексически blameless. Но смыслово часто остаётся blameful, только в более вежливой форме. Все в комнате знают, кто запушил конфиг. И эта молчаливая «общая тайна» становится более токсичной, чем открытый разбор был бы.
Признаки поверхностной безвиновности
1. Имена убраны, но «эпизоды» остались
«Деплой в 14:32 включил неправильную фича-флагу.» Все в команде знают, кто деплоил в 14:32. Это blame в сноске.
2. Action items, направленные на одну роль
«Все младшие SRE должны пройти тренинг по deployment-процедурам.» Перевод: «у нас тут стажёр накосячил». Старшие читают это, кивают, и в подкорке у каждого формируется ассоциация «джуны опасны».
3. Defensive language вместо curiosity
Вместо «как именно вы выбрали эту команду в тот момент?» — «была запущена неверная команда». Первое — это понимание, второе — констатация. Первое раскрывает контекст, второе закрывает разговор.
4. Психологическая безопасность только на сцене
На самом post-mortem всё правильно. После встречи в курилке (или в DM-чате) обсуждение мгновенно становится blameful: «ну да, это вообще-то Иван затащил». Это значит, что blameless — это встречный ритуал, а не способ мышления.
5. Менеджеры используют post-mortem для performance-review
Самый разрушительный признак. Если данные из post-mortem попадают в годовой review инженера — никто никогда не будет говорить честно о своих действиях. Blameless умирает в первый же раз, когда это происходит. Восстановить доверие — годы.
Что отличает настоящую blame-awareness
Allspaw в оригинальной статье говорил не о «отсутствии вины», а о понимании, как локальные решения людей складываются в системные исходы. Настоящая blame-awareness:
Идёт глубже, чем «не называть имён»
Имена могут звучать. «Иван, расскажи, в какой контекст ты входил в момент деплоя, что ты видел в этот момент?» — это вопрос понимания, а не вопрос «зачем ты это сделал?». Разница интонационная и контекстная.
Когда в комнате есть доверие, имена не разрушают. Когда доверия нет, никакая обезличенность не помогает.
Видит работу как «sense-making», а не «execution»
Инженер в момент инцидента — не исполнитель чёткого алгоритма. Он принимает решения в условиях неполной информации, с ограниченным временем и под давлением. Post-mortem должен реконструировать что человек видел, какие гипотезы строил, какие отверг и почему — а не констатировать «он сделал неверный выбор».
Action items направлены на систему, не на людей
«Иван должен быть внимательнее» — не action item. «Должен ли наш CLI требовать confirmation при выполнении этой команды в production-namespace?» — action item.
Каждый раз, когда action item звучит как «человек должен X», переформулируйте: «какое изменение в системе сделало бы X естественным?».
Сепарация от performance-management
Данные post-mortem — не материал для review. Если ваша оргструктура не может это гарантировать, blameless у вас никогда не будет работать. Это первое, что нужно чинить, не процессы разбора.
Что делать, если ваша организация поверхностно-blameless
-
Спросите у своих сотрудников лично (не на публичных опросах): «Что ты не сказал на последнем post-mortem, что хотел сказать?» Их ответы — это карта реальности.
-
Перестаньте использовать слово «blameless» в шаблонах. Используйте «understanding-oriented review». Слово стало токеном, потерявшим смысл.
-
Делайте leader-modelling. Если у вас есть значимый инцидент, в котором вы, как лидер, приняли неверное решение — разберите его публично, с вашим именем. Это меняет норму быстрее любых тренингов.
-
Не сглаживайте противоречия в документах. Если разные участники видели ситуацию по-разному — задокументируйте это. «Иван думал X, Анна думала Y, это расхождение и стало contributing factor.» Это и есть настоящая работа над безопасностью.
-
Аудит action items на blame-кодирование. Раз в квартал проходитесь по open action items и помечайте те, которые скрыто направлены на человека/роль. Переформулируйте.
Главное
Blameless post-mortem без blame-awareness — это безопаснее, чем blameful, но это всё ещё ритуал, а не инженерная практика. Цель — не скрыть, кто что сделал. Цель — понять, как складывается работа в условиях неполной информации, и сделать систему более прощающей. Когда blame-awareness становится культурным, имена в документах перестают значить то, что они значили раньше — потому что они больше не служат маркером для назначения «виноватого».