Страница:
[45], базирующуюся на практическом опыте профессиональных пользователей по всему миру.
3.3. Книги библиотеки ITIL
Каждая из книг библиотеки ITIL рассматривает вопросы отдельной части структурированной процессной основы. В них дается описание того, что необходимо для организации ИТ Сервис-менеджмента.
Библиотека ITIL определяет цели и виды деятельности, входные и выходные параметры каждого из процессов в ИТ-организации. Однако, библиотека ITIL не дает конкретного описания способов осуществления этой деятельности, так как они могут различаться в каждой организации. Акцент делается на проверенном практикой подходе, который может быть реализован различными способами в зависимости от обстоятельств. Библиотека ITIL не является методом; наоборот, она предлагает структурированную основу для планирования наиболее часто используемых процессов, ролей и видов деятельности, определяя связи между ними и необходимые виды коммуникации. Создание библиотеки ITIL вызвано необходимостью предоставления высококачественных услуг, уделяя при этом особое внимание отношениям с заказчиком. ИТ-организация должна выполнять соглашения с заказчиком, что означает поддержание хороших отношений с заказчиками и партнерами, такими, как поставщики.
Частично философия библиотеки ITIL имеет в своей основе системы качества, такие, как стандарты серии ISO-9000, и общие схемы обеспечения качества (Total Quality frameworks), как предлагаемые Европейской организацией Управления Качеством (European Foundation of Quality Management – EFQM). Библиотека ITIL поддерживает эти системы путем предоставления четкого описания процессов и передового опыта ИТ Сервис-менеджмента. Это может значительно сократить время, необходимое для прохождения сертификации ISO.
Первоначально библиотека ITIL состояла из нескольких комплектов книг, в каждом из которых описывалась конкретная область сопровождения и эксплуатации ИТ-инфраструктуры. Ядром ITIL считались десять книг, в которых описывались такие области, как поддержка услуг [46]и предоставление услуг [47]. Библиотека включала также около 40 других книг по вспомогательным предметам, имевшим отношение к ИТ Сервис-менеджменту, от монтажа кабелей до Управления Отношениями с Заказчиком. Однако, в первоначальных сериях книг вопросы ИТ Сервис-менеджмента рассматривали главным образом с точки зрения ИТ. Для заполнения разрыва между бизнес-практикой и ИТ-организацией в библиотеку была включена серия книг, рассматривающая бизнес-аспекты ИТ Сервис-менеджмента [48]. Более того, в определенных частях библиотеки ITIL в то время использовался несколько устаревший подход.
В настоящее время была сделана переработка центральных книг по ITIL и они были переизданы в виде двух книг: одна – по поддержке услуг и другая – по их предоставлению. Это позволило исключить повторы и встречавшуюся местами несогласованность ранних серий, что улучшило структурное единство издания, которое теперь дает более четкое представление об ИТ Сервис-менеджменте.
Начатый после выпуска указанного издания пересмотр всей серии публикаций ITIL еще не завершен.
Рис. 3.2. Представление элементов библиотеки ITIL (Источник: OGC)
Структурированный подход, изложенный в библиотеке ITIL, состоит из семи элементов (см. рис. 3.2). Все элементы взаимодействуют между собой и в определенной степени перекрываются друг с другом.
Этими элементами являются:
? Поддержка услуг (Service Support) – публикация 2000 г.;
? Предоставление услуг (Service Delivery) – публикация 2001 г.;
? Управление Инфраструктурой информационных и коммуникационных технологий (ICT Infrastructure Management) – публикация 2002 г.;
? Управление Приложениями (Applications management) – публикация 2002 г.;
? Управление Безопасностью (Security management) – публикация 2002 г.;
? Планирование внедрения Сервис-менеджмента (Planning to Implement Service Management) – публикация 2002 г.;
? Бизнес-перспектива (The Business Perspective) – публикация планируется в 2004 г.
В этой главе мы представляем серии публикаций ITIL. В течение 2002 г. оригинальная серия, первые книги которой появились в 1989 г., была заменена шестью новыми книгами ITIL, издание седьмой книги планируется на 2004 г. Более подробная информация по этой теме приводится в приложении и на Web-сайтах OGC и EXIN.
3.3.1. Предоставление услуг
Как уже отмечалось, Поддержка услуг и Предоставление услуг считаются центральными компонентами передового опыта ITIL для ИТ Сервис-менеджмента.
В книге ITIL по Предоставлению услуг описываются требования, необходимые для оказания услуг. В этой серии рассматриваются следующие вопросы:
? Управление Уровнем Услуг;
? Управление Финансами ИТ;
? Управление Мощностями;
? Управление Непрерывностью ИТ-услуг;
? Управление Доступностью.
В данную ознакомительную книгу было включено также Управление Информационной Безопасностью (со ссылкой на книгу ITIL по информационной безопасности), но оно не является частью серии по предоставлению услуг.
Сложную взаимосвязь между процессами, описываемыми в книгах по Поддержке и Предоставлению услуг, почти невозможно отразить графически. В общих чертах они показаны в виде упрощенной схемы на рис. 3.3.
Рис. 3.3. Поддержка и Предоставление Услуг.
Управление Уровнем Услуг
Целью Управления Уровнем Услуг является достижение ясных соглашений с заказчиком об ИТ-услугах и реализация этих соглашений. Соответственно, для Управления Уровнем Услуг необходима информация о потребностях заказчика, о предоставляемых ИТ-организацией технических средствах и о имеющихся финансовых ресурсах.
Управление Уровнем Услуг рассматривает услуги, предоставляемые заказчику (с акцентом на заказчике [49]). ИТ-организация может повысить степень удовлетворенности заказчика через создание услуг за основе его потребностей (услуги, вызванные спросом [50]), только на базе своих технических возможностей (услуги, вызванные предложением [51]). В главе об Управлении Уровнем Услуг книги по Предоставлению услуг рассматриваются следующие вопросы:
? как оптимизировать ИТ-услуги для их предоставления заказчикам по доступным ценам на основе точного определения договоренностей в Соглашении об Уровне Услуг;
? как проводить мониторинг и обсуждение услуг;
? как организовать Поддержку Услуг Внешними Договорами [52]с поставщиками.
Управление Финансами ИТ
Управление Финансами касается экономических вопросов предоставляемых ИТ-услуг. Например, Процесс Управления Финансами подготавливает информацию о расходах, возникших при предоставлении услуг. В результате при определении необходимых изменений ИТ-инфраструктуры или ИТ-услуг возможен учет финансовых факторов (соотнесение расходов и доходов – цены и результата). Определение, отнесение расходов, их прогноз и отслеживание, рассматривавшиеся в главе об управлении финансами книги по предоставлению услуг, - все это охватывается термином "расчет себестоимости" [53], а в нынешнем издании ITIL называется "бюджетированием и бухгалтерским учетом". Эта деятельность повышает информированность о расходах (где возникают издержки и какие) и может использоваться также при составлении бюджета. Управление Финансами ИТ описывает различные методы выставления счетов, включая определение цели выставления счетов за ИТ-услуги (для чего это используется в компании?) и определение ценообразования, а также аспекты бюджетирования.
Управление Мощностями
Управление Мощностями представляет собой процесс оптимизации расходов, времени приобретения и размещения ИТ-ресурсов с целью обеспечения выполнения договоренностей с заказчиком. Процесс Управления Мощностями имеет дело с Управлением Ресурсами, Управлением Производительностью, Управлением Спросом на ИТ, моделированием, планированием мощностей, Управлением Нагрузкой и определением необходимого объема технических средств для работы приложений [54]. В Управлении Мощностями акцент делается на планировании для обеспечения согласованного Уровня Услуг сейчас и в будущем.
Управление Доступностью
Управление Доступностью является процессом, обеспечивающим соответствующее размещение ресурсов, методов и технологий для поддержки Уровня Доступности ИТ-услуг, согласованных с заказчиком. Управление Доступностью занимается такими вопросами, как оптимизация обслуживания и разрабатывает способы минимизации числа инцидентов.
Управление Непрерывностью ИТ-услуг
Этот процесс касается подготовки и планирования способов устранения чрезвычайных ситуаций с ИТ-услугами в случае остановки бизнеса. Называвшийся в предыдущем издании ITIL "Планированием на случай чрезвычайных обстоятельств" [55], этот процесс уделяет основное внимание связям между всеми компонентами, необходимым для защиты непрерывности деятельности компании при катастрофах (т. е. для Управления Непрерывностью Бизнеса), а также средствам предотвращения таких катастроф. Управление Непрерывностью ИТ-услуг является процессом планирования и координации технических, финансовых и управленческих ресурсов, необходимых для обеспечения непрерывности услуг после катастроф, в соответствии с договоренностью с заказчиком.
3.3.2. Поддержка услуг
В книге ITIL по поддержке услуг описывается, как заказчик может получить доступ к соответствующим услугам для поддержки своего бизнеса. Эта книга охватывает следующие области:
? Служба Service Desk;
? Управление Инцидентами;
? Управление Проблемами;
? Управление Конфигурациями;
? Управление Изменениями;
? Управление Релизами.
Служба Service Desk
Служба Service Desk является точкой контакта пользователя с ИТ-организацией. Ранее в книгах ITIL она называлась службой Help Desk. Основными задачами службы Help Desk были регистрация, решение и отслеживание инцидентов. Служба Service Desk имеет более широкие функции (например, получение Запросов на Изменения) и может выполнять действия, относящиеся к нескольким процессам.
Управление Инцидентами
Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это разграничение иногда может запутывать, но его главное достоинство заключается в установлении различия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением. Процесс Управления Инцидентами предназначен для устранения инцидента и быстрого возобновления предоставления услуг. Инциденты регистрируются, причем качество регистрационной информации определяет эффективность ряда других процессов.
Управление Проблемами
Если есть подозрение на проблему в ИТ-инфраструктуре, то целью Процесса Управления Проблемами является установление корневой причины. Подозрение на существование проблемы может возникнуть из-за наличия инцидентов, но безусловно целью является предотвращение сбоев везде. где это возможно.
Когда причины установлены (определены известные ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре для предотвращения возникновения новых инцидентов. Такие улучшения производятся путем подачи Запросов на Изменение [56]. Необходимо обратить внимание на то, что определение Управления Проблемами, дающееся в ITIL, значительно отличается от определения, которое раньше было принято, например, в ИТ-индустрии США.
Управление Конфигурациями
Задачами Управления Конфигурациями являются контроль изменяющейся ИТ-инфраструктуры (стандартизация и мониторинг статуса), идентификация Конфигурационных Единиц (инвентаризация, верификация и регистрация), сбор и Управление Документацией по ИТ-инфраструктуре, а также предоставление информации об ИТ-инфраструктуре для всех других процессов.
Управление Изменениями
Управление Изменениями направлено на контроль проведения изменений в ИТ-инфраструктуре. Целью процесса является определение необходимых изменений и способов их проведения с минимальным негативным воздействием на ИТ-услуги, при одновременном обеспечении контроля (отслеживании) изменений посредством консультаций и координации действий со всей организацией. Изменения производятся по Запросу от Заказчика, из Процесса Управления Проблемами или из некоторых других процессов. Управление Изменениями тесно связано с деятельностью по мониторингу статуса элементов из Процесса Управления Конфигурациями. Внесение изменений производится согласно разработанной схеме, включающей определение, планирование, создание и испытание, принятие окончательного решения о проведении, внедрение и оценку.
Управление Релизами
Релизом называется набор Конфигурационных Единиц [57], которые совместно тестируются и вводятся в активную рабочую среду. Главной задачей Управления Релизами является обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранение.
Управление Релизами обеспечивает гарантию того, что в использовании находятся только тестированные и корректные версии авторизованного программного и аппаратного обеспечения. Управление Релизами тесно связано с деятельностью по Управлению Конфигурациями и Управлению Изменениями. Реальное внесение изменений часто осуществляется через действия в рамках Процесса Управления Релизами.
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.
Таблица 4.1. Пример системы кодирования приоритетов
Эскалация
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
? Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
? Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Первая, вторая и n-линия поддержки
Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.
3.3. Книги библиотеки ITIL
Каждая из книг библиотеки ITIL рассматривает вопросы отдельной части структурированной процессной основы. В них дается описание того, что необходимо для организации ИТ Сервис-менеджмента.
Библиотека ITIL определяет цели и виды деятельности, входные и выходные параметры каждого из процессов в ИТ-организации. Однако, библиотека ITIL не дает конкретного описания способов осуществления этой деятельности, так как они могут различаться в каждой организации. Акцент делается на проверенном практикой подходе, который может быть реализован различными способами в зависимости от обстоятельств. Библиотека ITIL не является методом; наоборот, она предлагает структурированную основу для планирования наиболее часто используемых процессов, ролей и видов деятельности, определяя связи между ними и необходимые виды коммуникации. Создание библиотеки ITIL вызвано необходимостью предоставления высококачественных услуг, уделяя при этом особое внимание отношениям с заказчиком. ИТ-организация должна выполнять соглашения с заказчиком, что означает поддержание хороших отношений с заказчиками и партнерами, такими, как поставщики.
Частично философия библиотеки ITIL имеет в своей основе системы качества, такие, как стандарты серии ISO-9000, и общие схемы обеспечения качества (Total Quality frameworks), как предлагаемые Европейской организацией Управления Качеством (European Foundation of Quality Management – EFQM). Библиотека ITIL поддерживает эти системы путем предоставления четкого описания процессов и передового опыта ИТ Сервис-менеджмента. Это может значительно сократить время, необходимое для прохождения сертификации ISO.
Первоначально библиотека ITIL состояла из нескольких комплектов книг, в каждом из которых описывалась конкретная область сопровождения и эксплуатации ИТ-инфраструктуры. Ядром ITIL считались десять книг, в которых описывались такие области, как поддержка услуг [46]и предоставление услуг [47]. Библиотека включала также около 40 других книг по вспомогательным предметам, имевшим отношение к ИТ Сервис-менеджменту, от монтажа кабелей до Управления Отношениями с Заказчиком. Однако, в первоначальных сериях книг вопросы ИТ Сервис-менеджмента рассматривали главным образом с точки зрения ИТ. Для заполнения разрыва между бизнес-практикой и ИТ-организацией в библиотеку была включена серия книг, рассматривающая бизнес-аспекты ИТ Сервис-менеджмента [48]. Более того, в определенных частях библиотеки ITIL в то время использовался несколько устаревший подход.
В настоящее время была сделана переработка центральных книг по ITIL и они были переизданы в виде двух книг: одна – по поддержке услуг и другая – по их предоставлению. Это позволило исключить повторы и встречавшуюся местами несогласованность ранних серий, что улучшило структурное единство издания, которое теперь дает более четкое представление об ИТ Сервис-менеджменте.
Начатый после выпуска указанного издания пересмотр всей серии публикаций ITIL еще не завершен.
Рис. 3.2. Представление элементов библиотеки ITIL (Источник: OGC)
Структурированный подход, изложенный в библиотеке ITIL, состоит из семи элементов (см. рис. 3.2). Все элементы взаимодействуют между собой и в определенной степени перекрываются друг с другом.
Этими элементами являются:
? Поддержка услуг (Service Support) – публикация 2000 г.;
? Предоставление услуг (Service Delivery) – публикация 2001 г.;
? Управление Инфраструктурой информационных и коммуникационных технологий (ICT Infrastructure Management) – публикация 2002 г.;
? Управление Приложениями (Applications management) – публикация 2002 г.;
? Управление Безопасностью (Security management) – публикация 2002 г.;
? Планирование внедрения Сервис-менеджмента (Planning to Implement Service Management) – публикация 2002 г.;
? Бизнес-перспектива (The Business Perspective) – публикация планируется в 2004 г.
В этой главе мы представляем серии публикаций ITIL. В течение 2002 г. оригинальная серия, первые книги которой появились в 1989 г., была заменена шестью новыми книгами ITIL, издание седьмой книги планируется на 2004 г. Более подробная информация по этой теме приводится в приложении и на Web-сайтах OGC и EXIN.
3.3.1. Предоставление услуг
Как уже отмечалось, Поддержка услуг и Предоставление услуг считаются центральными компонентами передового опыта ITIL для ИТ Сервис-менеджмента.
В книге ITIL по Предоставлению услуг описываются требования, необходимые для оказания услуг. В этой серии рассматриваются следующие вопросы:
? Управление Уровнем Услуг;
? Управление Финансами ИТ;
? Управление Мощностями;
? Управление Непрерывностью ИТ-услуг;
? Управление Доступностью.
В данную ознакомительную книгу было включено также Управление Информационной Безопасностью (со ссылкой на книгу ITIL по информационной безопасности), но оно не является частью серии по предоставлению услуг.
Сложную взаимосвязь между процессами, описываемыми в книгах по Поддержке и Предоставлению услуг, почти невозможно отразить графически. В общих чертах они показаны в виде упрощенной схемы на рис. 3.3.
Рис. 3.3. Поддержка и Предоставление Услуг.
Управление Уровнем Услуг
Целью Управления Уровнем Услуг является достижение ясных соглашений с заказчиком об ИТ-услугах и реализация этих соглашений. Соответственно, для Управления Уровнем Услуг необходима информация о потребностях заказчика, о предоставляемых ИТ-организацией технических средствах и о имеющихся финансовых ресурсах.
Управление Уровнем Услуг рассматривает услуги, предоставляемые заказчику (с акцентом на заказчике [49]). ИТ-организация может повысить степень удовлетворенности заказчика через создание услуг за основе его потребностей (услуги, вызванные спросом [50]), только на базе своих технических возможностей (услуги, вызванные предложением [51]). В главе об Управлении Уровнем Услуг книги по Предоставлению услуг рассматриваются следующие вопросы:
? как оптимизировать ИТ-услуги для их предоставления заказчикам по доступным ценам на основе точного определения договоренностей в Соглашении об Уровне Услуг;
? как проводить мониторинг и обсуждение услуг;
? как организовать Поддержку Услуг Внешними Договорами [52]с поставщиками.
Управление Финансами ИТ
Управление Финансами касается экономических вопросов предоставляемых ИТ-услуг. Например, Процесс Управления Финансами подготавливает информацию о расходах, возникших при предоставлении услуг. В результате при определении необходимых изменений ИТ-инфраструктуры или ИТ-услуг возможен учет финансовых факторов (соотнесение расходов и доходов – цены и результата). Определение, отнесение расходов, их прогноз и отслеживание, рассматривавшиеся в главе об управлении финансами книги по предоставлению услуг, - все это охватывается термином "расчет себестоимости" [53], а в нынешнем издании ITIL называется "бюджетированием и бухгалтерским учетом". Эта деятельность повышает информированность о расходах (где возникают издержки и какие) и может использоваться также при составлении бюджета. Управление Финансами ИТ описывает различные методы выставления счетов, включая определение цели выставления счетов за ИТ-услуги (для чего это используется в компании?) и определение ценообразования, а также аспекты бюджетирования.
Управление Мощностями
Управление Мощностями представляет собой процесс оптимизации расходов, времени приобретения и размещения ИТ-ресурсов с целью обеспечения выполнения договоренностей с заказчиком. Процесс Управления Мощностями имеет дело с Управлением Ресурсами, Управлением Производительностью, Управлением Спросом на ИТ, моделированием, планированием мощностей, Управлением Нагрузкой и определением необходимого объема технических средств для работы приложений [54]. В Управлении Мощностями акцент делается на планировании для обеспечения согласованного Уровня Услуг сейчас и в будущем.
Управление Доступностью
Управление Доступностью является процессом, обеспечивающим соответствующее размещение ресурсов, методов и технологий для поддержки Уровня Доступности ИТ-услуг, согласованных с заказчиком. Управление Доступностью занимается такими вопросами, как оптимизация обслуживания и разрабатывает способы минимизации числа инцидентов.
Управление Непрерывностью ИТ-услуг
Этот процесс касается подготовки и планирования способов устранения чрезвычайных ситуаций с ИТ-услугами в случае остановки бизнеса. Называвшийся в предыдущем издании ITIL "Планированием на случай чрезвычайных обстоятельств" [55], этот процесс уделяет основное внимание связям между всеми компонентами, необходимым для защиты непрерывности деятельности компании при катастрофах (т. е. для Управления Непрерывностью Бизнеса), а также средствам предотвращения таких катастроф. Управление Непрерывностью ИТ-услуг является процессом планирования и координации технических, финансовых и управленческих ресурсов, необходимых для обеспечения непрерывности услуг после катастроф, в соответствии с договоренностью с заказчиком.
3.3.2. Поддержка услуг
В книге ITIL по поддержке услуг описывается, как заказчик может получить доступ к соответствующим услугам для поддержки своего бизнеса. Эта книга охватывает следующие области:
? Служба Service Desk;
? Управление Инцидентами;
? Управление Проблемами;
? Управление Конфигурациями;
? Управление Изменениями;
? Управление Релизами.
Служба Service Desk
Служба Service Desk является точкой контакта пользователя с ИТ-организацией. Ранее в книгах ITIL она называлась службой Help Desk. Основными задачами службы Help Desk были регистрация, решение и отслеживание инцидентов. Служба Service Desk имеет более широкие функции (например, получение Запросов на Изменения) и может выполнять действия, относящиеся к нескольким процессам.
Управление Инцидентами
Разграничение между инцидентами и проблемами вероятно является одним из самых известных, но не самых популярных вкладов библиотеки ITIL в развитие ИТ Сервис-менеджмента. Хотя это разграничение иногда может запутывать, но его главное достоинство заключается в установлении различия между быстрым восстановлением услуги и установлением причины инцидента и ее устранением. Процесс Управления Инцидентами предназначен для устранения инцидента и быстрого возобновления предоставления услуг. Инциденты регистрируются, причем качество регистрационной информации определяет эффективность ряда других процессов.
Управление Проблемами
Если есть подозрение на проблему в ИТ-инфраструктуре, то целью Процесса Управления Проблемами является установление корневой причины. Подозрение на существование проблемы может возникнуть из-за наличия инцидентов, но безусловно целью является предотвращение сбоев везде. где это возможно.
Когда причины установлены (определены известные ошибки), принимается бизнес-решение о том, необходимо ли делать улучшения в инфраструктуре для предотвращения возникновения новых инцидентов. Такие улучшения производятся путем подачи Запросов на Изменение [56]. Необходимо обратить внимание на то, что определение Управления Проблемами, дающееся в ITIL, значительно отличается от определения, которое раньше было принято, например, в ИТ-индустрии США.
Управление Конфигурациями
Задачами Управления Конфигурациями являются контроль изменяющейся ИТ-инфраструктуры (стандартизация и мониторинг статуса), идентификация Конфигурационных Единиц (инвентаризация, верификация и регистрация), сбор и Управление Документацией по ИТ-инфраструктуре, а также предоставление информации об ИТ-инфраструктуре для всех других процессов.
Управление Изменениями
Управление Изменениями направлено на контроль проведения изменений в ИТ-инфраструктуре. Целью процесса является определение необходимых изменений и способов их проведения с минимальным негативным воздействием на ИТ-услуги, при одновременном обеспечении контроля (отслеживании) изменений посредством консультаций и координации действий со всей организацией. Изменения производятся по Запросу от Заказчика, из Процесса Управления Проблемами или из некоторых других процессов. Управление Изменениями тесно связано с деятельностью по мониторингу статуса элементов из Процесса Управления Конфигурациями. Внесение изменений производится согласно разработанной схеме, включающей определение, планирование, создание и испытание, принятие окончательного решения о проведении, внедрение и оценку.
Управление Релизами
Релизом называется набор Конфигурационных Единиц [57], которые совместно тестируются и вводятся в активную рабочую среду. Главной задачей Управления Релизами является обеспечение успешного развертывания релизов, включая интеграцию, проведение тестирования и хранение.
Управление Релизами обеспечивает гарантию того, что в использовании находятся только тестированные и корректные версии авторизованного программного и аппаратного обеспечения. Управление Релизами тесно связано с деятельностью по Управлению Конфигурациями и Управлению Изменениями. Реальное внесение изменений часто осуществляется через действия в рамках Процесса Управления Релизами.
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.
| Приоритет | Высокая | Средняя | Низкая |
| Время разрешения | |||
| Высокая | Критический | Высокий | Средний |
| < 1 часа | < 8 часов | < 24 часов | |
| Средняя | Высокий | Средний | Низкий |
| < 8 часов | < 24 часов | < 48 часов | |
| Низкая | Средний | Низкий | Планирование |
| < 24 часов | < 48 часов | Запланировано |
Таблица 4.1. Пример системы кодирования приоритетов
Эскалация
Если инцидент не может быть разрешен первой линией поддержки за согласованное время, необходимо привлечение дополнительных знаний или полномочий. Это называется эскалацией, которая происходит в соответствии с рассмотренными выше приоритетами и, соответственно, временем разрешения инцидента.
Различают функциональную и иерархическую эскалацию:
? Функциональная эскалация (горизонтальная) – означает привлечение большего количества специалистов или предоставление дополнительных прав доступа для разрешения инцидента; при этом, возможно, происходит выход за пределы одного структурного ИТ-подразделения.
? Иерархическая эскалация (вертикальная) – означает вертикальный переход (на более высокий уровень) в рамках организации, так как для разрешения инцидента недостаточно организационных полномочий (уровня власти) или ресурсов.
Задачей Руководителя Процесса Управления Инцидентами является заблаговременное резервирование возможностей для функциональной эскалации в рамках линейных подразделений организации так, чтобы разрешение инцидентов не требовало регулярной иерархической эскалации. В любом случае, линейные подразделения должны предоставить для этого процесса достаточное количество ресурсов.
Первая, вторая и n-линия поддержки
Выше была изложена маршрутизация инцидента, или функциональная эскалация. Маршрутизация определяется требуемым уровнем знаний, полномочий и срочностью. Первой линией поддержки (называемой также поддержкой 1-го уровня) обычно является Служба Service Desk, второй линией – подразделений, осуществляющие Управление ИТ-инфраструктурой, третья – отделы разработки и архитектуры программного обеспечения, и четвертая – поставщики. Чем меньше организация, тем меньше в ней уровней эскалации. В больших организациях Руководитель Процесса Управления Инцидентами может назначить Координаторов инцидентов в соответствующих подразделениях для поддержки своей деятельности. Например, координаторы могут играть роль интерфейса между процессной деятельностью и линейными организационными подразделениями. Каждый из них координирует деятельность собственных групп поддержки. Процедура эскалации графически представлена на рис. 4.3.