Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL Страница 12

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

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

Эскалация

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

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

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

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

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

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

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

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

4.2. Цель

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

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

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

? своевременное разрешение инцидентов, ведущее к уменьшению потерь для бизнеса;

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

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

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

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

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

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

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

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

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

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

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

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

? пользователи могут перенаправляться к одним и тем же специалистам "по кругу" без успешного разрешения инцидента;

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

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

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

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

4.3. Процесс

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

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

4.3.1. Входы процесса

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

4.3.2. Управление конфигурациями

Конфигурационная База Данных (Configuration Management Database - CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользо­вателями и Уровнями Услуг (сервисов). Например, Управление Конфигурациями показывает, кто является ответственным за компонент инфраструктуры, что делает возможным более эффективное распределение инцидентов по группам специалистов. Кроме того, эта база данных помогает решать оперативные вопросы, например, перенаправление очереди печати или переключение пользователя на другой сервер. При регистрации инцидента в регистрационные данные добавляется связь (link) с соответствующей Конфигурационной Единицей (Configuration Item – CI), позволяющая предоста­вить более подробную информацию об источнике ошибки. В случае необходимости может быть об­новлен статус соответствующей компоненты в CMDB.

4.3.3. Управление Проблемами

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

4.3.4. Управление Изменениями

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

4.3.5. Управление Уровнем Услуг

Управление Уровнем Услуг контролирует выполнение договоренностей (соглашений – SLA) с за­казчиком о предоставляемой ему поддержке. Сотрудники, участвующие в Управлении Инцидента­ми должны хорошо знать эти соглашения, чтобы использовать необходимую информацию при кон­тактах с пользователями. Кроме того, регистрационные данные об инцидентах требуются при соста­влении отчетов для проверки выполнения согласованного Уровня Услуг.

4.3.6. Управление Доступностью

Для определения показателей доступности услуг Процесс Управления Доступностью использует ре­гистрационные данные об инцидентах и данные мониторинга статуса, предоставляемые Процессом Управления Конфигурациями. Аналогично Конфигурационной Единице (CI) в Конфигурационной Базе Данных (CMDB), сервису (услуге) может быть также назначен статус "не работает"[67]. Это мо­жет быть использовано для проверки действительных показателей доступности услуги и времени реагирования поставщика. При осуществлении такой проверки необходима фиксация времени дей­ствий, произошедших в процессе обработки инцидента, от момента обнаружения и до закрытия.