Закрыть
Справочник Atlassian по инцидентам

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

Caution alert exclamation point

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

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

Workflow of Atlassian incident response from new to fixing to resolved
Book illustration with a light bulb over it

Обзор

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

Illustration of different kinds of charts

Разбор инцидентов

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

Выявление

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

Мы используем запоминающиеся короткие URL, которые перенаправляют сотрудников Atlassian на внутренний портал Jira Service Desk. Сотрудники Atlassian могут проверить, не взят ли уже данный инцидент в работу, посмотрев на доску Jira или на макрос Jira в Confluence. У команд (например, у команды службы поддержки) есть установленные в общеизвестных местах доски, которые они используют для мониторинга текущих инцидентов.

Для каждого инцидента мы заполняем следующие поля.

Поле Jira

Тип

Текст справки

Summary

Текст

В чем заключается экстренная ситуация?

Description

Текст

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

Опасность

Список (однозначный выбор)

(Гиперссылка на страницу Confluence со шкалой опасности.) Выбор уровня опасности 2 или 1 означает, что, по вашему мнению, данная проблема должна быть решена немедленно. Это приводит к автоматическому уведомлению ответственных сторон.

Неисправный сервис

Список (однозначный выбор)

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

Затронутые продукты

Флажки

Какие продукты затрагивает этот инцидент? Выберите все подходящие варианты.

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

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

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

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

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

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

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

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

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

  • Чат в Slack или другом сервисе обмена сообщениями. Он позволяет команде общаться, делиться наблюдениями, ссылками и снимками экрана. При этом каждое сообщение снабжается временной отметкой и сохраняется. В качестве имени каналу чата присваивается ключ задачи (например, HOT-1234), что позволяет людям, которым требуется участвовать в решении задачи, проще присоединяться к обсуждению. 

  • Видеочат в приложении для проведения конференций, например Skype, Blue Jeans и т. п. А если вы находитесь в одном офисе, можно собрать команду в реальной комнате. Мы считаем, что общение лицом к лицу помогает командам решать вопросы быстрее и сокращает споры.

  • Страница Confluence под названием «Документ состояния инцидента». Когда участники одновременно редактируют одну и ту же страницу, они видят собираемую информацию в режиме реального времени. Это отличный способ отслеживания изменений (например, можно создать таблицу, показывающую, кто и что изменил, когда, как, почему, как вернуться к предыдущей версии и т. д.). Можно также отслеживать несколько потоков работ или просматривать расширенный график. Документ состояния инцидента является очень полезным источником достоверной информации во время сложных или масштабных инцидентов.

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

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

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

  • описание и уровень опасности инцидента;

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

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

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

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

Оценка

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

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

  • Каковы последствия для клиентов (внутренних или внешних)?

  • Что видят клиенты?

  • Сколько клиентов затронуто (некоторые, все)?

  • Когда это началось?

  • Сколько заявок в поддержку отправили клиенты?

  • Присутствуют ли другие факторы, например сообщения в Twitter, угрозы безопасности или потери данных?

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

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

Опасность

Description

Examples

1

Критически опасный инцидент с очень большими последствиями

  • Предназначенный для клиентов сервис, например Jira Cloud, не работает у всех клиентов.

  • Нарушена конфиденциальность или защита данных.

  • Потеряны данные клиентов.


2

Серьезный инцидент со значительными последствиями

  • Предназначенный для клиентов сервис недоступен части клиентов.

  • Есть существенное влияние на основные функциональные возможности (например, git push, создание задач).

3

Несерьезный инцидент с незначительными последствиями

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

  • Снижение производительности, не препятствующее использованию сервиса.

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

В Atlassian инциденты с уровнем опасности 3 передаются командам доставки для устранения в рабочее время, а инциденты опасности 1 и 2 требуют отправки сообщений участникам команды для немедленного исправления. Разница в порядке реагирования на инциденты с уровнем опасности 1 и 2 является более тонкой и зависит от затронутого сервиса.

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

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

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

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

 

Внутренняя страница Statuspage

Внешняя страница Statuspage

Имя инцидента

<Ключ задачи по инциденту> - <Опасность> - <Описание инцидента>

Исследование проблем, связанных с <продукт>

Сообщение

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

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

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

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

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

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

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

Важнейшей системой на этом этапе является средство оповещения и рассылки сообщений, например 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 обрабатываемых вами инцидентов часто является важной бизнес-метрикой.

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

Book illustration with a light bulb over it

Обзор

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

Illustration of different kinds of charts

Разбор инцидентов

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

Ищете инструмент, который поможет организовать процесс управления инцидентами?