Шрифт:
Эскалация
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
• Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
• Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Первая, вторая и n-линия поддержки
Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.
Рис. 4.3. Эскалация инцидента (источник: OGC)
4.2. Цель
Целью Процесса Управления Инцидентами является скорейшее восстановление нормального Уровня Услуг, определенного в Соглашении об Уровне Услуг (Service Level Agreement – SLA), с минимальными возможными потерями для бизнес-деятельности организации и пользователей. Кроме того, Процесс Управления Инцидентами должен вести точную регистрацию инцидентов для оценки и совершенствования процесса и предоставления необходимой информации для других процессов.
4.2.1. Преимущества использования процесса
• Для бизнеса в целом:
– своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;
– повышение производительности работы пользователей;
– независимый, ориентированный на потребности заказчика мониторинг инцидентов;
– доступность объективной информации о соответствии предоставляемых услуг согласованным договоренностям (SLA).
• Для ИТ-организации:
– улучшенный мониторинг, позволяющий проводить точное сопоставление уровня производительности ИТ-систем с соглашениями (SLA);
– эффективное руководство и мониторинг выполнения соглашений (SLA) на основе достоверной информации;
– эффективное использование персонала;
– предотвращение потерь инцидентов и Запросов на Обслуживание или их неправильной регистрации;
– повышение точности информации в Конфигурационной Базе Данных (Configuration Management Database – CMDB) за счет ее проверки при регистрации инцидентов в привязке к Конфигурационным Единицам (Configuration Item – CI);
– повышение удовлетворенности пользователей и заказчиков.
Отказ от использования Процесса Управления Инцидентами может привести к следующим отрицательным последствиям:
• инциденты могут быть потеряны или, наоборот, необоснованно восприняты как чрезвычайно серьезные из-за отсутствия ответственных за мониторинг и эскалацию, что может привести к снижению общего уровня обслуживания;
• пользователи могут перенаправляться к одним и тем же специалистам «по кругу» без успешного разрешения инцидента;
• специалисты могут постоянно отрываться от работы телефонными звонками пользователей, из-за чего им становится трудно эффективно выполнять свою работу;
• могут возникать ситуации, когда несколько человек будут работать над одним и тем же инцидентом, непродуктивно теряя время, и примут противоречивые решения;
• может ощущаться недостаток информации о пользователях и предоставляемых услугах, необходимой для принятия руководящих решений;
• из-за указанных выше возможных проблем затраты компании и ИТ-организации на поддержку услуг будут выше, чем реально требуется.
4.3. Процесс