Книга: Руководство по DevOps

Запланируйте встречи для разбора ошибок без поиска виноватых

Чтобы развить в организации культуру беспристрастности, после аварий и значительных инцидентов (например, после неудачного развертывания или проблемы в эксплуатации, повлиявшей на клиентов), когда последствия сбоя уже устранены, нужно провести «послеаварийную ретроспективу» (blameless post-mortem)[145]. Разбор ошибок без поиска виноватых (автор термина — Джон Оллспоу) помогает изучить «ошибки так, чтобы сфокусироваться на ситуационных аспектах механизма сбоя и на процессе принятия решений у человека, стоявшего ближе всех к сбою».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги