КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Первая, вторая и п-линия поддержкиЭскалация
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента. Различают функциональную и иерархическую эскалацию: ü Функциональная эскалация (горизонтальная) — означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения. ü Иерархическая эскалация (вертикальная) — означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Выше была изложена маршрутизация инцидента, пли функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. ü Первой линией поддержки (называемой также поддержкой 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, как «владелец» всех инцидентов. Эта служба должна также информировать пользователя о состоянии инцидента.
Ø Обратная связь с пользователем может быть уместной после изменения статуса, например, направлении инцидента на следующую линию поддержки, изменении расчетного времени решения, эскалации и т. д.
Ø Во время мониторинга возможна функциональная эскалация к другим группам поддержки или иерархическая эскалация для принятия руководящих решений.
Дата добавления: 2014-01-11; Просмотров: 314; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |