Через полгода после большого сбоя команда снова получила то же падение и по той же причине. Старый постмортем открыли не из любопытства, а почти по инерции, и выяснилось неприятное: список action items там был, ответственные стояли, оформление выглядело образцово, но не выполнен был ни один пункт. Именно так, по данным Habr / Карьера, и работает театр надёжности: процесс формально есть, а практической пользы от него ноль.
Исходный текст на Habr устроен как разбор не одной частной аварии, а повторяющегося паттерна, который автор видит в инженерных командах со стороны. Формально постмортем в описанной истории не провалился. Он отлично выполнил другую задачу: помог команде пережить инцидент, оформить коллективное раскаяние, разослать документ по спискам рассылки и создать ощущение, что выводы сделаны. Проблема в том, что реальная цель таких процедур часто расходится с заявленной. На упаковке написано «чтобы не повторилось», а по факту процесс нужен «чтобы выглядело, будто организация контролирует ситуацию».
В этом и есть самый болезненный тезис материала. Когда в компании обсуждают неработающие процессы, первая реакция обычно предсказуема: бардак, недисциплинированность, не дожали внедрение, забыли закрыть задачи. Но автор предлагает смотреть глубже. Если красивый постмортем с таймлайном, five whys, таблицами и owners повторяется, а эффект каждый раз один и тот же, значит, дело не в случайной лени. Значит, процесс изначально встроен в систему как ритуал. Он должен не чинить, а демонстрировать зрелость: руководству, соседним отделам, клиентам, иногда самой команде. В такой конструкции невыполненные action items не баг, а почти штатный исход. Они нужны как декорация в момент разбора, а не как рабочий план на ближайшие месяцы.
Для российских и русскоязычных IT-команд этот сюжет слишком узнаваем. У многих компаний за последние годы выросла нагрузка на внутреннюю отчётность: инцидентные отчёты, ретро, risk review, согласования, формальные статусы по надёжности. Всё это само по себе не вредно. Вред начинается в момент, когда артефакты отделяются от реальной инженерной работы. Тогда вместо снижения числа повторных аварий команда получает вторую смену по производству документов. Метрики есть, владельцы процессов есть, встречи назначены, но изменения в коде, инфраструктуре и приоритетах не происходят. Снаружи система выглядит взрослой, внутри она просто научилась воспроизводить правильную картинку.
Отсюда вытекает и неприятный управленческий вывод. Театр надёжности редко появляется потому, что кто-то однажды решил всех обмануть. Чаще его выращивают сами стимулы. Если менеджер оценивается по наличию оформленного постмортема, он получит постмортем. Если тимлида спрашивают, проведён ли разбор и назначены ли ответственные, он обеспечит разбор и назначит ответственных. Если у команды нет ресурса на переделку архитектуры, на удаление хрупких зависимостей или на скучную, но критичную автоматизацию, action items так и останутся в документе. Это не оправдание, а диагноз: организация измеряет следы деятельности, а не последствия. В такой среде люди довольно быстро учатся делать то, что проверяют.
Для разработчиков здесь важен практический сигнал. Наличие процесса ещё ничего не говорит о его полезности. Полезность проверяется проще и жёстче: повторился ли инцидент, закрыты ли изменения в проде, уменьшилась ли зона отказа, стало ли быстрее восстановление, стало ли меньше ручных операций. Если ответов нет, значит, процесс работает как презентация. Для продактов и IT-руководителей вывод не мягче: нельзя бесконечно требовать зрелых процедур и одновременно не отдавать под них время, приоритет и бюджет. Постмортем без последующих инженерных изменений ничем не лучше чек-листа ради чек-листа. Для HR и фаундеров это тоже не абстракция, потому что ритуальная занятость быстро бьёт по мотивации сильных инженеров. Люди особенно остро чувствуют момент, когда от них ждут не результата, а участия в корпоративной пантомиме.
Материал Habr ценен тем, что не сводит проблему к плохим людям и не предлагает волшебную методологию взамен. Он скорее возвращает разговор к неудобовому, но трезвому вопросу: для чего существует каждый конкретный процесс в вашей компании на самом деле. Чтобы предотвращать повторение сбоя или чтобы снять тревогу после него? Чтобы менять систему или чтобы оставить после инцидента аккуратный PDF? Пока ответ честно не проговорён, любые разговоры об инженерной культуре рискуют остаться частью того же спектакля. И, похоже, главный дефицит в IT сейчас не новые шаблоны разборов, а готовность отменять процессы, которые слишком хорошо научились изображать работу.