Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL Страница 11

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

3.3.3. Другие рассматриваемые процессы

Существуют два процесса, которые хотя и не являются модулями ITIL в сериях Предоставление ус­луг и Поддержка услуг, но связаны ссылками с другими модулями или с ключевыми пунктами дру­гих процессов. Управление Отношениями с Заказчиком ИТ1 является процессом, привлекающим все больше внимания, но пока не вошедшим в какой-либо модуль ITIL. Управление Информацион­ной Безопасностью было описано в публикации ITIL 1999 г., но формально не является частью се­рии Предоставление услуг. Вопросам безопасности в этой книге посвящена отдельная глава.

Управление Взаимоотношениями с Заказчиком ИТ

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

Управление Информационной Безопасностью

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

Рис. 3.4. Книга "Поддержка Услуг" (Service Support) – публикация 2000 г. (OGC)

Рис. 3.5. Книга "Предоставление Услуг" (Service Delivery) – публикация 2001 г. (OGC)

Рис. 3.6. Книга "Управление Инфраструктурой информационных и коммуникационных технологий" (ICT Infrastructure Management) – публикация 2002 г. (OGC)

Рис. 3.7. Книга "Управление Приложениями" (Application Management) – публикация 2002 г. (OGC)

Рис. 3.8. Книга "Управление Безопасностью" (Security Management) – публикация 2002 г. (OGC)

Рис. 3.9. Книга "Планирование внедрения Сервис-менеджмента" (Planning to Implement Service Management) – книга 2002 г. (OGC)

Глава 4 Управление Инцидентами

4.1. Введение

Задача Процесса Управления Инцидентами является реактивной – уменьшение или исключение отрицательного воздействия (потенциальных) нарушений в предоставлении ИТ-услуг, таким образом обеспечивая наиболее быстрое восстановление работы пользователей. Для выполнения этой задачи производится регистрация, классификация и назначение инцидентов соответствующим группам специалистов, мониторинг хода работ по разрешению инцидентов, решение инцидентов и их закрытие. Так как это требует тесного взаимодействия с пользователями, фокусной точной Процесса управления Инцидентами обычно является функция Service Desk[58], которая играет роль центра контактов пользователей с "внутренними" коллективами технических служб. Управление Инцидентами является важнейшей основой для работы других процессов ITIL, предоставляя ценную информацию об ошибках в работе ИТ-инфраструктуры.

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

Рис. 4.1. Позиционирование Процесса Управления Инцидентами относительно других функций (подразделений) ИТ-организации

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

Инцидент

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Степень воздействия[63], срочность[64] и приоритет[65]

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

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

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

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

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

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

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

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

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