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

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

Категория

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

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

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

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

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

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

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

Приоритет

После этого назначается приоритет, чтобы быть уверенными, что группа поддержки уделит инци­денту необходимое внимание. Приоритет — это номер, определяющийся срочностью (насколько бы­стро это должно быть исправлено) и степенью воздействия (какой ущерб будет нанесен, если не ис­править быстро).

Приоритет = Срочность х Степень воздействия. Услуги (сервисы)

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

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

Если Служба Service Desk не может разрешить инцидент незамедлительно, то определяется группа поддержки, которая будет заниматься разрешением инцидента. Основой для распределения (марш рутизацнн) инцидентов часто является информация о категориях. При определении категорий мо­жет потребоваться рассмотрение структуры групп поддержки. Правильное распределение инциден­тов имеет существенное значение для эффективности Процесса Управления Инцидентами. Поэтому одним из ключевых показателей эффективности¹ (KPI) Процесса Управления Инцидентами может быть число неправильно распределенных обращений.

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

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

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

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

Статус

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

• новый;

• принят;

• запланирован;

• назначен;

• активный;

• отложен;

• разрешен;

• закрыт.

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

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

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

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

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

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

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

3. Закрытие

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

' Key Performance Indicators - KPI.

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