Степень юздействия

Срочность

Приоритет

Расчет:

•люди

•ресурсы

•время

Рис. 4-2. Определение степени воздействия, срочности и приоритета

СтснеШ) воздействия и срочность также могут сами меняться во времени, например при росте kojhi-чества пользователей, подвергшихся воздействию инцидента или в критические моменты времени.

Степень воздействия и срочность могут быть объединены в мат])ицу, наирмер, как показано в т-абл. 4.1.

СТЕПЕНЬ ВОЗДЕЙСТВИЯ

Таблица 4 1. Пример системы кодирования приоритетов Эскалация

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

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

•Функциональная эскалация (горизонтальная) - означает привлечение 6ольи1сго количества специалистов НЛП предоставление дополнительных прав доступа для ])азреп1е1Н1Я инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подра.зделеиня.

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

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

Первая, вторая и п-лииия поддержки

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

4. УПРАВЛеИИё ИНЦИДЕНТАМИ

стью II линейными организационными подразделениями. Каждый из иих координирует деятельность собственных групп по;у1ержки. Процедура эскалации графически представлена на рис. 4.3.

Первая линия помержки

Вторая линия помержки

Обнаружение и региарация

Классификация, началжая помержка

Привязка

Разрешение

Закрытие инцидента

Рис. 4.3. Эскалация инцидента (источник: OGC)

4.2. Цель

Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, оиределенного в Соглашении об Уровне Услуг (Service Level Agreement - SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кро.ме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.

4.2.1. Преимущества использования процесса

• Для бизнеса в целом:

-своевременное разрешение инцидентов. ведуи1ее к уменьшению потерь для бизнеса;

-повышение производительности работы пользователей;

-независимый, ориентированный на потребности заказчика мониторинг инцидентов;

-доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностя.м (SLA).

• Для ИТ-организации:

-улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);

-эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;

-эффективное использование персонала;

-предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;

-повышение точности информации в Кон(})игурационной Базе Данных (Configuration Management Database - CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфи-1-урационным Единицам (Configuration Item - CI);

-повышение удовлетворсности пользователей и заказчиков.

4. УШАШАЕНШ ИНеДИДЕНТАМИ

Отказ от использопапня Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:

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

•пользователи могут перенаправляться к одним и тем же cnenHajuicTaM «по кругу» без успешного разрешения И1ии1дента;

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

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

•может ои1ущаться недостаток информации о пользователях и предоставляемых услугах, необходимой для принятия руководящих решений;

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

4.3. Процесс

На рнс. 4.4 показаны входы и выходы процесса, а также виды деятельности, которые охватывает этот процесс.

Служба Service Desk

инциденты

Контроль работы серверов

Контроль работы компьютерных сетей

Процедуры

Друше источники инцидентов

Выходы: решения (resolution) и обходные п/ти (work-arourvj)

Запросы на

обслуживание

маршрутизация и ллониторинг ▼

Данные об

Детальная информация о Конфигурации

Конфигурационная База Данных (CMDB)

Рис. 4.4. Положение Процесса Управления Инцидентами