назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [ 17 ] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


17

Услуп! (сервисы)

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

Группа поддержки

Если Служба Service Desk не может разрешить ингшдент незамедлительно, то определяется группа поддержки, которая будет заниматься разрсчпением инцидента. Основой для распределения (марш-

При регисграции инцидента производятся следующие действия:

•Назначение номера инцидента: в больиниютве случаев система автоматически назначает новый (уникальный) номер инцидента. Часто этот номер сообщается пользователю, чтобы ои мог ссылаться на него при дальнейших контактах.

. Запись базовой диагностической И!1формацин: время, признаки (симигомы), пользователь, сотрудник, принявший вопрос в обработку, место произошедшего ипщадеита и информация о затронутой услуге и/или технических средствах.

•Запись дополнительной информации об инциденте: добавляется информация, например, из скрипта (script) или процедуры опроса или из Конфигурационной Вазы Данных - CMDB (обычно на основе взаимоотношений Конфигурационных Единиц, определенных в CMDB).

•Объявление сигнала тревоги: если происходит инщадент, имеюпииг высокую степень воздействия, например, сбой важного сервера, производится предупреждение других пользователей и руководства.

4.4.2. Классификация

Классификация инцилептов направлена на определение его категории для облегчения мониторинга и составления отчетов. Желательно, чтобы опции классификации были как можно ишре, но при этом требуется более высокий уровень ответственности персонала. Иногда пытаются объединить в одном перечне несколько аспектов классификации, таких, как тип, группа поддерлски и источник. Это часто вносит путаницу. Лучнге использовать несколько коротких пе1)ечней. В данном разделе рассматр[шаются вопросы, относяпщеся к классификации.

Категория

Прежде всего, инцидентам присваивается категория и подкатегория, например, исходя из предполагаемого источника инцидента или соответствующей фуппы поддержки:

•Центральная процессинговая система - подсистема доступа, центральный сервер, приложение.

•Сеть - маршрутизаторы, сегменты, концентратор (hub), IP-адреса.

•Рабочая станция - монитор, сетевая карта, дисковод, клавиатура.

•Использование и функциональноегь - услуга (сервис), возможности системы, досгупность, резервное копирование (back-up), документация.

•Организация и процедуры - заказ, запрос, по/щержка, оповещение (коммуникатш).

•Запрос на Обслуживание - запрос пользователя в Службу Service Desk на поддержку, предоставление ипформатщи, документации или оказание консультации. Это может быть выделено в отдельную процедуру или обработано таким же образом, как реальный инцидент.

Приоритет

После :ш)го назначается приоритет, чтобы быть уверенными, что группа поддержки уделит шищ-денту необходимое внимание. Приоритет - это номер, определяюицн"1СЯ срочностью (насколько быстро это должно быть исправлено) и степенью воздействия (какой yniep6 будет нанесен, если не исправить быстро).

Приоритет = Срочность х Степень воздействия.



рутнзации) мацидентов часто является 1111(})ормация о категориях. При определении категорий может потребоваться рассмотрение структуры групп поддержки. Правильное распределение инцидентов имеет существенное значение для эффективности Процесса Управления Иищшепталги. Поэтому одним из ключевых показателей эф(1)сктнвности (KPI) Процесса Управ.те1И1я Инцидентами может быть число неправильно распределенных обращений.

Сроки решения

С учетом приоритета и соглапгения SLA пользователь информируется о максимальном расчетном времени разренгения инцидеггга. Эти сроки также фиксируются в системе.

Идентификационный но.мер инцидента

Абонент информируется о номере тппщдента для его точной идентифика)ии1 при последуюпцтх обращениях.

Статус

Статус шидадента указывает на его положение в процессе обработки инцидента. Примерами статусов могут быть:

•новый;

•принят;

•запланиро)шн;

•назначен;

•активный;

•отложен;

•разрешен;

•закрыт.

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

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

4.4.4.Расследование и диагностика

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

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

4.4.5.Решение и восстановление

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

4.4.6.Закрытие

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

Key Perfofimance Indicators - KPI.



4. VFIPAisA-gUMe ИтИАШГАШ

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

4.4.7. Мониторинг хода решения и отслеживание

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

4.5. Контроль процесса

Осногюй контроля процесса являются отчеты для различных целевых групп. Руководитель Процесса Уп1)авления Инцидентами является ответстве1П1ЫМ за эти отчепл, а также за составление списка рассылки и гра(1)ика составления отчетов. Отчеты могут включать специализированную информацию для следующих функциональных 1юдразделений:

•Рзководителю Процесса Управления Инцидентами отчет необходим для:

-идентификации недостающих звеньев процесса;

-идснтификащп! нарупгений нсполнения соглашений об Уровне Услуг (SLA);

-отслеживания хода выполнения процесса;

-определения тенденгпгй развития,

•Руководство Линейными ИТ-подразделениями - отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следую-П1ую ниформати-но:

-прогресс в решении инцидентов;

-время разрешения инцидентов в различных ipynnax поддержки.

•Управления Уровнем Сервисов (Услуг) - отчет должен, прежде всего, содержат!> информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информагино, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Огчегы для заказчиков должны предоставлять информацию о том, выполняются ли соглапш-ння в отнопгенни Уровня Сервисов (услуг) в рамках Процесса Управлешгя Инцидентами.

•Руководителей других нроцессоп ИТ Сервис-менеджмента - отчеты для руководителей других процессов долж1н,1 быть, в первую очередь, ииформативнылн-!, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных записей об инцидентах может предоставлять следуюи1ую информацию:

-число обнаруженггых и зарегистрирова1Н1ых инцидентов;

-число разре1пе1П1ых инцидентов, с разделением но времени разрешения;

-статус и число неразрешенных инцидентов;

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

-инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.

4.5.1. Критические факторы успеха

Для успеппюго Управления И)1циденгами необходимо следуюп1ее:

•Актуальная Конфигурационная База Дантлх (CMDB), помогающая оценить степень во.здействия и срочность инцидентов. Эта ищ1)ормация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличению времени разренгения инцпдентов.

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [ 17 ] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]