Что такое управление инцидентами?

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

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

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

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

При работе с инцидентом команде необходим план, который поможет:

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

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

Многие команды полагаются на более традиционные процессы управления инцидентами в ИТ, например описанные в сертификациях ITIL. Другие команды больше склоняются к таким процессам управления инцидентами, как DevOps или назначение инженера по техническому обеспечению надежности сайта (SRE).

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

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

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

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

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

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

• Первоначальная диагностика. В идеале команда поддержки первого уровня должна вести инцидент от его начала до закрытия, но если она не справляется, то должна собрать всю информацию и эскалировать команде следующего уровня.
• Эскалация. Получив данные об инциденте, следующая команда продолжит его диагностику, а если не справится, то эскалирует его следующей команде.
• Информирование. Команда должна регулярно информировать о ситуации внешних и внутренних заинтересованных лиц, на которых влияет инцидент.
• Изучение и диагностика. Этот этап продолжается вплоть до решения инцидента. Иногда команды могут привлечь внешние ресурсы или специалистов из других отделов для консультации и помощи в решении проблемы.
• Решение и восстановление. На этом этапе команда завершает диагностику и выполняет все необходимое, чтобы решить инцидент. Полное восстановление работоспособности может занять некоторое время, поскольку исправления (например, патчи для багов) могут требовать тестирования и развертывания уже после того, как будет найдено подходящее решение.
• Закрытие. Если инцидент был эскалирован, он возвращается в службу поддержки для закрытия. Закрывать инциденты могут только сотрудники службы поддержки. Это позволяет поддерживать высокое качество обслуживания и последовательность в решении проблем. Владелец инцидента должен связаться с лицом, сообщившим об инциденте, и убедиться, что найденное решение является удовлетворительным и инцидент действительно можно закрывать.

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

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

Преимущество подхода «кто разработал, тот и поддерживает» дает agile-командам необходимую гибкость, но при этом размывает границы при распределении ответственности. Менее структурированные процессы разработки повышают удобство и продуктивность работы команд DevOps, однако для управления инцидентами стоит разработать стандартные процессы. Тогда при возникновении инцидента ни у кого не будет вопросов, что делать дальше, можно будет отслеживать проблемы и фиксировать их решение.

• Дежурство по очереди. Обычно команды DevOps не назначают на дежурство конкретных специалистов, а создают график дежурств и распределяют между всеми участниками неприятную необходимость подскакивать среди ночи из-за возникшего инцидента.
• Ответственность за исправление собственного продукта. Суть принципа «кто разработал, тот и запускает» заключается в том, что лучший специалист для устранения сбоев в работе сервиса — тот, кто его разработал и знает досконально.
• Быстрая и ответственная разработка. Когда разработчики понимают, что именно им придется разбираться со сбоями, появляется стимул писать более качественный код.

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

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

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

• Отслеживание инцидентов. Каждый инцидент нужно отслеживать и регистрировать, чтобы в дальнейшем можно было выявлять закономерности при сравнении с другими инцидентами.
• Отдельный чат. Канал для обмена текстовыми сообщениями в реальном времени — основной инструмент совместной диагностики и устранения инцидента всей командой. Кроме того, это дает подробные данные для последующего анализа.
• Видеочат. Во многих случаях видеочат служит дополнением к текстовому. По видеосвязи команда может обсудить свои выводы и определить стратегию реагирования.
• Система оповещения. Такие инструменты, как Jira Service Management, интегрируются с системой мониторинга и управляют дежурствами и эскалациями.
• Инструмент ведения документации. Такие инструменты, как Confluence, могут использоваться для документирования текущего инцидента и ретроспективы после его устранения.
• Statuspage. Информирование клиентов и заинтересованных лиц внутри компании о ситуации с помощью Statuspage позволяет держать всех в курсе дела.