Семь стадий эффективного реагирования на инцидент

Обнаружить инцидент

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

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

Наладить каналы связи для команды

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

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

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

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

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

Оценить воздействие и определить уровень опасности

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

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

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

Затем, как правило, назначают уровень опасности.

Уровни опасности, применяемые в рамках реагирования на инциденты

Уровень опасности 1
Описание: критический инцидент с очень большими последствиями.
См. примеры ниже.

• Предназначенный для клиентов сервис не работает у всех пользователей.
• Нарушена конфиденциальность или защита данных.
• Потеряны данные клиентов.

Уровень опасности 2
Описание: серьезный инцидент со значительными последствиями.
См. примеры ниже.

• Предназначенный для клиентов сервис недоступен для части клиентов.
• Существенно затронуты основные функциональные возможности.

Уровень опасности 3
Описание: несерьезный инцидент с незначительными последствиями.
См. примеры ниже.

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

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

С помощью уровней опасности также можно дать понять, какие ожидаются меры по реагированию.

Например, в некоторых компаниях инциденты с уровнем опасности 3 можно устранять в рабочее время, а в случае инцидентов с уровнями опасности 1 и 2 необходимо, чтобы участники команды сию же минуту принялись работать над исправлением.

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

Общайтесь с клиентами

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

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

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

Мы используем Statuspage для внутренней и внешней коммуникации об инцидентах. Приведем два простых шаблона для обновления внутренней или внешней страницы статусов.

Внутренняя страница Statuspage
<Ключ задачи по инциденту> - <Уровень опасности> - <Описание инцидента>

Мы исследуем инцидент, затрагивающий <продукт X>, <продукт Y> и <продукт Z>. Скоро мы предоставим оперативную информацию через электронную почту и Statuspage.

Внешняя страница Statuspage
Расследование проблем, связанных с <продуктом>

Мы уже работаем над проблемами, связанными с <продуктом>, и скоро предоставим здесь оперативную информацию.

Выполнить эскалацию инцидента правильным специалистам

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

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

Распределить роли в команде реагирования на инцидент

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

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

Три ключевые роли в команде реагирования на инциденты

Менеджер инцидента

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

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

Технический руководитель

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

Менеджер по коммуникациям

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

Разрешить инцидент

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

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

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

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

Заключение

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