Во время совещания и последующего решения вопроса нужно запретить употребление фраз «мог бы» и «должен был», так как это контрфактуальные высказывания, возникающие из свойства человеческого мышления создавать альтернативные варианты уже происшедших событий.
Контрфактуальные утверждения, такие как «Я мог бы…» или «Если бы я знал об этом, я бы…», формулируют проблему в терминах воображаемой системы, а не в терминах системы, существующей на самом деле, которой мы и должны себя ограничивать (см. приложение 8).
Один из возможных неожиданных результатов таких встреч — сотрудники часто станут винить себя за то, что оставалось вне их контроля, или сомневаться в своих способностях. Йен Малпасс, инженер Etsy, замечает: «Когда мы делаем что-то такое, отчего весь сайт вдруг перестает работать, все внутри стынет, как от прыжка в ледяную воду. Наверное, первая мысль у всех — “Я неудачник, я понятия не имею, что делаю”. Надо это прекратить, такие мысли — путь к отчаянию, сумасшествию и ощущению себя обманщиком. Нельзя допускать, чтобы хорошие инженеры так о себе думали. Гораздо лучший вопрос: “Почему тогда это казалось мне правильным?”»
Во время совещаний мы должны выделить достаточно времени на мозговой штурм и на выбор ответных мер. Когда контрмеры определены, нужно определить их приоритет, составить план выполнения и выбрать ответственного за их воплощение в жизнь. Все это показывает, что мы ценим улучшение повседневной работы больше, чем ее саму.
Дэн Мильстейн, один из ведущих инженеров Hubspot, пишет, что он начинает совещания по разбору ошибок со слов: «Давайте попытаемся подготовиться к такому будущему, где мы такие же тупые, как сегодня». Другими словами, контрмера «быть осторожнее» или «быть не такими глупыми» — плохая, вместо этого мы должны разработать реальные контрмеры, чтобы подобные ошибки больше не повторялись.
Примерами контрмер могут быть автоматизированные тесты для обнаружения опасных состояний в цикле развертывания, добавление новой телеметрии, определение категорий изменений, подразумевающих дополнительное рецензирование коллегами, и проведение репетиций сбоев во время регулярных упражнений игровых дней.
Распространяйте информацию с разбора ошибок как можно шире
Проведя совещание по разбору ошибок, нужно сообщить всем о доступности записей со встречи и других документов (например, записей о восстановленном ходе событий, логов IRC-чата, внешних контактов). Эта информация в идеале должна находиться в централизованном месте, где все сотрудники компании могут получить к ней доступ и извлечь пользу и новые знания из произошедшего сбоя. Проведение совещаний с разбором ошибок настолько важно, что можно даже приостановить полное устранение инцидента до того, как будет завершен анализ сбоя.