Процесс управления инцидентами (Incident Management)

Инцидент (incident или INC) — любое событие (сбои, запросы на консультации и т.п,), не являющееся частью нормальной работы услуги, ведущее/способное привести к остановке услуги или снижению уровня её качества.

Цель процесса управления инцидентами — скорейшее восстановление нормального функционирования сервиса в соответствии с Соглашением об уровне услуг и минимизация воздействия отказа на жизнедеятельность бизнеса.

Для успешного управления инцидентами необходимо создание диспетчерской службы (Service desk), которая должна являться единой точкой контакта с пользователями и координирует устранение инцидентов. Service Desk — подразделение (в терминологии ITIL «функция»), обеспечивающее единую и единственную точку входа для всех запросов конечных пользователей и унифицированную процедуру обработки запросов.

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

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

Различают функциональную и иерархическую эскалацию:

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

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

Маршрутизация инцидента, или функциональная эскалация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки.

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

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

Hank Marquis предлагает 6 основных аспектов процесса управления инцидентами:

Создание базы данных записей обо всех инцидентах. Необходимо фиксировать все возникающие инциденты, независимо от способа их поступления (электронная почта, телефонный звонок, факс и т.д.). Вся информация о ходе решения инцидента так же должна фиксироваться в базе данных.
Создание базы знаний, где будет содержаться дополнительная информация для разрешения инцидента. Чем больше информации, тем лучше. В ITIL это базы данных управления конфигурацией (CMDB ) и/или системы управления конфигурацией (CMS).
Разработайте и утвердите четкие инструкции и правила обработки инцидентов (регистрация, классификация, определение приоритета, анализа и т.д.).
Определите, в привязке к SLA, процедуры, которые позволят вам управлять воздействием (impact) инцидента на бизнес.
Создайте модель «основного инцидента» – набор правил четко описывающих очень серьёзный инцидент. Под основным инцидентом понимается такой, который затрагивает критичный бизнес-сервис и/или большое количество заказчиков и пользователей. В любом случае, основной инцидент требует немедленной эскалации, уведомления заказчиков и другой специальной обработки. Вся суть заключается в том, что такой инцидент требует максимальной реакции со стороны ИТ-организации.
Информируйте тех, кто сообщил вам об инциденте, о статусе работ. Вам необходимо представлять, кому и как часто необходимо направлять информацию. Например, Вы можете уведомить об инциденте заказчиков и пользователей. Вы должны также проинформировать их о невозможности вернуть уровень предоставляемого сервиса к согласованным параметрам в согласованное время.

Если у вас не реализован хотя бы один из этих 6 пунктов, то, в соответствии со стандартом ISO/IEC 20000-1 (Service Management), сфокусировавшись на нем, вы сможете улучшить качество сервиса. Если же все пункты у вас реализованы, то, скорее всего, вам уже не нужно тратить много времени на внедрение процесса управления инцидентами – сосредоточьтесь на других областях ITIL, таких как Управление проблемами (Problem Management) или Управление изменениями (Change Management).

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

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

Примеры Запросов на Обслуживание:

вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;
запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;
запрос о замене пароля;
запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;
получение информации из базы данных.

Для того чтобы можно было отличить «настоящие инциденты» от «инцидентов-Запросов на Обслуживание«, рекомендуется присваивать Запросам на Обслуживание специальную категорию.

При одновременной обработке нескольких инцидентов необходимо расставлять приоритеты. Обоснованием для назначения приоритета служит уровень важности ошибки для бизнеса и для пользователя. На основе диалога с пользователем и в соответствии с положениями Соглашений об Уровнях Услуг (Service Level Agreements – SLAs) Служба Service Desk назначает приоритеты, определяющие порядок обработки инцидентов. При эскалации инцидентов на вторую, третью или более линии поддержки, тот же приоритет должен быть соблюден, но иногда он может быть скорректирован по согласованию со Службой Service Desk.

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

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

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