Отношения процесса управления инцидентами с другими процессами

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

Конфигурационная База Данных (Configuration Management Database — CMDB) играет важную роль в Управлении Инцидентами, так как она определяет связь между ресурсами, услугами, пользо­вателями и Уровнями Услуг (сервисов). Например,

Ø более эффективное распределение инцидентов по группам специалистов. На основе данных CMDB о том, кто является ответственным за компонент инфраструктуры (КЭ),

Ø решение оперативных вопросов, например, перенаправление очереди печати или переключение пользователя на другой сервер.

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

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

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

Ø С другой стороны, Управление Проблемами помогает Процессу Управления Инцидентами, предоставляя информацию о проблемах, известных ошибках, обходных решениях и быстрых исправлениях'.

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

Ø Инциденты могут быть решены путем внесения изменений, например, заменой монитора.

Ø Управле­ние Изменениями предоставляет Процессу Управления Инцидентами информацию о запланиро­ванных изменениях и их статусах.

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

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

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

Ø Регистрационные данные об инцидентах требуются при соста­влении отчетов для проверки выполнения согласованного Уровня Услуг.

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

Ø Для определения показателей доступности услуг Процесс Управления Доступностью использует ре­гистрационные данные об инцидентах.

 

2.6. Управление Мощностями

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

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

 

3. 3. Схема процесса (основные стадии и задачи)

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

Инциденты могут возникнуть в любой части инфраструктуры:

Ø Пользователи

Ø Сотрудники других отделов

Ø Автоматические системы управления, настроенные на регистрацию событии в приложениях и технической инфра­структуре.

3.2. Прием и регистрация инцидента (Acceptance and Recording)

— принимается сообщение и созда­ется запись об инциденте.

Инци­денты могут быть обнаружены следующим образом:

ü Обнаружен пользователем: он докладывает об инциденте в Службу Service Desk.

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

ü Обнаружен сотрудником Службы Service Desk: сотрудник производит регистрацию инцидента.

ü Обнаружен кем-либо в другом подразделении ИТ: этот специалист регистрирует инцидент в сис­теме регистрации инцидентов или докладывает о нем в Службу Service Desk.

Необходимо избегать двойной регистрации одного инцидента. Поэтому при регистрации инцидента следует проверить, нет ли аналогичных открытых инцидентов.

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

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

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

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

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

 

3.3. Классификация и начальная поддержка (Classification and Initial support)

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

Категория

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

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

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

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

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

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

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

 

Приоритет

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

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

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

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

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

Ø Основой для распределения (маршрутизации) инцидентов часто является информация о категориях..

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

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

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

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

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

 

Статус

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

• новый;

• принят;

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

• назначен;

• активный;

• отложен;

• разрешен;

• закрыт.

Ø Если вызов касается Запроса на Обслуживание (Service Request), то инициируется соответству­ющая процедура.