На ретроспективе после серьёзного инцидента команда ищет виновного, хотя дефект уже исправлен. Какой механизм качества превращает инцидент в системные улучшения?
Нужен бескарательный разбор инцидента — postmortem с анализом первопричин и системных факторов, а не поиск виновного. Его результатом должны стать проверяемые действия: изменения в требованиях, тестах, мониторинге, процессе выпуска или распределении ответственности.
Такой подход сформировался в практиках управления инцидентами и надёжностью сложных систем. Он решает исходную проблему обвинительного разбора: страх наказания заставляет участников скрывать ошибки и упрощать объяснение до фразы «кто-то не проверил».
Бескаратность не означает отсутствие ответственности. Она отделяет анализ причин от дисциплинарных решений и помогает исследовать условия, при которых ошибка стала возможной и не была обнаружена раньше.
Если команда ограничивается исправлением дефекта или назначением виновного, устраняется только непосредственная причина. Сохраняются слабые места процесса: неоднозначные критерии готовности, отсутствие проверки опасного сценария, недостаточный контроль изменений или неясная зона ответственности.
Последствием становится повторение инцидента в другой форме. Кроме того, метрика «число найденных виновных» не показывает устойчивость процесса и ухудшает качество обратной связи: участники начинают поздно сообщать о рисках и скрывать собственные ошибки.
Разбор следует проводить после стабилизации системы и опираться на факты: хронологию событий, внесённые изменения, результаты проверок, сигналы мониторинга и решения участников. Нужно разделить несколько уровней причин:
Для каждого вывода формируют корректирующее действие с владельцем, сроком и критерием завершения. Хорошее действие меняет систему: добавляет контроль для критичного риска, уточняет критерии готовности, улучшает наблюдаемость или пересматривает порядок выпуска. Формулировка «быть внимательнее» не является проверяемым улучшением.
Важно не превращать postmortem в бесконечный список задач. Приоритет получают действия, которые уменьшают вероятность повторения или сокращают ущерб, а их выполнение затем проверяется отдельно. Если человеческое нарушение было сознательным и грубо пренебрегало правилами, бескаратный формат не отменяет управленческой ответственности; однако обычную ошибку нельзя подменять наказанием за отсутствие системного контроля.
После релиза неверный расчёт скидки привёл к финансовым потерям. Рассматривались три варианта: наказать автора изменения, добавить ещё один ручной тест или провести postmortem с анализом цепочки принятия решения.
Наказание могло быстро показать реакцию руководства, но не устраняло риск повторения. Дополнительный ручной тест повышал шанс обнаружения именно этого дефекта, однако увеличивал стоимость регресса и не решал проблему отсутствия контроля для аналогичных изменений.
Выбрали postmortem. Выяснилось, что бизнес-правило было неоднозначным, критичный сценарий не имел владельца, а выпуск не требовал проверки финансовых инвариантов. Команда уточнила требования, добавила автоматизированную проверку ключевого правила и включила финансовые изменения в обязательный маршрут ревью; результатом стало уменьшение класса повторяемых пропусков без привязки качества к поиску виновного.
1. Чем postmortem отличается от анализа первопричины?
Ответ: Postmortem — это управляемый разбор всего инцидента: что произошло, как его обнаружили, как реагировали и какие действия нужны дальше. Анализ первопричины — лишь часть такого разбора, причём в сложных системах обычно существует не одна причина, а цепочка технических и организационных факторов.
2. Как проверить, что корректирующее действие действительно снижает риск?
Ответ: Для действия заранее задают наблюдаемый критерий результата. Например, недостаточно написать «улучшить мониторинг»; нужно определить, какой сигнал появится, за какое время он должен обнаружить ошибку и кто проверит его работоспособность. Через согласованный срок оценивают выполнение и фактическое изменение показателей: времени обнаружения, доли повторных инцидентов или количества пропущенных критичных сценариев.
3. Не приводит ли бескаратный подход к безответственности?
Ответ: Нет, если он сохраняет прозрачность решений и владельцев действий. Бескаратность означает, что добросовестная ошибка анализируется как свойство системы, а не автоматически становится основанием для наказания. При этом команда фиксирует, кто должен изменить процесс, к какому сроку и по какому критерию; умышленное нарушение или сокрытие информации рассматриваются отдельно.