Close

Путь к успешному управлению инцидентами начинается здесь

Просмотр тем

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

Говоря о реагировании на инциденты, мы подразумеваем установленный в организации процесс реагирования на угрозы в сфере ИТ, такие как кибератаки, нарушения безопасности и сбои в работе сервера.

В других командах ИТ и DevOps этот процесс может называться «управлением серьезными инцидентами» или просто «управлением инцидентами».

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

В этой статье мы рассмотрим семь основных этапов реагирования на инцидент.

  1. Обнаружить инцидент
  2. Наладить каналы связи для команды
  3. Оценить воздействие и определить уровень опасности
  4. Общайтесь с клиентами
  5. Выполнить эскалацию инцидента правильным специалистам
  6. Распределить роли в команде реагирования на инцидент
  7. Разрешить инцидент
Рабочий процесс реагирования на инциденты

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

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

No matter how the incident is detected, your first step should be to record that a new incident is open in a tool for tracking incidents. In an incident management solution such as Jira Service Management, alerting and communication is integrated with your tracking tool.

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

One of the first things the incident manager (IM) does when they come online is set up the incident team's communication channels. The goal at this point is to establish and focus all incident team communications in well-known places, such as:

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

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

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

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

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

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

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

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

The next step typically is to assign a severity level.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sometimes the initial responders are the ones who resolve the incident. More often than not, those responders need to bring other teams into the incident by paging them using an alerting tool. With Jira Service Management, responders can take their pick as to what alerting method they use, or even use them all in one central location.

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

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

After a new incident responder is paged and comes online, the incident manager delegates a role to them. As It’s important they understand what's required of their role, and how to contribute to the incident team quickly and effectively.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

There are many moving parts to the incident response process. Keeping track of each step with seamless communication is easy with an incident management tool like Jira Service Management. Centralize alerts and unify teams with flexibility to resolve incidents quickly.

продолжение темы
Ретроспективы