Записаться

Управление инцидентами: операционная часть, метрики и роли

1. Расследование, диагностика и закрытие инцидента

Расследование и диагностика инцидента — работа творческая и не регламентируется бизнес-процессом. Процессом регулируется только обновление статусов по мере изменения местонахождения и состояния инцидента, а также информирование пользователя.

После решения инцидента, если требуются серьёзные изменения в системе, формируется запрос на изменение (Request for Change, RFC). Он передаётся в процесс управления изменениями (Change Management). Процесс управления инцидентами на время отвязывается от инцидента.

Управление изменениями оценивает влияние решения, определяет необходимые изменения, согласует их с релизами (release) и выполняет работу. Когда изменения отработаны, управление изменениями сообщает, что инцидент разрешён. После этого процесс управления инцидентами уведомляет пользователя. Пользователь проверяет результат, и инцидент закрывается.

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

2. Операционное описание процесса

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

3. Метрики: что измерять и зачем

В ITIL (Information Technology Infrastructure Library) приведены примеры метрик для управления инцидентами. Их много, но перечень неполный: можно предложить и другие. ITIL показывает, что можно измерить при данном процессе, но не объясняет, зачем это нужно.

Пример: измеряется среднее время разрешения инцидентов по приоритетам. Если высокоприоритетные инциденты разрешаются медленно, это может означать:

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

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

Например, зачем измерять среднее время разрешения высокоприоритетных инцидентов? Чтобы принять решение:

• о дополнительных инвестициях в IT-персонал;
• об инвестициях в инфраструктуру;
• о замене оборудования или программного обеспечения.

Авторы ITIL не описали эту логику, потому что в момент создания документа ещё не было общепринятого понимания иерархии целей и связи IT-целей с бизнес-целями. Такая систематическая работа появилась позже. Но то, что авторы заранее предложили измеримые характеристики процесса, говорит о высоком качестве документа.

4. Роли в процессе управления инцидентами

Основная роль — руководитель процесса управления инцидентами. Он управляет процессом и отвечает за его развитие и сопровождение. Речь идёт не только о процессе, но и о системе управления инцидентами, включая информационную систему для регистрации инцидентов, назначения приоритетов и другой автоматизации.

Типичные функции руководителя:

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

ITIL не определяет, кто именно должен быть руководителем. Это решение организации. Это может быть:

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

Также в процессе участвует персонал групп поддержки — коллективный администратор. Эти сотрудники выполняют процесс и обеспечивают его работоспособность и эффективность.

Краткие итоги

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

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

Метрики сами по себе не дают ответа на вопрос, что делать. Среднее время разрешения, количество эскалаций или распределение по приоритетам становятся полезными только в контексте цели. Если цель — повысить доступность сервиса, одни решения будут приоритетными; если цель — снизить нагрузку на персонал, другие. Без явной цели показатели легко превращаются в самоцель или в инструмент давления. Отсюда практический вывод: сначала формулируется желаемый результат, затем выбирается метод, и только потом подбираются измерения, которые подтверждают или опровергают выбранный курс.

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