Когда в проде что-то ломается, очень легко скатиться в самый привычный и, на первый взгляд, логичный сценарий: начать искать виноватого.

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

И я понимаю, почему так происходит. Когда всё горит, хочется быстро найти точку, куда можно направить злость, усталость и тревогу. Хочется сказать: «Вот. Нашли. Проблема здесь». Человеческий мозг любит простые ответы, особенно когда вокруг дым, алерты и бизнес уже аккуратно спрашивает, когда «примерно всё починится», хотя в переводе это означает: «У вас там вообще есть взрослые?»

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

Так появляется не ответственность, а корпоративное партизанское движение. Все всё понимают, но вслух говорят очень осторожно, потому что где-то рядом ходит невидимый протокол «а кто это сделал?».

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

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

Ответственность - это не когда команда находит крайнего и торжественно приносит его в жертву стабильности прода. Ответственность - это когда команда спокойно разбирает факт, причину и действие. Что произошло, почему это стало возможным и что мы меняем, чтобы такая же история не повторилась через две недели, только уже в более дорогой и унизительной форме. Очень плохой финал postmortem - это фраза «впредь быть внимательнее».

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

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

Инциденты в разработке всё равно будут. Это неприятная, но честная часть работы. Можно сколько угодно делать вид, что сильные команды ничего не ломают, но обычно так говорят либо в презентациях, либо люди, которые давно не деплоили ничего живого. Сильная команда отличается не тем, что у неё никогда ничего не падает. Она отличается тем, что после падения становится умнее. Не тише. Не запуганнее. Не осторожнее в плохом смысле, когда все просто боятся лишний раз открыть рот. А именно умнее. Потому что если после каждого инцидента команда просто ищет виноватого, она не учится. Она только копит напряжение и ждёт следующего пожара. А если после инцидента меняется система, значит, боль хотя бы не пропала впустую. Что, согласитесь, уже роскошь по меркам обычной пятницы в проде.