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

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

Во время совещания по разбору ошибок мы делаем следующее:

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

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

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

• допускаем, что всегда есть ситуации, где люди могут действовать только по своему усмотрению, а оценить эти действия можно только в ретроспективе;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы справиться с проблемой, в компании придумали инструмент под названием Morgue, позволяющий легко фиксировать аспекты каждого сбоя, например его MTTR и степень серьезности, лучше работать с разными часовыми поясами (это стало важно, потому что многие сотрудники Etsy начали работать удаленно) и включать в отчеты другие данные, например текст в формате Markdown, изображения, теги и историю.