15. Культура постмортема: учимся на ошибках

Авторы — Джон Лунни и Сью Льюдер

Под редакцией Гэри О’Коннора

Ошибки — плата за знания.

Девин Кэрреуэй

Будучи SR-инженерами, мы работаем с очень большими, сложными, распределенными системами. Мы постоянно дополняем наши сервисы новыми функция­ми и добавляем новые системы. Перебои и внештатные ситуации неизбежны, учитывая масштаб и интенсивность этих изменений. Когда это происходит, мы устраняем причину проблемы и сервис снова функционирует в нормальном режиме. И если бы у нас не было какого-либо формализованного процесса извлечения опыта из этих происшествий, они могли бы повторяться бесконечно. Если не делать из них выводы, то сбои будут становиться сложнее и даже порождать новые сбои, перегружая систему и ее операторов, вплоть до помех пользователям. Поэтому анализ завершившегося инцидента — «разбор полетов» — является важным инструментом SR-инженера.

Концепция «разбора полетов» и так называемого постмортема хорошо известна в индустрии высоких технологий [Allspaw, 2012]. Постмортем представляет собой письменный отчет об инциденте, его последствиях, действиях, предпринятых для его смягчения или устранения, его первопричине (или первопричинах), а также о последующих действиях для предотвращения его повторения. Эта глава описывает критерии для выбора момента проведения «разбора полетов» и составления постмортема, излагает практику организации этого процесса, а также советы по введению соответствующей культуры на основании нашего опыта, полученного за годы работы.

Философия постмортема от Google

Главная цель написания постмортема — гарантировать документирование инцидента, тщательно изучить все имевшие место его причины и, что особенно важно, принять эффективные профилактические меры для уменьшения вероятности его повторения и/или возможных последствий. Подробный обзор методов анализа первопричин выходит за рамки этой главы (вместо нее см. [Rooney, 2004]); впрочем, по теме качества систем можно найти большое количество публикаций, практических рекомендаций и инструментов. Наши команды используют для анализа первопричин различные методы, выбирая наиболее подходящие для их сервисов. Проведение «разбора полетов» и составление постмортема ожидается после любого значительного нежелательного события. Это не наказание, а возможность научиться чему-то новому для всей компании. Стоимость этого процесса, однако, достаточно высока в плане затраченных усилий и времени, поэтому мы сами вольны решать, когда приступить к отчету. Команды обладают некоторой внутренней свободой действий, однако есть общие правила, когда постмортем необходим:

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

• потеря данных любого типа;

• потребовалось вмешательство дежурного инженера (отмена и откат изменений, перенаправление трафика и т.п.);

• время разрешения ситуации превысило определенный лимит;

• ошибка системы мониторинга (обычно это подразумевает обнаружение инцидента пользователем или инженером).

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

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

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

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

• Тыканье пальцем. «Бэкенд-часть системы слишком сложная, ее надо переписать! Она выходила из строя каждую неделю в течение трех последних кварталов, и я уверен, что мы все устали исправлять все по мелочам. Серьезно, если меня вызовут еще хотя бы раз, я перепишу ее сам...»

• Безобвинительный тон. «Принятие решения о переписывании бэкенд-части системы в самом деле может предотвратить дальнейшее возникновение этих досадных ситуаций, а руководство по обслуживанию текущей версии довольно объемное и слишком сложное, чтобы его можно было полноценно изучить. Я уверен, что наши будущие дежурные инженеры скажут нам спасибо!»

Практическая рекомендация: избегайте обвинений и будьте конструктивными Безобвинительный постмортем может показаться непростым для написания, поскольку сам формат постмортема предписывает явно указывать действия, которые привели к инциденту. Устранение порицаний из постмортема придаст людям уверенности, чтобы безбоязненно обсуждать проблему. Важно также не заставлять отдельных сотрудников или команды слишком часто заниматься составлением постмортемов, превращая это в наказание. Атмосфера страха перед обвинением создает почву для замалчивания проблем и инцидентов, что ведет к возрастанию рисков для всей организации [Boysen, 2013].

Сотрудничайте и делитесь знаниями

Мы ценим сотрудничество, и «разбор полетов» здесь не исключение. Процесс составления постмортема включает сотрудничество и обмен знаниями на каждом этапе.

Мы пишем наши постмортемы в Google Doc с использованием внутрикорпоративных шаблонов (см. приложение Г). Вне зависимости от того, какое средство вы используете, обращайте внимание на следующие ключевые свойства.

• Совместная работа в реальном времени. Обеспечивает максимально быстрый сбор данных и идей. Незаменима на ранней стадии работы над постмортемом.

• Открытая система комментариев и примечаний. Упрощает поиск решений методом краудсорсинга (то есть «народной стройки». — Примеч. пер.) и расширяет их покрытие.

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

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

Критерии оценки могут включать следующее.

• Собраны ли ключевые данные по инциденту для последующего исследования?

• Является ли оценка влияния полной и завершенной?

• Была ли найдена основная причина?

