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

Виды процессов управления инцидентами

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

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

Процесс управления инцидентами в ИТ

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

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

Шаги процесса управления инцидентами

Выявите инцидент и зарегистрируйте его

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

• Имя человека, сообщающего об инциденте
• Дата и время сообщения об инциденте
• Описание инцидента (что не работает или работает не так, как должно)
• Уникальный идентификационный номер, присвоенный инциденту, для отслеживания

Категория

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

Расставляйте приоритеты

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

Реагируйте

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

Процесс управления инцидентами в DevOps и SRE

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

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

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

Три принципа управления инцидентами в командах DevOps

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

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

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

Инструменты управления инцидентами

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

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