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

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

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

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

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

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

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

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

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

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

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

Категория

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

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

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

Реагируйте

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

Инциденты, проблемы и изменения. В чем разница?

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

• Запрос на обслуживание — формальный запрос клиента, чтобы что-либо получить. Например, запрос на новый ноутбук.
• Инцидент — незапланированное прекращение предоставления или снижение качества ИТ-услуги. Например, веб-сайт перестает работать.
• Проблема — это основная причина инцидента. Например, неправильная настройка сервера. Чтобы у вас не было слишком много инцидентов, нужно держать все проблемы под контролем.
• Изменение — это действие, которое может быть выполнено в стандартной, нормальной или аварийной ситуации. Для изменения в стандартной ситуации есть прописанная процедура. Для изменения в нормальной ситуации должна быть подготовлена и одобрена отдельная процедура. Изменение в аварийной ситуации производится немедленно и в идеале сначала должно быть протестировано.

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

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

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

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

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

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

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

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

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

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

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