• Целесообразны ли план действий и очередность последующих исправлений ошибок?

• Поставлены ли заинтересованные стороны в известность о результатах?

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

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

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

Внедрение культуры постмортема

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

• Постмортем месяца. В ежемесячной рассылке по всей организации распространяется наиболее содержательный и качественный постмортем.

• Группа Google+, посвященная постмортемам. В этой группе распространяют и обсуждают примеры постмортемов — свои и других организаций, эффективные методы работы и комментарии по поводу постмортемов.

• Книжные клубы по постмортемам. Команды ведут регулярные собрания (читательские клубы), на которых за освежающими напитками рассматриваются особенно интересные или значимые постмортемы и ведется открытый диалог с вовлеченными и не вовлеченными в событие лицами, а также с новыми сотрудниками Google о том, что произошло и какие уроки можно извлечь из инцидента, какими будут его последствия. Инцидент может рассматриваться по прошествии нескольких месяцев или даже лет!

• «Колесо неудачи». Новые SR-инженеры часто проходят через упражнение «Колесо неудачи» (см. подраздел «Катастрофа: ролевая игра» на с. 484), в ходе которого разыгрываются события какого-либо постмортема с группой инженеров, исполняющих соответствующие роли. Это происходит в присутствии инженера, работавшего над изначальным инцидентом. Он помогает сделать обстановку максимально приближенной к реальности.

Одна из главных трудностей при внедрении культуры постмортемов в организации состоит в том, что некоторые могут оспорить их значимость, ссылаясь на затраты на подготовку. Следующие меры помогут преодолеть это затруднение.

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

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

• Поощряйте осведомленность и участие высшего руководства. Даже сам Ларри Пейдж говорит об огромной значимости постмортемов!

Практическая рекомендация: явно вознаграждайте людей за правильные поступки Основатели Google Ларри Пейдж и Сергей Брин проводят TGIF (из «Википедии»: TGIF — акроним к английской фразе Thank God it’s Friday — «Слава Богу, сего­дня пятница, празднование последнего рабочего/учебного дня недели». — Примеч. пер.), еженедельное собрание сотрудников в прямом эфире в нашей штаб-квартире в Маунтин-Вью, Калифорния, которое транслируется в офисы Google по всему миру. Одно из TGIF 2014 года было посвящено теме «Искусство постмортема» и включало дискуссию SR-инженеров о событиях с серьезными последствиями. Один из них говорил о недавно загруженном им обновлении. И хотя оно было заранее тщательно протестировано, непредусмотренное взаимодействие программ на четыре минуты вывело из строя важнейший сервис. Инцидент продолжался всего четыре минуты, потому что инженер не растерялся и немедленно отменил изменения, предотвратив куда более обширные и далеко идущие последствия. Этот инженер не только неме­дленно получил два партнерских бонуса1 в награду за быстрые и грамотные действия по разрешению инцидента, но и сорвал шквал аплодисментов от присутствующих на пятничном мероприятии, включая основателей компании и многотысячную аудиторию

сотрудников Google. В дополнение к таким публичным мероприятиям Google имеет ряд внутрикорпоративных соцсетей, которые стимулируют коллег отмечать хорошо составленные отчеты и отличное управление инцидентами. Это один из многих примеров того, как признание вклада в работу приходит со стороны всех сотрудников — от рядовых специалистов до директоров1.

Практическая рекомендация: интересуйтесь мнениями об эффективности постмортема В Google стремятся оперативно решать возникающие проблемы и делиться инновациями в рамках всей корпорации. Мы постоянно интересуемся у наших команд, насколько постмортемы способствуют решению их задач и что в них можно усовершенствовать. Мы задаем следующие вопросы. Помогают ли постмортемы в вашей работе? Не слишком ли изнурительным вам кажется написание постмортемов (см. главу 5)? Какие приемы и методы ваша команда могла бы порекомендовать остальным? Какие из инструментов вы хотели бы усовершенствовать? Результаты опроса позволяют находящимся «на передовой» SR-инженерам спросить об улучшениях, которые повышали бы эффективность постмортемов.

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

Итоги главы: непрерывные улучшения

Мы с уверенностью можем говорить, что благодаря постоянным усилиям по внедрению культуры постмортемов системы Google реже подвергаются сбоям и это делает их более эффективными и комфортными для пользователей. Наша рабочая группа «Постмортемы в Google» служит примером нашей приверженности культуре безобвинительных постмортемов. Эта группа координирует действия по составлению постмортемов во всей компании: централизованно собирает шаблоны постмортемов, автоматизирует создание постмортемов на основании данных от программных инструментов, используемых при работе над инцидентом, и помогает автоматизировать извлечение данных из постмортемов, чтобы мы могли проанализировать имеющиеся тенденции. Мы смогли объединить лучшие методы работы над такими различными продуктами, как YouTube, Google Fiber, Gmail, Google Cloud, AdWords и Google Maps. Хотя эти разработки и различаются, все они используют постмортемы с одной и той же целью — извлекать уроки из наших самых сложных и неприятных событий.

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