Джин Ким - Руководство по DevOps

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

Чтобы лучше понять, что же на самом деле произошло, на совещании должны присутствовать следующие участники:

• принимавшие решения, имеющие отношение к проблеме;

• обнаружившие проблему;

• устранявшие проблему;

• диагностировавшие проблему;

• пострадавшие от проблемы;

• все остальные заинтересованные в разборе проблемы.

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

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

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

Контрфактуальные утверждения, такие как «Я мог бы…» или «Если бы я знал об этом, я бы…», формулируют проблему в терминах воображаемой системы , а не в терминах системы, существующей на самом деле , которой мы и должны себя ограничивать (см. приложение 8).

Один из возможных неожиданных результатов таких встреч — сотрудники часто станут винить себя за то, что оставалось вне их контроля, или сомневаться в своих способностях. Йен Малпасс, инженер Etsy, замечает: «Когда мы делаем что-то такое, отчего весь сайт вдруг перестает работать, все внутри стынет, как от прыжка в ледяную воду. Наверное, первая мысль у всех — “Я неудачник, я понятия не имею, что делаю”. Надо это прекратить, такие мысли — путь к отчаянию, сумасшествию и ощущению себя обманщиком. Нельзя допускать, чтобы хорошие инженеры так о себе думали. Гораздо лучший вопрос: “Почему тогда это казалось мне правильным?”»

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

Дэн Мильстейн, один из ведущих инженеров Hubspot, пишет, что он начинает совещания по разбору ошибок со слов: «Давайте попытаемся подготовиться к такому будущему, где мы такие же тупые, как сегодня». Другими словами, контрмера «быть осторожнее» или «быть не такими глупыми» — плохая, вместо этого мы должны разработать реальные контрмеры, чтобы подобные ошибки больше не повторялись.

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

Проведя совещание по разбору ошибок, нужно сообщить всем о доступности записей со встречи и других документов (например, записей о восстановленном ходе событий, логов IRC-чата, внешних контактов). Эта информация в идеале должна находиться в централизованном месте, где все сотрудники компании могут получить к ней доступ и извлечь пользу и новые знания из произошедшего сбоя. Проведение совещаний с разбором ошибок настолько важно, что можно даже приостановить полное устранение инцидента до того, как будет завершен анализ сбоя.

Такой подход помогает распространять локальные улучшения и опыт по всей компании. Рэнди Шуп, бывший технический директор Google App Engine, описывает то, как документация совещаний по разбору ошибок может иметь огромную ценность для организации: «Как вы можете догадаться, в Google вся информация доступна. Все документы с разбора причин сбоев находятся в местах, где их могут видеть все сотрудники. И поверьте мне, когда у какой-то группы происходит авария, похожая на то, что уже когда-то было, эти документы читаются и изучаются в первую очередь» [146].