Управление инцидентами - 2

Записаться

Приоритет инцидента

Приоритет (priority) — важная, но условная характеристика. В рамках ITIL (IT Infrastructure Library) его нужно назначать каждому инциденту. Приоритет зависит не только от актива, вызвавшего сбой, но и от информации, людей, бизнес-приложения, времени разрешения, соглашения об уровне обслуживания (SLA, Service Level Agreement) и роли пользователя или заказчика.

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

Воздействие и срочность

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

Важнейший источник информации для приоритета — SLA. Также важен пользователь или заказчик: один и тот же сбой может иметь разное значение в зависимости от того, кого он затрагивает.

Регистрация и эскалация

Инцидент может быть решён сервис-деском (service desk). Если это невозможно, инцидент передаётся на следующую линию поддержки. При регистрации фиксируются номер, приоритет, время возникновения и источник инцидента. Эти данные нужны для статистики и дальнейшего анализа.

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

Функциональная и иерархическая эскалация

Функциональная эскалация (functional escalation) — привлечение дополнительных специалистов внутри линии поддержки или из соседних подразделений.

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

Руководитель процесса управления инцидентами должен заранее предусматривать эскалации, распределять ответственность, согласования и ресурсы.

Линии поддержки

Примеры линий поддержки:

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

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

Ответственность и координация

Каждая линия поддержки — это структурное подразделение. Его возглавляет ответственный менеджер, который отвечает за качество работы линии. Но кто-то должен отвечать за сквозной процесс.

Последовательность работ включает обработку, назначение приоритета, регистрацию, эскалацию по линиям, разрешение, информирование пользователя, достижение договорённости о successful разрешении и закрытие инцидента. За всю эту последовательность может отвечать координатор инцидентов (incident coordinator). Координаторов может быть несколько. Они могут работать в ИТ-департаменте или в бизнес-структурах. Бизнес-подразделение может мониторить инциденты и взаимодействовать с ИТ не в терминах отдельных инцидентов, а в терминах их совокупности.

Источники обнаружения инцидентов

Инцидент может быть обнаружен:

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

Пример системного обнаружения: монитор занятости дискового пространства показывает, что на сервере базы данных остаётся всё меньше свободного места. Через некоторое время сервер может перестать отвечать на запросы. Это инцидент, вызванный системой.

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

Цель и место процесса

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

Описание процесса похоже на нормальный бизнес-процесс. В центре перечислены действия процесса. Слева — входы, справа — процессы, с которыми происходит обмен информацией. Внизу — конфигурационная база данных (CMDB, Configuration Management Database), к которой процесс обращается для понимания причин и последствий инцидента. Сверху отдельно показан инцидент или запрос на обслуживание (service request). Архитектура напоминает IDEF0: процесс, механизмы, входы и выходы.

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

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

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

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