Результат разбора любого инцидента — наказание виновного или виновных. Но наказание за ошибки не делает систему надёжнее. Вместо этого оно мотивирует скрывать недочеты. Единственный способ построить предсказуемо работающую ИТ‑инфраструктуру — создать среду, в которой инженеры добровольно и без страха рассказывают о том, что пошло не так. И это задача не HR, а системного менеджмента. О том, как этого достигнуть, делимся в статье.

Природа ошибки в сложных системах

В 2016 году инженеры Amazon проводили постмортем‑разбор после серьёзного сбоя в S3. Ошибка была глупой и человеческой: оператор ввёл неправильную команду при плановом обслуживании, что привело к остановке ключевой подсистемы на несколько часов. Интернет гудел, бизнес терял деньги. Естественно, в итоге кто‑то должен был уволиться.

Но внутри Amazon никто не уволился. Команда провела разбор, выпустила подробный отчёт, а затем изменила интерфейсы администрирования так, чтобы невозможно было ввести ту самую роковую команду без двойного подтверждения. И просто пошли дальше, без крови.

Нет, это не история о гуманности. Это история о понимании того, что сложные системы могут сбоить по определению. Если вы управляете тысячами серверов, сотней микросервисов и пятнадцатью зависимостями от сторонних API, статистически сбой неизбежен. Выбор не в том, случится ли сбой, а в том, узнаете ли вы о его настоящих причинах.

Основной парадокс ИТ‑менеджмента формулируется просто. Когда вы наказываете за ошибку, вы получаете одну ошибку и одно наказание. Когда вы НЕ наказываете за ошибку, вы получаете одну ошибку и пятьдесят исправлений в процессах, инструментах и архитектуре. И эти пятьдесят исправлений — единственное, что действительно повышает надёжность.

Но тогда почему почти везде осуждение (здесь более правильным было бы использовать англицизм «шейминг», но ФЗ № 168…, а вот от постмортемов я не откажусь, слишком емкий термин) продолжается? Почему даже после публичных деклараций о blameless culture на постмортемах всё равно ищут виноватого? Ответ лежит в человеческой психологии и в том, как устроены классические системы управления.

Явное и скрытое осуждение

Открытое наказание за инцидент стало редким в цивилизованных ИТ‑компаниях (по крайней мере западных). Уже почти никто не увольняет инженера за то, что он положил прод. Но осуждение никуда не делось. Оно просто перешло в скрытые формы, которые гораздо опаснее, потому что их труднее идентифицировать и исправить.

Скрытое осуждение — это голос тимлида на постмортеме, когда он спрашивает: «Как ты мог не заметить это на код‑ревью?». Формально вопрос без обвинения, но фактически — публичный укол, после которого инженер замкнётся и больше никогда не признается в своих сомнениях до того, как что‑то пойдёт не так.

Скрытое осуждение — это когда в ежегодной оценке сотрудника появляется пункт «Допустил инцидент с уровнем серьёзности P1», и премия уменьшается. Формально это объективная метрика, потому что формально все знали правила. Но на практике это означает, что инженер приложит все усилия, чтобы не сообщить о потенциальной проблеме, пока она не станет критической.

Наконец, скрытое осуждение — это когда предложения по исправлению корневых причин инцидента постоянно получают в бэклоге приоритет «когда‑нибудь», потому что бизнес не видит в них прямой ценности. Команда знает, что система хрупкая, но её голос не слышат. И когда происходит очередной сбой из‑за той же самой проблемы, инженеры уже не предлагают решений — потому что зачем?

Самый опасный вид осуждения — это самосуд. Инженер, допустивший ошибку, начинает избегать сложных задач, перекладывать ответственность на других, тратить время на создание избыточных проверок, которые не добавляют ценности, но защищают его репутацию. Система теряет скорость и качество, а менеджмент даже не догадывается о настоящей причине деградации.

Как распознать, что в вашей организации процветает скрытое осуждение? Есть несколько верных признаков.

• Один из них — исчезновение инцидентов низкого уровня серьёзности. Если вы фиксируете только P1 и P2, а P3 и P4 почти отсутствуют — это значит, что люди скрывают мелкие проблемы, боясь, что они повлияют на их оценку.

• Другой признак — сверхбыстрые постмортемы. Если разбор инцидента укладывается в 30 минут и ни к каким изменениям процессов не приводит, значит, люди просто отбывают номер, не вскрывая настоящих причин.

