Инцидент

Терминология

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

В книге «Поддержка услуг» библиотеки ITIL дается следующее определение:

Инцидент² — это любое событие, не являющееся частью стандартных операций по предоставлению услуги, которое привело или может привести к нарушению или снижению качества этой услуги.

В контексте библиотеки ITIL инцидентами считаются не только ошибки аппаратного или про­граммного обеспечения, но также и Запросы на Обслуживание.

Запрос на Обслуживание³ — это Запрос от Пользователя на поддержку, предоставление информа­ции, консультации или документации, не являющийся сбоем ИТ-инфраструктуры.

¹ В литературе по ITIL понятие «функция» ассоциировано с вертикальным (линейным) подразделением организации, выполняющим
соответствующие функциональные обязанности и фактически является его синонимом. — Прим. ред.

² Incident.

³ Service request.

4. УПРАВЛЕНИЕ ИНЦИДЕНТАМИ

Примеры Запросов на Обслуживание:

• вопрос о функционировании ИТ-систем или запрос о предоставлении какой-либо информации;

• запрос о состоянии (статусе) чего-либо в ИТ-инфраструктуре;

• запрос о замене пароля;

• запросы на выполнение пакетных заданий, восстановление или авторизацию пароля;

• получение информации из базы данных.

Для того чтобы можно было отличить «настоящие инциденты» от «инцидентов-Запросов на Обслу­живание», рекомендуется присваивать Запросам на Обслуживание специальную категорию. Важно также отметить, что Запрос на Обслуживание это не то же самое, что Запрос на Изменение:

Запрос на Изменение (RFC)' — это экранная или бумажная форма, используемая для записи деталь­ной информации о предлагаемом Запросе на Изменение какой-либо Конфигурационной Единицы¹ (CI) в ИТ-инфраструктуре или процедуры или какого-либо иного объекта ИТ-инфраструктуры.

Запрос на Изменение RFC считается завершенным после проведения изменения в инфраструктуре, например, замены зарегистрированных компонентов, инсталляции ПК и т. д. Это не инциденты, а изменения.

Степень воздействия³, срочность⁴ и приоритет⁵

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

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

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

• срочность инцидента: приемлемая задержка разрешения инцидента для пользователя или биз­нес-процесса.

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

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

¹ Request for change —RFC

³ Configuration item — CI.

³ Impact.

⁴ rgency.
⁵ Priority.

4. УПРАВЛЕНИЕ ИНЦИДЕНТАМИ

Рис. 4.2. Определение степени воздействия, срочности и приоритета

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

Степень воздействия и срочность могут быть объединены в матрицу, например, как показано в табл.4.1.

Таблица 4.1. Пример системы кодирования приоритетов

Дата добавления: 2015-01-03