Михаил Чугунков. Управление инцидентами: простой процесс реагирования на аварии

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

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

Управление инцидентами — это супер широкая тема с богатой теоретической базой.

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

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

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

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

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

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

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

Вот этот этап про предотвращение часто забывается, а зря.

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

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

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

Чтобы избежать такой ситуации, руководитель разработки должен создать матрицу рисков с классификацией инцидентов. Первый класс включает нарушение бизнес-критичных процессов, требующее срочного реагирования в любое время, которое, согласно ТК РФ, оплачивается. Второй класс — серьезные аварии, решаемые в приоритетном порядке, но только в рабочее время, например, поломка внутренней системы деплоя на выходных. Мелкие баги, вроде неправильного цвета кнопки, исправляются в штатном порядке и не регистрируются как инциденты.

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

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

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

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

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

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

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

Тяжело в учении — легко в бою, и информация гораздо лучше усваивается через интерактив, чем через сухую теорию.

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

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

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

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

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

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

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

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

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

Процесс и PlayBook разработки команды выложены на GitHub, доступ к которому можно получить по QR-коду.