• Третий признак — текучка. Если инженеры уходят сразу после крупных инцидентов, скорее всего, они чувствуют себя публично униженными и не видят перспектив оставаться в культуре, где ошибки запоминаются надолго.

Миф об «ответственности»

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

Ответственность в сложной ИТ‑системе выглядит иначе. Она означает, что инженер, вовлечённый в инцидент, добровольно и максимально подробно реконструирует цепочку событий, которые к нему привели. Также это значит, что этот же инженер будет участвовать в выработке мер предотвращения и, вероятно, будет тем, кто их реализует. И когда инцидент повторяется, никто не спрашивает «почему ты не исправил?», а все вместе ищут, почему исправление не сработало.

Наказание не гарантирует ответственности, а гарантирует сокрытие информации. Классическое исследование, проведённое в медицинской авиации, показало: в госпиталях, где врачей наказывали за ошибки, частота сообщений об инцидентах была в семь раз ниже, но реальная смертность пациентов — выше. Потому что врачи скрывали осложнения, не учились на них и повторяли те же ошибки снова и снова. ИТ‑инфраструктура ничем не отличается от операционной. Если вы не знаете о проблеме, вы не можете её исправить.

В Google, которая десятилетиями развивает SRE‑культуру, есть жёсткое правило. Ни один инженер не может быть наказан за ошибку, которая привела к сбою, если он действовал в соответствии с имеющимися у него инструкциями и знаниями. Если же он нарушил процедуру — это отдельный разговор. Но тогда вопрос не в ошибке, а в сознательном нарушении, и это уже не про надежность системы, а про дисциплину.

Бюджет ошибок

Самый эффективный из существующих инструментов, позволяющий убрать осуждение из разбора инцидентов, называется «бюджет ошибок». Идея проста и элегантна: вы определяете целевой уровень надёжности вашего сервиса — например, 99.9% доступности в месяц. Это означает, что 0.1% времени, примерно 43 минуты в месяц, сервис может быть недоступен без нарушения обязательств перед бизнесом. Эти 43 минуты — и есть бюджет ошибок.

Дальше начинается магия. Когда происходит инцидент и сервис падает на 10 минут, команда не спрашивает «кто виноват?». Команда спрашивает «сколько минут бюджета мы потратили?» и «как нам сделать так, чтобы следующий инцидент съел меньше?».

Бюджет ошибок снимает эмоциональное напряжение. Инцидент перестаёт быть катастрофой, за которую нужно с кого‑то спросить. Он становится статистическим событием, которое укладывается или не укладывается в установленные рамки. Если команда уложилась в бюджет — нет вопросов вообще. Если превысила — значит, нужно менять процессы, инструменты или архитектуру. Но наказания ни для кого нет, потому что превышение бюджета — это системная проблема, а не личная вина.

Более того, бюджет ошибок даёт бизнесу инструмент для принятия осознанных решений. Когда продукт‑менеджер хочет выпустить фичу с высоким риском, можно просто сказать: «Ок, мы это сделаем, но тогда мы потратим 15 минут бюджета на тестирование и возможные откаты. У нас остаётся 28 минут на месяц». Это переводит разговор из плоскости «вы мешаете бизнесу» в плоскость «мы управляем общим ресурсом надёжности».

Компании, которые внедрили бюджет ошибок, сообщают о парадоксальном эффекте. Количество инцидентов не снижается — иногда даже растёт на начальном этапе, потому что люди перестают их скрывать. Но время восстановления после сбоев падает, а процент повторяющихся инцидентов стремится к нулю. Потому что теперь у команды есть мотивация исправлять корневые причины, а не прятать концы в воду.

Инженерная анатомия разбора

Постмортем — это главный ритуал blameless culture. Но большинство организаций проводят его неправильно. Типичный постмортем выглядит так: собираются десять человек — инженеры, менеджеры, представители бизнеса. Ведущий просит «рассказать хронологию сбоя». Кто‑то рассказывает. Все задают уточняющие вопросы. В конце составляют список из пятнадцати действий — кто‑то что‑то починит, кто‑то что‑то задокументирует, кто‑то добавит мониторинг. Через месяц никто не помнит этот список. Через три месяца случается такой же сбой.

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

Следующий этап — восстановление не только хронологии, но и мысленных моделей каждого участника. В правильном постмортеме спрашивают не «что ты сделал?», а «что ты думал в тот момент, какие у тебя были данные, что ты считал безопасным?». Без этого невозможно понять системные причины ошибки. Человек, который ввёл не ту команду, глубоко в детстве прочитал неправильную документацию. Человек, который пропустил предупреждение в логах, не был ленивым — просто дашборд был так устроен, что предупреждение терялось среди ста других.

