Как запустить процесс управления крупными инцидентами

Управление инцидентами, оказывающими сильное воздействие, и их разрешение

Управление серьезными инцидентами (в Atlassian эту задачу часто называют управлением инцидентами) — это процесс реагирования на незапланированное событие или прекращение обслуживания с целью возобновить предоставление услуги. Данный процесс реализуется командами DevOps и командами по эксплуатации ИТ.

Что такое крупный инцидент?

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

В каждой компании по-своему определяют аварийную ситуацию. В Atlassian мы разделяем ситуации на три уровня серьезности, при этом два самых тяжелых уровня (SEV 1 и SEV 2) соответствуют серьезным инцидентам.

Если предназначенный для клиентов сервис прекратил работу для всех клиентов Atlassian, такой инцидент имеет уровень SEV 1. Если такой сервис не работает только у некоторых клиентов, инцидент соответствует уровню SEV 2. Обе ситуации попадают в категорию серьезных инцидентов и требуют немедленного реагирования от наших команд управления инцидентами.

Любая проблема, которая не мешает основным задачам, имеет уровень SEV 3 и не является серьезным инцидентом.

Определение процесса управления крупными инцидентами

Жизненный цикл инцидента (иногда его называют процессом управления инцидентами) — это путь выявления, устранения, понимания и предотвращения повторения инцидента.

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

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

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

Процесс управления крупными инцидентами в Atlassian

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

Обнаружение

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

Когда инцидент доходит до наших команд, ему уже присвоен уровень SEV 1, 2 или 3. В Atlassian инциденты с уровнями SEV 1 и 2 принято считать серьезными, а SEV 3 — инцидентами с менее значительными последствиями.

Создание нового инцидента

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

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

Налаживание связи

Как только менеджер инцидентов получает оповещение, первое, что он делает, — сообщает, что работа над исправлением ситуации началась. Он меняет статус инцидента на «исправление» и настраивает каналы связи для команды.

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

Оценка

После оповещения менеджера инцидентов и открытия каналов связи нужно провести оценку инцидента.

Для начала наши команды должны ответить на следующие вопросы.

• Какое влияние инцидент оказывает на клиентов и сотрудников Atlassian?
• Что видят клиенты?
• Сколько клиентов затронуто? Несколько? Все?
• Когда начался инцидент?
• Сколько заявок в службу поддержки было отправлено по поводу этого инцидента?
• Нужно ли учесть что-то еще при определении уровня опасности или важности либо при определении подхода к разрешению инцидента? К таким факторам можно отнести проблемы безопасности, негативные отзывы в социальных сетях и т. д.

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

Отправка первых сообщений

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

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

Быстрая и точная коммуникация помогает укреплять и поддерживать доверие клиентов.

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

Эскалация

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

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

Делегирование

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

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

Отправка последующих сообщений

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

Проверяйте

Однако каждый инцидент требует уникального подхода. Именно поэтому на данном этапе процесса мы:

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

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

Решение

Согласно нашему справочнику по работе с инцидентами, инцидент считается разрешенным, «когда устранены текущие или потенциальные последствия для бизнеса».

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

Ретроспективы

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

Используйте шаблоны ретроспектив и возможности Jira Service Management, чтобы без труда создавать и экспортировать в Confluence отчеты по результатам ретроспективы инцидентов (с соответствующими хронологиями). Это поможет реагирующим лицам вместе с многофункциональными командами отслеживать дальнейшие действия и предотвращать повторение инцидентов в будущем.

Роли и обязанности

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

Менеджер инцидентов. Лицо, ответственное за надзор за разрешением инцидента.

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

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

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

Ответственный за социальные сети. Эксперт, ответственный за информирование об инциденте в социальных сетях.

Среди других стандартных ролей:

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

Комиссия по расследованию серьезных инцидентов. Группа, ответственная за расследование и управление изменениями.

Решение для управления инцидентами Jira Service Management позволяет последовательно пройти весь процесс реагирования, от составления графика дежурств и организации процесса оповещения до объединения усилий команд и проведения ретроспектив инцидентов.