Реагирование на инцидент

Выявление

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

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

Если задача по инциденту создана, но еще не назначена менеджеру инцидента (IM), статус инцидента отображается как новый. Это первоначальный статус в нашем процессе обработки инцидента в Jira.

У нас есть сервис, который с помощью интеграций Jira отправляет оповещения о создании нового серьезного инцидента. Этот сервис оповещает дежурного IM в соответствии с выбранным сервисом. Например, в случае инцидента с Bitbucket будет отправлено сообщение менеджеру инцидентов Bitbucket. У нас также есть глобальный реестр всех менеджеров серьезных инцидентов, которых мы называем «дежурными менеджерами инцидентов» (IMOC).

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

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

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

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

• Чат в Slack или другом сервисе обмена сообщениями. Он позволяет команде общаться, делиться наблюдениями, ссылками и снимками экрана. При этом каждое сообщение снабжается временной отметкой и сохраняется. В качестве имени каналу чата присваивается ключ задачи (например, HOT-1234), что позволяет людям, которым требуется участвовать в решении задачи, проще присоединяться к обсуждению.
• Видеочат в приложении для проведения конференций, например Skype, Blue Jeans и т. п. А если вы находитесь в одном офисе, можно собрать команду в реальной комнате. Мы считаем, что общение лицом к лицу помогает командам решать вопросы быстрее и сокращает споры.
• Страница Confluence под названием «Документ состояния инцидента». Когда участники одновременно редактируют одну и ту же страницу, они видят собираемую информацию в режиме реального времени. Это отличный способ отслеживания изменений (например, можно создать таблицу, показывающую, кто и что изменил, когда, как, почему, как вернуться к предыдущей версии и т. д.). Можно также отслеживать несколько потоков работ или просматривать расширенный график. Документ состояния инцидента является очень полезным источником достоверной информации во время сложных или масштабных инцидентов.

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

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

Большинство систем для чата имеют возможность установки темы комнаты. IM обновляет тему комнаты, добавляя информацию об инциденте и полезные ссылки, в том числе:

• описание и уровень опасности инцидента;
• кто и какую роль выполняет, начиная с IM;
• ссылки на задачу по инциденту, комнату видеочата и документ состояния инцидента.

Это позволяет любому участнику, знающему ключ задачи этого инцидента, присоединиться к чату и быстро приступить к работе над инцидентом (напоминаем, что в качестве имени канала чата мы используем ключ задачи инцидента, например HOT-1234).

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

Оценка

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

У нас есть следующий список вопросов, которые ИМ задают своим командам.

• Каковы последствия для клиентов (внутренних или внешних)?
• Что видят клиенты?
• Сколько клиентов затронуто (некоторые, все)?
• Когда это началось?
• Сколько заявок в поддержку отправили клиенты?
• Присутствуют ли другие факторы, например сообщения в Twitter, угрозы безопасности или потери данных?

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

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

Отправка первых комментариев

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

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

Подключение дополнительных специалистов

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

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

Важнейшей системой на этом этапе является средство оповещения и рассылки сообщений, например OpsGenie. OpsGenie и аналогичные системы позволяют определить список дежурных сотрудников, чтобы в каждой команде была доступна для связи группа сотрудников, которая в определенный период отвечает за реагирование на экстренные ситуации. Такой подход лучше, чем постоянная зависимость от конкретного лица («опять нужен Боря»), поскольку конкретные лица не могут быть постоянно доступны: люди имеют обыкновение брать отпуск, менять работу или выгорать, если их вызывают слишком часто. Этот подход также оказывается более удачным, чем вызов сотрудников по принципу «кто доступен», поскольку он обеспечивает ясное представление, кто сейчас отвечает за реагирование.

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

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

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

В Atlassian мы используем следующие роли.

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

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

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

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

Отправка дополнительных комментариев

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

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

Для внутренней коммуникации мы придерживаемся следующей схемы.

• Мы общаемся через внутреннюю страницу Statuspage и электронную почту, как описано выше в разделе о первых сообщениях.
• Используйте один и тот же формат для имени инцидента и темы электронных сообщений (<ключ задачи по инциденту> - <опасность> - <описание инцидента>).
• Начните с описания текущего состояния и последствий (1–2 предложения).
• Раздел «Текущий статус» в виде списка из 2–4 пунктов.
• Раздел «Следующие шаги» в виде списка из 2–4 пунктов.
• Укажите, когда и куда будет отправлен следующий цикл сообщений.

Для проверки полноты сообщений мы отвечаем на вопросы из следующего контрольного списка.

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

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

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

Для внешней коммуникации мы просто обновляем инцидент, который мы ранее создали на внешней странице Statuspage, меняя его статус по мере необходимости. Мы стараемся делать обновления краткими и благозвучными, поскольку внешним клиентам не интересны технические детали инцидента: они просто хотят знать, исправлена ли проблема, а если нет, то когда она будет исправлена. Как правило, 1–2 предложений будет достаточно.

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

Проверяйте

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

• Наблюдаем за происходящим. Обмениваемся наблюдениями и подтверждаем их.
• Разрабатываем теории о том, почему это происходит.
• Разрабатываем эксперименты, которые доказывают или опровергают эти теории. Проводим их.
• Повторяем снова.

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

Самые большие проблемы для IM на этом этапе связаны с поддержанием дисциплины в команде.

• Эффективно ли общаются между собой участники команды?
• Каковы текущие наблюдения, теории и потоки работ?
• Эффективно ли мы принимаем решения?
• Мы действительно вносим изменения сознательно и осторожно? Осознаем ли мы, какие изменения вносим?
• Ясны ли роли? Выполняют ли люди свою работу? Нужно ли нам подключать к проблеме дополнительные команды?

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

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

Решение

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

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

В Atlassian мы используем настраиваемые поля Jira, чтобы отслеживать для каждого инцидента время начала последствий, время его обнаружения и время окончания последствий. С помощью этих полей мы рассчитываем время до восстановления (TTR), т. е. интервал между началом и окончанием, и время до обнаружения (TTD), т. е. интервал между началом и моментом обнаружения. Распределение TTD и TTR обрабатываемых вами инцидентов часто является важной бизнес-метрикой.

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

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