После того как мысленные модели восстановлены, постмортем переходит к поиску «провалов в защите». Хорошая система имеет несколько уровней защиты, которые должны поймать ошибку до того, как она станет инцидентом. Автоматические проверки не сработали. Код‑ревью пропустило. Тест‑сьют не покрыл. Staging‑окружение отличалось от продакшена. Каждый провал — это системная проблема, которую можно исправить, не увольняя ни одного инженера.

И только после этого — последний этап. Постмортем порождает не список из пятнадцати задач, а ровно три задачи.

• Первая — автоматический тест, который не позволит этому конкретному сценарию произойти снова.

• Вторая — изменение в документации или процессах, делающее эту ошибку менее вероятной для всех.

• Третья — метрика, которая покажет, что исправление действительно работает. Если в вашем постмортеме больше трёх значимых пунктов, вы занимаетесь не исправлением корневых причин, а выписыванием списка пожеланий, который никто не выполнит.

Как построить механизмы, а не уговоры

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

Настоящий переход происходит, когда вы меняете системы управления, а не лозунги. Когда в вашей форме оценки сотрудника исчезает пункт «количество допущенных инцидентов» и появляется пункт «качество постмортемов, в которых участвовал». Когда вы поощряете не только героев‑пожарных, тушащих сбой в три часа ночи, а инженеров, которые сделали так, что пожарных вызовов стало меньше. Когда вы включаете в OKR команды не «снизить число инцидентов на 30%» (что приводит к сокрытию инцидентов), а «снизить время восстановления на 50%» и «увеличить долю инцидентов, прошедших полноценный постмортем, до 100%».

Ещё один системный механизм — обязательная ротация на роль инженера поддержки (on‑call). Когда каждый разработчик по очереди отвечает за инциденты, исчезает деление на «мы — разработчики фич» и «они — эксплуатация, которая вечно ломает». Инженер, который сам просидел на дежурстве, будет писать более устойчивый код и более внятные инструкции. И он будет более терпим к ошибкам коллег, потому что знает, как это бывает.

И наконец, самый сложный, но самый важный механизм — изменение реакции руководства на инциденты. Если после сбоя CEO пишет письмо «какого чёрта?» и требует отчёта с фамилиями, никакие ваши постмортемы не помогут. Если руководство смотрит на отчёт об инциденте и спрашивает «чему мы научились?», а не «кого наказали?», система меняется. Это требует лидера, который сам готов быть уязвимым и признавать свои ошибки. Что встречается гораздо реже, чем хотелось бы.

Выводы

Разбор полетов на постмортемах — это не жестокость и не бесчувственность менеджеров. Это результат естественного, но ошибочного представления о том, как работают сложные системы. Люди видят ошибку, видят последствия и хотят, чтобы такое больше не повторилось. Наказание кажется самым прямым способом.

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

Переход к blameless‑культуре начинается с одного простого ритуала. На следующем постмортеме, когда кто‑то начнёт спрашивать «кто это сделал?», остановите его. Скажите: «Нам не важно, кто это сделал. Мы уже знаем этого человека — это инженер, который старался как мог. Теперь давайте разберёмся, как система позволила ошибке дойти до продуктива». В этот момент вы сделаете первый шаг. Все остальные шаги — это системная работа по изменению метрик, процессов и личного примера руководства.

И помните: идеальных систем не существует. Ваши инженеры будут ошибаться. Вопрос не в том, как их заставить не ошибаться. Вопрос в том, как быстро вы об этом узнаете и как эффективно исправите системную причину. А это напрямую зависит от того, боятся ли они говорить правду.

Если после каждого инцидента команда ищет виновного, проблема не в инженерах. Проблема в том, как устроены метрики, постмортемы, on‑call, приоритеты в бэклоге и реакция руководства на сбои.

Для тех, кто хочет управлять не только релизами и командами, но и надёжностью всей инженерной системы, у OTUS есть курс «CTO / Технический директор». Он про тот самый уровень, где технические решения уже невозможно отделить от управленческих: архитектура, риски, процессы, ответственность и зрелость команды.

А чтобы глубже зайти именно в тему инцидентов и командной диагностики, можно начать с бесплатных открытых уроков:

• 16 июня, 20:00 — «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

• 20 мая, 20:00 — «Системная диагностика команды и группы команд». Записаться

Оба урока помогут посмотреть на сбои не как на повод искать виновного, а как на сигнал о том, где инженерной системе пора стать взрослее.