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

Эскалация

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

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

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

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

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

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

ü Первой линией поддержки (называ­емой также поддержкой 1-го уровня) обычно является Служба Service Desk,

ü второй линией — подраз­деления, осуществляющие Управление ИТ-инфраструктурой,

ü третья — отделы разработки и архитек­туры программного обеспечения, и

ü четвертая — поставщики.

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

3.4. Привязка (или сопоставление — Matching)

— проверяется, не является ли инцидент уже извест­ным инцидентом или известной ошибкой, нет ли для него уже открытой проблемы, и нет ли для него известного решения или обходного пути.

3.5. Расследование и диагностика (Investigation and Diagnosis)

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

Ø Служба Service Desk или группа поддержки направляет инциденты, не имеющие готового решения или выходящие за пределы компетенции работающего с ним сотрудника, группе поддержки следую­щего уровня с большим опытом и знаниями. Эта группа исследует и разрешает инцидент или напра­вляет его группе поддержки очередного уровня.

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

3.6. Решение и восстановление (Resolution and Recovery)

Ø если решение найдено, то работа может быть восстановлена.

Ø В некоторых случаях необходимо направить Запрос на Изменение (RFC) в Процесс Управления Изменениями.

Ø В наихудшем случае, если не найдено никакого решения, инцидент остается открытым.

3.7. Закрытие (Closure)

Ø с пользователем связываются, чтобы он подтвердил согласие с предложен­ным решением, после чего инцидент может быть закрыт.

Ø При закрытии инцидента необходимо обновить данные об окончательной кат егории, приоритете, сервисах (услугах), подвергшихся воздействию инцидента и Конфигурационной Единице (CI), вызвавшей сбой.

3.8. Мониторинг хода работ и отслеживание (Progress monitoring and Tracking)

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

Ø В большинстве случаев ответственной за мониторинг хода решения является Служба Service Desk, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента.

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

Ø Во время мониторинга возможна функциональная эска­лация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.