ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

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

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

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

? Если есть (и они касаются того же инцидента), информация об инциденте обновляется или же инцидент регистрируется отдельно и устанавливается связь (привязка) к главному инциденту; при необходимости изменяется степень воздействия и приоритет, и добавляется информация о новом пользователе.

? Если нет (отличается от открытого инцидента), производится регистрация нового инцидента.

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

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

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

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

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

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

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

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

Категория

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

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

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

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

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

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

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

Приоритет

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

Приоритет = Срочность х Степень воздействия.

Услуги (сервисы)

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

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

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

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

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

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

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

Статус

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

? новый;

? принят;

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

? назначен;

? активный;

? отложен;

? разрешен;

? закрыт.

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

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

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

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

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

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

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

4.4.6. Закрытие

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

4.4.7. Мониторинг хода решения и отслеживание

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

4.5. Контроль процесса

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

? Руководителю Процесса Управления Инцидентами отчет необходим для:

? идентификации недостающих звеньев процесса;

? идентификации нарушений исполнения соглашений об Уровне Услуг (SLA);

? отслеживания хода выполнения процесса;

? определения тенденций развития.

? Руководство Линейными ИТ-подразделениями – отчет для руководства группы поддержки; он также может быть полезен в Управлении ИТ-подразделениями. Отчет должен содержать следую­щую информацию:

? прогресс в решении инцидентов;

? время разрешения инцидентов в различных группах поддержки.

? Управления Уровнем Сервисов (Услуг) – отчет должен, прежде всего, содержать информацию о качестве предоставляемых услуг. Руководитель Процесса Управления Уровнем Услуг должен получать всю информацию, необходимую для составления Отчетов об Уровне Услуг перед заказчиками. Отчеты для заказчиков должны предоставлять информацию о том, выполняются ли соглаше­ния в отношении Уровня Сервисов (услуг) в рамках Процесса Управления Инцидентами.

? Руководителей других процессов ИТ Сервис-менеджмента – отчеты для руководителей других процессов должны быть, в первую очередь, информативными, то есть содержать всю необходимую им информацию. Например, Процесс Управления Инцидентами на основе регистрационных запи­сей об инцидентах может предоставлять следующую информацию:

? число обнаруженных и зарегистрированных инцидентов;

? число разрешенных инцидентов, с разделением по времени разрешения;

? статус и число неразрешенных инцидентов;

? инциденты с разбивкой по периодам возникновения, группам заказчика, группам поддержки и временем разрешения в соответствии с соглашением (SLA);

? инциденты с разбивкой по категориям, приоритетам и группам поддержки и др.

4.5.1. Критические факторы успеха

Для успешного Управления Инцидентами необходимо следующее:

? Актуальная Конфигурационная База Данных (CMDB), помогающая оценить степень воздействия и срочность инцидентов. Эта информация также может быть получена от пользователя, но в этом случае она, возможно, будет менее полной и достаточно субъективной, что приведет к увеличе­нию времени разрешения инцидентов.

? База знаний[69]. Например, актуальная база данных по проблемам/известным ошибкам, описываю­щая способ распознавания инцидентов, имеющиеся решения и обходные пути. Она также может включать аналогичные базы знаний от поставщиков.

? Соответствующую автоматизированную систему регистрации, отслеживания и мониторинга ин­цидентов.

Дополнительно необходимо тесное взаимодействие с Процессом Управления Уровнем Сервисов (Услуг) для определения требуемых приоритетов и времени разрешения инцидентов.

4.5.2. Показатели эффективности[70]

Для оценки производительности процесса необходимо четко определить контрольные параметры и измеряемые оценки, часто называемые показателями эффективности. Отчет по этим показателям производится регулярно, например раз в неделю, чтобы получить картину изменений, по которой можно было бы определить тенденции. Примерами таких параметров являются:

? общее количество инцидентов;

? среднее время разрешения инцидентов;

? среднее время разрешения инцидентов по приоритетам;

? среднее число инцидентов, разрешенных в рамках соглашений (SLA);

? процент инцидентов, разрешенных первой линией поддержки (без направления в другие группы);

? средняя стоимость поддержки на инцидент;

? число решенных инцидентов на одно рабочее место или на одного сотрудника службы Service Desk;

? инциденты, решенные без посещения пользователя (удаленно);

? число (или процент) инцидентов с первоначально некорректной классификацией;

? число (или процент) инцидентов, неправильно распределенных в группы поддержки.

4.5.3. Функции и роли

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

Руководитель Процесса Управления Инцидентами

Во многих организациях роль Руководителя Управления Инцидентами играет менеджер Службы Service Desk. В сферу ответственности Руководителя Процесса Управления Инцидентами включа­ется следующее:

? мониторинг эффективности и рациональности работы[71] процесса;

? контроль работы групп поддержки;

? составление рекомендаций по совершенствованию работы процесса;

? развитие и сопровождение системы Управления Инцидентами.

Персонал групп поддержки

? Первая линия поддержки несет ответственность за регистрацию, классификацию, сопоставление (привязку), распределение по группам поддержки, разрешение и закрытие инцидентов.

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

4.6. Затраты и проблемы

4.6.1. Затраты

Затраты, связанные с Управлением Инцидентами, включают первоначальные затраты на внедрение (например, расходы на разработку процесса, обучение и инструктаж персонала), выбор и закупку инструментальных средств[72] поддержки процесса. Выбор инструментальных средств может занять значительное количество времени. Кроме того, существуют операционные расходы, связанные с оп­латой работы персонала и использованием инструментальных средств. Эти затраты во многом зави­сят от структуры Управления Инцидентами, диапазона видов деятельности, включенных в процесс, сфер ответственности и числа подразделений.

4.6.2. Проблемы

При внедрении Управления Инцидентами могут возникнуть следующие проблемы:

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

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

? Эскалация – как известно, в рамках Процесса Управления Инцидентами возможна эскалация ин­цидентов. Слишком большое число эскалаций может оказать отрицательное воздействие на рабо­ту специалистов, которые из-за этого отрываются от своей запланированной работы.

? Отсутствие Каталога Услуг и Соглашений об Уровне Сервисов (SLA) – если поддерживаемые услуги и продукты недостаточно точно определены, тогда специалистам, вовлеченным в Управле­ние Инцидентами, бывает трудно обоснованно отказать пользователям в помощи.

? Недостаточная приверженность[73] процессному подходу со стороны руководства и персонала – решение инцидентов с помощью процессного подхода обычно требует изменения культуры и более высокого уровня ответственности за свою работу со стороны персонала. Это может вы­звать серьезное сопротивление внутри организации. Эффективное Управление Инцидентами требует от сотрудников понимания и реальной приверженности процессному подходу, а не просто участия.

Глава 5 Управление Проблемами

5.1. Введение

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

Для выяснения корневых причин возникновения как существующих, так и потенциальных ошибок в предоставлении услуг, в рамках Процесса Управления Проблемами производится изучение инфра­структуры и имеющихся регистрационных данных, включая базу данных инцидентов. Такие иссле­дования необходимы из-за сложного и распределенного характера инфраструктуры, когда связи ме­жду инцидентами не всегда бывают очевидными. Например, причиной проблемы могут стать сразу несколько ошибок, и в то же время несколько проблем могут быть связаны с одной и той же ошиб­кой. Вначале надо определить причину возникновения проблемы. После того, как корневая причина определена, проблема переходит в разряд известных ошибок и для устранения этой причины можно направить Запрос на Изменение[74]. Но даже после этого известные ошибки будут отслеживаться и контролироваться в рамках Процесса Управления Проблемами. Поэтому следует вести регистрацию всех идентифицированных известных ошибок, их симптомов и имеющихся решений.

5.1.1. Определение – "проблема" и "известная ошибка"

На рис 5.1 показаны взаимосвязи между проблемой, известной ошибкой и Запросом на Изменение и даны определения этих терминов.

Рис. 5.1. Отношения между проблемами и известными ошибками (источник OGC)

5.1.2. Взаимоотношения с Процессом Управления Инцидентами

Процесс Управления Проблемами поддерживает Процесс Управления Инцидентами, предоставляя ему обходные решения и быстрые исправления[75], но при этом не неся прямой ответственности за раз­решение инцидента. Управление Инцидентами помогает быстро исправить ошибку любыми доступ­ными средствами, включая обходные решения, в то время как Управление Проблемами занимается поиском причины произошедшего и ее устранением. Инцидент может никогда "не стать" проблемой. Однако кроме самого инцидента, может быть определена связанная с ним проблема. Поэтому работа над проблемой может помочь в разрешении текущего инцидента, если он еще открыт.

На рис. 5.2 показаны отношения между инцидентами, проблемами, известными ошибками и изме­нениями.

Рис. 5.2. Отношения между Процессами Управления Инцидентами, Управления Проблемами и Управления Изменениями

5.2. Цель процесса

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

Управление Проблемами гарантирует, что:

? существующие и регулярно возникающие ошибки[76] идентифицированы, документированы и отслеживаются;

? симптомы ошибок, постоянные или временные решения документируются;

? подаются Запросы на Изменения с целью модификации инфраструктуры;

? предотвращается возникновение новых инцидентов;

? создаются отчеты о качестве инфраструктуры ИТ и самого процесса.

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

? Улучшение качества ИТ-услуг и Управления – результат документирования ошибок и/или их устранения.

? Повышение производительности труда пользователей – за счет улучшения качества услуг.

? Повышение производительности труда персонала – наличие документированных решений проб­лем позволяет даже менее опытным участникам Процесса Управления Инцидентами разрешать инциденты быстрее и эффективнее.

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

? Совершенствование знаний в области Управления, эффективное обучение – Процесс Управле­ния Проблемами позволяет хранить исторические данные[77], которые используются при определе­нии тенденций и помогают принять меры по предотвращению новых инцидентов. Исторические данные также можно использовать при проведении исследований и диагностирования, а также, при создании Запросов на Изменения.

? Улучшение регистрации инцидентов – Управление Проблемами вводит стандарты на регистра­цию и классификацию инцидентов с целью эффективного определения проблем и их симптомов. Это также помогает улучшить составление отчетов об инцидентах.

? Более высокая доля инцидентов, разрешенных на первой линии поддержки – поскольку Про­цесс Управления Проблемами разрабатывает решения для ликвидации инцидентов и проблем, а обходные решения можно найти в базе знаний, то первая линия поддержки с большим успехом сама разрешает инциденты.

5.3. Процесс

Входами для Процесса Управления Проблемами являются:

? детальные описания инцидентов;

? обходные решения, найденные Процессом Управления Инцидентами;

? детали конфигурации из Конфигурационной Базы Данных (CMDB);

? подробная информация от производителя используемых в инфраструктуре продуктах, включая известные ошибки в этих продуктах и технические детали;

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

Основными видами деятельности в рамках Процесса Управления Проблемами являются:

? контроль проблем: определение и исследование проблем;

? контроль ошибок: отслеживание известных ошибок и подача Запросов на Изменения (RFC);

? проактивное Управление Проблемами: предотвращение инцидентов путем совершенствования инфраструктуры;

? предоставление информации: отчеты по серьезным проблемам и достигнутым результатам.

Выходами процесса являются:

? известные ошибки;

? Запросы на Изменения (RFC);

? новые регистрационные данные о проблемах (обновленные с учетом информации о способах ре­шения и/или обходных решениях);

? закрытые после устранения причины проблемы регистрационные записи;

? информация для руководства.

Рис. 5.3. Управление Проблемами среди других процессов

5.3.1. Управление Инцидентами

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

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

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

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

Управление Изменениями отвечает за контролируемое проведение изменений, включая Запросы на Изменения для устранения проблем, предложенные Процессом Управления Проблемами. Управле­ние Изменениями несет ответственность за определение степени воздействия изменения и ресурсов, необходимых для его реализации, а также за планирование, согласование и оценку запрашиваемых изменений. Кроме того, Управление Изменениями информирует Процесс Управления Проблемами о ходе работ и о завершении корректирующих изменений. Оценка этим изменениям дается совмест­но с Процессом Управления Проблемами. Итогом работы является Анализ результатов внедрения[79], после которого в рамках подпроцесса Контроля ошибок может быть закрыта известная ошибка, а также относящиеся к ней (открытые) инциденты.

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

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

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

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

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

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

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

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

5.4. Виды деятельности

5.4.1. Контроль проблем

Целью этого вида деятельности является выявление проблем и изучение их причин. Контроль проб­лем должен преобразовать проблему в известную ошибку путем диагностирования неизвестной при­чины ее возникновения. На рис. 5.4 показаны действия, выполняемые в рамках контроля проблемы.

Рис. 5.4. Контроль проблем (источник: OGC)

Идентификация и регистрация проблемы

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

Деятельность по "идентификации проблем" часто выполняют Координаторы проблем. Однако бы­вает так, что персонал, изначально не вовлеченный в эту работу, например, специалисты по Управле­нию Мощностями, тоже может выявлять проблемы. Такие "находки" также следует регистрировать как проблемы.

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

? Анализ инцидентов показывает, что некоторый инцидент повторяется, возникает большое количе­ство инцидентов или возникает негативная тенденция.

? Анализ инфраструктуры позволил определить ее слабые места, где могут произойти новые инци­денты (возможно, это проводилось средствами Процессов Управления Доступностью и Управле­ния Мощностями).

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

? Существует угроза срыва Уровня Услуг, согласованного с заказчиком (по показателям производи­тельности, мощности ИТ-средств, затрат и т. д.)

? Нельзя установить связь между новыми инцидентами и уже известной проблемой или ошибкой.

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

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

Такая оценка может базироваться на "болевом показателе" инцидентов, в котором учитываются:

? издержки, которые несет бизнес из-за инцидентов;

? количество инцидентов;

? количество пользователей и бизнес-процессов, затронутых инцидентами;

? время и затраты на разрешение инцидентов.

Классификация и назначение

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

Классификация проблемы включает в себя следующее:

? Категория: определение области, например, программное или аппаратное обеспечение;

? Степень воздействия на бизнес-процесс;

? Срочность: допустимая задержка в решении проблемы;

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

? Статус: например, проблема, известная ошибка и т. д.

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

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

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

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

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

Источники ошибок в других средах

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

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

5.4.2. Контроль ошибок

Деятельность по Контролю ошибок заключается в ведении мониторинга и исправлении известных ошибок до момента их полного устранения (в тех случаях, когда это возможно и целесообразно). Эта задача решается путем подачи Запроса на Изменение (RFC) в Процесс Управления Изменениями и оценки внесенных изменений с помощью Анализа результатов внедрения (PIR). В рамках контроля ошибок осуществляется деятельность по мониторингу всех известных ошибок с момента их идентификации и до устранения. К работе по Контролю ошибок привлекаются многие подразделения, как операционной среды, так и из среды разработок.

Рис. 5.5. Контроль ошибок (источник: OGC)

Идентификация и регистрация ошибок

После определения причины проблемы и связанной с ней Конфигурационной Единицы, проблеме присваивается статус "Известной ошибки" и начинается деятельность по Контролю ошибок. Во многих случаях уже имеется обходное решение для проблемы, даже если ошибка найдена самими разработчиками. Но в некоторых случаях обходное решение нужно найти, а затем передать его в Процесс Управления Инцидентами, если там еще имеются открытые инциденты. Это обходное ре­шение также можно использовать во время сопоставления инцидентов[80].

Поиск решения

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

Срочное исправление

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

Определение окончательного решения

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

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

После окончания этапа выбора существует достаточно информации для подачи Запроса на Измене­ние. Далее исправление известной ошибки будет произведено в рамках Процесса Управления Изме­нениями.

Анализ результатов внедрения[81] (PIR)

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

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

Отслеживание и мониторинг

Данная задача предполагает выполнение мониторинга хода работ по разрешению проблем и извест­ных ошибок на всех этапах Контроля проблем и Контроля ошибок. Цели состоят в следующем:

? Определить, изменилась ли степень влияния или срочность проблемы, и на основании этого про­изводить корректировку приоритета проблемы.

? Вести мониторинг процесса выработки и реализации решения и контролировать правильность ис­полнения Запроса на Изменение. По этой причине Управление Изменениями регулярно передает информацию о состоянии Запросов на Изменение в Контроль ошибок.

Предоставление информации

В течение всего процесса информация об обходных решениях и быстрых исправлениях передается в Управление Инцидентами. Пользователи также могут информироваться об этом. Хотя данные пре­доставляет Процесс Управления Проблемами, их распространением занимается Служба Service Desk. Управление Проблемами использует Конфигурационную Базу Данных, а также Соглашения об Уровне Услуг, для уточнения, какую информацию и кому следует предоставлять.

5.4.3. Проактивное Управление Проблемами

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

5.5 Управление Процессом

5.5.1. Отчеты об Управлении и Ключевые показатели эффективности

Успешное Управление Проблемами проявляется в:

? сокращении количества инцидентов в результате разрешения проблем;

? сокращении времени, требуемом для разрешения проблем;

? уменьшении других затрат, связанных с разрешением проблем.

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

Отчеты об Управлении Проблемами могут быть достаточно объемными и охватывать следующие ас­пекты:

? Отчеты о времени исполнения: разделенные на Контроль проблем, Контроль ошибок и проактив­ное Управление Проблемами, а также разделенные между группой поддержки и поставщиком.

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

? Эффективность[82] Процесса Управления Проблемами: точное количество инцидентов до и после решения проблемы, зарегистрированные проблемы, количество поданных Запросов на Измене­ния и решенных известных ошибок.

? Баланс между реактивным и проактивным Управлением Проблемами: увеличение объема проактивного Управления Проблемами по сравнению с простым реагированием на инциденты свидетельствует о большей зрелости процесса.

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

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

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

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

5.5.2. Критические факторы успеха

Успешное Управление Проблемами зависит от следующих факторов:

? Эффективная автоматизированная регистрация инцидентов и эффективный контроль за состоя­нием инфраструктуры.

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

? Эффективность взаимодействия Управления Проблемами и Управления Инцидентами. При рас­пределении заданий и работ нужно учитывать конфликт интересов этих двух процессов: "тушение пожара" в рамках Управления Инцидентами и необходимость выяснения корневых причин в рамках Управления Проблемами.

5.5.3. Функции и роли

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

Руководитель Процесса Управления Проблемами

Руководитель Процесса несет ответственность за такие виды деятельности по Управлению Пробле­мами, как:

? разработка и поддержка подпроцессов Контроля проблем и Контроля ошибок;

? оценка эффективности и рациональности[83] работ по Контролю проблем и Контролю ошибок;

? предоставление Управленческой Информации;

? управление Персоналом, участвующим в Процессе Управления Проблемами;

? обеспечение необходимых ресурсов;

? разработка и совершенствование систем Контроля Проблем и Контроля Ошибок;

? анализ работы и оценка эффективности проактивного Управления Проблемами.

Роли поддержки деятельности по Управлению Проблемами

Ответственность персонала, выполняющего роли по решению проблем:

? Реактивное Управление:

? выявление и регистрация проблемы путем анализа информации об инцидентах;

? изучение проблем на основе их приоритетности;

? подача Запросов на Изменение;

? мониторинг устранения ошибок;

? подготовка рекомендаций по обходным решениям и быстрым исправлениям для Управления Инцидентами.

? Проактивное Управление:

? определение тенденций;

? подача Запросов на Изменения;

? предотвращение распространения проблем на другие системы.

5.6. Затраты и проблемы

5.6.1. Затраты

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

5.6.2. Проблемы

На следующие вопросы следует обратить внимание при реализации Процесса Управления Пробле­мами и, по возможности, их избежать:

? Плохая связь между Процессами Управления Инцидентами и Управления Проблемами: если связь между работами над инцидентами, проблемами и известными ошибками неадекватна, Про­цесс Управления Инцидентами не будет знать об обходных решениях для проблем, а Процессу Уп­равления Проблемами будет трудно выполнять оценку и мониторинг проблем. В результате этого будет существовать меньше доступной информации об инфраструктуре и данных о предыстории проблем. Поэтому успешное Управление Проблемами во многом зависит от этого взаимодействия.

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

? Отсутствие понимания важности процесса: если существовавший ранее подход был неформаль­ным, может возникнуть сопротивление четкому подходу к Управлению Проблемами, особенно в плане документирования и ведения записей. По этой причине сотрудники, участвующие в Упра­влении Проблемами, должны быть своевременно информированы о разработке и реализации процесса.

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

6.1. Введение

В каждой ИТ-организации имеется информация об ИТ-инфраструктуре. Она чаще всего появляется по­сле реализации крупных проектов, которые обычно завершаются проведением аудита и анализом ре­зультатов. Главным в работе с такой информацией является поддержание ее в актуальном состоянии. Процесс Управления Конфигурациями помогает получать достоверную и актуальную информацию об ИТ-инфраструктуре. Важным в этой информации является то, что в нее входят данные не только о кон­кретных единицах конфигурации (Конфигурационных Единицах[84] или CI), но и о том, как они связаны друг с другом. Взаимоотношения и взаимосвязи между Конфигурационными Единицами составляют основу для анализа степени воздействия инцидентов, проблем, изменений и т. д. на ИТ-инфраструктуру. Процесс Управления Конфигурациями проверяет, правильно ли регистрируются изменения в ИТ-инфраструктуре, включая взаимоотношения между Конфигурационными Единицами (CI), и ведет мониторинг статуса ИТ-компонентов чтобы гарантировать наличие точной информации о версиях существующих Конфигурационных Единиц (CIs).

В случае если Управление Конфигурациями реализовано эффективно, то этот процесс может дать информацию о следующем:

? Финансовая информация и политика компании в отношении продуктов

? Какие ИТ-компоненты используются в настоящее время по каждой модели (версии) и на про­тяжении какого времени?

? Какие тенденции существуют в разных группах продуктов?

? Какова текущая и остаточная стоимость ИТ-компонентов?

? Какие ИТ-компоненты нужно выводить из операционной среды и какие требуют модернизации?

? Сколько будет стоить замена определенных компонентов?

? Какие имеются лицензии и достаточно ли их?

? Какие контракты на сопровождение следует пересмотреть?

? Какова степень стандартизации инфраструктуры?

? Выявление неисправностей и оценка результатов

? Какие ИТ-компоненты необходимы для поддержки процесса восстановления в случае чрезвы­чайной ситуации?

? Будет ли работать план восстановления на случай чрезвычайных обстоятельств, если была из­менена Конфигурация Инфраструктуры?

? Какие ИТ-компоненты будут затронуты при развертывании новых сервисов?

? Как оборудование подключено к сети?

? Какие программные модули входят в каждый из комплектов программного обеспечения?

? Какие ИТ-компоненты затрагиваются изменениями?

? Какие Запросы на Изменения (RFC) конкретных ИТ-компонентов находятся на рассмотрении и какие инциденты и проблемы произошли в прошлом и сейчас продолжают оставаться актуальными?

? Какие ИТ-компоненты вызывают известные ошибки?

? Какие ИТ-компоненты были закуплены у конкретного поставщика в течение определённого пе­риода?

? Предоставление услуг и выставление счетов

? Какие Конфигурации ИТ-компонентов являются существенными для определенных услуг?

? Какие ИТ-компоненты используются в том или ином месте и кем?

? Какие стандартные ИТ-компоненты может заказать пользователь и какие из них поддержива­ются (каталог продуктов)?

6.1.1. Основные понятия

По терминологии процесса Управления Конфигурациями ИТ-компоненты и предоставляемые на их основе услуги называются Конфигурационными Единицами (CI). Каждый ИТ-компонент, чье на­личие и версия зарегистрированы, является Конфигурационной Единицей. Как видно из рис. 6.1. Конфигурационными Единицами могут быть технические средства, все виды программного обеспе­чения, активные и пассивные сетевые элементы, серверы, системные блоки, документация, процеду­ры, услуги и все другие ИТ-компоненты, контролируемые ИТ-организацией. Если Управление Конфигурациями применено к информационным системам, а не только к инфор­мационным технологиям, то Конфигурационная База Данных[85] (CMDB) может хранить и управлять детальной информацией о пользователях, персонале ИТ-организации и бизнес-структурах. Эти Конфигурационные Единицы также попадают под действие процесса Управления Изменениями, на­пример, при найме и увольнении работников.

Рис. 6.1. Конфигурационные Единицы

Все Конфигурационные Единицы должны быть включены в Конфигурационную Базу Данных (CMDB), которая отслеживает все ИТ-компоненты и взаимоотношения между ними. В самой при­митивной форме Конфигурационная База Данных представляет собой набор бумажных форм или электронных таблиц.

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

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

Управление Конфигурациями не следует путать с Управлением Активами.

? Управление Активами – это бухгалтерский процесс мониторинга амортизации активов, чья заку­почная цена превышает определенную величину. Мониторинг ведется путем учета закупочных цен, амортизации, месторасположения активов. Эффективно работающая система Управления Активами может послужить основой для системы Управления Конфигурациями.

? Управление Конфигурациями идет дальше, учитывая также информацию о взаимоотношениях между Конфигурационными Единицами и решая задачу стандартизации и авторизации единиц CI. Управление Конфигурациями также контролирует информацию о статусе ИТ-компонентов, их расположении, произведенных в них изменения и т. д.

6.2. Цель процесса

Цель процесса Управления Конфигурациями – содействие в Управлении Значимостью[86] ИТ-услуг (сочетание требований заказчика, качества и затрат) путем поддержки логической модели ИТ-инф­раструктуры и ИТ-услуг и предоставления информации о них другим бизнес-процессам. Это дости­гается посредством идентификации, мониторинга, контроля и предоставления информации о Кон­фигурационных Единицах и их версиях. Задачами данного процесса являются:

? точная регистрация детальной информации об ИТ-компонентах и услугах, предоставляемых орга­низацией;

? предоставление точной информации и документации для поддержки других процессов сервис-ме­неджмента.

6.2.1. Преимущества использования процесса

Управление Конфигурациями содействует рентабельному предоставлению высококачественных ИТ-услуг с помощью:

? Управления ИТ-компонентами – ИТ-компоненты являются крайне важным элементом при пре­доставлении ИТ-услуг. Каждая услуга включает одну или несколько Конфигурационных Единиц, и процесс Управления Конфигурациями контролирует, что происходит с этими единицами.

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

? Эффективного разрешения проблем – Управление Конфигурациями помогает в определении Конфигурационных Единиц, затронутых проблемой, и контролирует модификацию и замену этих элементов. Данный процесс также предоставляет информацию о тенденциях, которая является также входной информацией для Управления Проблемами.

? Более быстрой обработки изменений – Управление Конфигурациями помогает в проведении более быстрого и точного анализа степени влияния, поэтому изменения могут быть реализованы быстрее и эффективнее.

? Лучшего контроля аппаратного и программного обеспечения – распространение пакетов про­грамм по возможности нужно объединять с установкой (распространением) аппаратного обеспе­чения и проведением предварительного тестирования. Конфигурационную Базу Данных и Базисные Конфигурации (т. е. мгновенные "фотографии" состояния инфраструктуры) можно исполь­зовать для разработки плана тестирования и распространения конкретным группам пользовате­лей. В базе также содержится информация о проверенных версиях программного обеспечения, ко­торые можно использовать при проведении изменений в случае необходимости возврата в исход­ное состояние.

? Улучшенной безопасности – Управление Версиями дает информацию об авторизованных изме­нениях в Конфигурационных Единицах и использовании различных модификаций программного обеспечения. Такая информация из Конфигурационной Базы Данных также помогает в мониторинге лицензий.

? Соблюдения требований закона – незаконные копии будет выявляться при сравнении результа­тов аудиторской проверки с Конфигурационной Базой Данных. Это может принести дополни­тельную пользу организации, т. к. незаконные версии могут содержать вирусы, а процесс Управле­ния Конфигурациями может защитить организацию от их проникновения. В некоторых организа­циях не так легко помешать персоналу использовать незаконное и потенциально зараженное про­граммное обеспечение, тем не менее тот факт, что такие версии могут быть обнаружены с помо­щью процесса Управления Конфигурациями, Конфигурационной Базы Данных и аудиторских проверок и что по результатам проверок будут приняты дисциплинарные меры, послужат предос­тережением персоналу. На нарушение правил персонал обычно толкает мысль, что об этом никто не узнает.

? Более точного планирования расходов – Конфигурационная База Данных предоставляет ин­формацию о затратах на сопровождение и контракты, лицензии и продукцию с истекшим сроком эксплуатации.

? Лучшей поддержки процессов Управления Доступностью и Управления Мощностями – эти процессы в части планирования и анализа услуг зависят от правильной детальной информации о Конфигурациях.

? Крепкого надежного фундамента для Управления Непрерывностью ИТ-услуг - Конфигураци­онная База Данных, если имеется ее резервная копия в надежном месте, может играть важную роль в восстановлении услуг в случае чрезвычайных обстоятельств. База также помогает в опреде­лении Конфигурационных Единиц, необходимых для такого восстановления, включая соответст­вующие процедуры и руководства, если они входят в состав базы.

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

Рис. 6.2. Взаимоотношения между Конфигурационной Базой Данных и другими процессами (источник: OGC)

6.3. Процесс

Входом для процесса Управления Конфигурациями является информация об изменениях и инфор­мация из процесса Управления Закупками, а выходом – отчеты для других процессов и ИТ-руко­водства. Есть еще другой выход, когда Управление Конфигурациями предоставляет данные из Кон­фигурационной Базы Данных другим процессам, необходимые им для выполнения своих задач.

Процесс Управления Конфигурациями связан с многими другими процессами.

6.3.1. Управление Инцидентами

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

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

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

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

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

6.3.4. Управление Релизами

Процесс Управления Релизами дает информацию о планах выпуска релизов и их версиях, например, о плановых датах основных и второстепенных релизов, а также о произведенных изменениях. Перед выполнением изменения процесс запрашивает информацию о Конфигурационной Единице, напри­мер, статус CI, ее расположение, исходный код и т. д.

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

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

6.3.6. Управление Финансами

Процессу Управления Финансами необходима информация об использовании услуг, например, у кого имеется в распоряжении PC. Процесс объединяет эту информацию с данными из Соглашений об Уровне Услуг (SLA) для определения цены. Данный процесс также ведет мониторинг инвестиций и стоимости ИТ-компонентов (Управление Активами).

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

Процесс Управления Доступностью использует Конфигурационную Базу Данных для определения Конфигурационных Единиц, задействованных в услуге, для составления плана изменений и для вы­явления слабых мест, например, с помощью методики CFIA (Component Failure Impact Analysis – анализ влияния сбоев компонентов на предоставление сервиса). Доступность услуги (цепь компонентов инфраструктуры) определяется тем, насколько надежным является самый слабый компо­нент (звено цепочки). Процесс Управления Конфигурациями предоставляет информацию о составе цепочки, а также о каждом ее звене.

6.3.8. Управление Непрерывностью ИТ-услуг

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

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

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

6.3.10. Виды деятельности

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

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

? Идентификация: формируется процесс поддержки базы данных в актуальном состоянии. В этот этап входит разработка модели данник для регистрации всех ИТ-компонентов инфраструктуры, взаимоотношений между ними и информации о владельце этих компонентов или лица, ответст­венного за них, статусе единиц, а также об имеющейся документации. Также должны быть разра­ботаны процедуры создания новых Конфигурационных Единиц и для изменения уже существую­щих. Поскольку потребности в информации постоянно меняются, определение состава данных о Конфигурации также меняется.

? Контроль: контроль обеспечивает актуальное состояние Конфигурационной Базы Данных путем принятия, регистрации и мониторинга авторизованных и идентифицированных Конфигурацион­ных Единиц. Наличие контроля гарантирует, что ни одна Конфигурационная Единица не будет добавлена, изменена, заменена или удалена без соответствующего документа, например, утвер­жденного Запроса на Изменение или скорректированной спецификации.

? Мониторинг статуса: хранение текущей информации и истории статуса Конфигурационной Еди­ницы на протяжении ее жизненного цикла. С помощью мониторинга статуса можно отследить, как меняется статус единицы, например "в разработке", "в тестировании", "в наличии", "в использо­вании", - "выведено из рабочей среды".

? Верификация: верификация Конфигурационной Базы Данных путем аудита ИТ-инфраструкту­ры на наличие в ней зарегистрированных Конфигурационных Единиц и правильности регистра­ционных записей.

? Отчетность: предоставление информации в другие процессы и подготовка отчетов об использова­нии Конфигурационных Единиц, тенденциях и т. д.

Ниже дается подробное описание этих действий.

6.4. Виды деятельности

6.4.1. Планирование

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

6.4.2. Идентификация

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

Какие услуги и связанные с ними компоненты ИТ-инфраструктуры должны находиться под контролем Сервис-менеджмента и какая информация необходима для этого?

При разработке системы идентификации должны быть приняты решения относительно охвата (гра­ниц)[87] процесса и уровня детализации регистрируемой информации. Для каждого параметра (харак­теристики) следует определить владельца или заинтересованное лицо[88]. Чем больше параметров ре­гистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос "Что же регистрировать?" может быть сведен к перечню конкретных вопросов для определения тре­буемой информации, например:

? Какие ресурсы имеются для сбора и обновления информации?

? Насколько зрелыми являются наши административные и материально-технические (логистиче­ские) процессы?

? На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распростране­ние компонентов отдельно от основного компонента?

? Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и конт­ролироваться?

? Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диаг­ностики этих сбоев?

? Для каких компонентов следует регистрировать статус и его предысторию?

? Какие компоненты используются в организации в различных версиях или вариантах?

? Изменения в каких компонентах могут повлиять на возможности и доступность услуг?

? Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери?

? Какова настоящая и будущая информационная потребность у других процессов?

? Для каких компонентов требуется такая информация, как серийный номер, дата покупки и по­ставщик, и какая информация необходима для бухгалтерии?

? Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг?

? Какая информация необходима для выставления счетов заказчикам?

? Насколько реальны наши стремления, не нужна ли корректировка?

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

Охват (сфера действия, границы)[89]

При создании Конфигурационной Базы Данных и обновлении модели данных следует определить­ся, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфи­гурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как "электронные органайзеры" (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса? Границы, опреде­ленные для процесса Управления Конфигурациями, влияют на границы, в которых, например, про­цесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, прово­димый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и т. д.

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

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

Границы Конфигурационной Базы Данных могут включать аппаратное и программное обеспечение, а также документацию, например, Соглашения об Уровне Услуг (SLAs), процедуры, руководства, технические спецификации, организационные схемы, персонал и планы проектов. Как и другие Конфигурационные Единицы, эти документы физически могут находиться в разных местах, но ин­формация о них находится в базе данных с номерами версий, датами публикаций, именами авторов и т. д. В этом случае процессы Управления Конфигурациями и Управления Изменениями могут контролировать эти характеристики документов.

На рис. 6.3 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных. Отслеживание этих взаимоотношений облегчает определение степени воздействия инци­дентов на услуги. Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предо­ставление сервиса. Такая информация в дальнейшем может быть использована для улучшения ус­луг. У такой "сервисной" Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг. В приве­денном примере услуга "В" полностью выходит за границы базы данных. Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге "А", входят в сферу действия Конфигура­ционной Базы Данных (например, находятся в рассматриваемой организации), это означает, что ус­луга "А" не может полноценно поддерживаться.

Рис. 6.3. Охват Конфигурационной Базы Данных (источник: OGC)

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

Уровень Детализации CMDB

Определение Уровня Детализации для каждого типа Конфигурационных Единиц является важным этапом разработки процесса Управления Конфигурациями. Здесь нет универсальных решений. На этом этапе анализируется информация о Конфигурационных Единицах. Для определения Уровня Детализации составляется схема взаимоотношений между задействованными Конфигурационными Единицами и выбирается требуемая глубина детализации CMDB. Кроме того, определяются имена и атрибуты для Конфигурационных Единиц.

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

Взаимоотношения между Конфигурационными Единицами

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

? Взаимоотношения на физическом уровне:

? Является частью: это взаимоотношения типа "parent/child" ("родитель/ребенок"), например, дисковод является частью PC, а программный модуль – частью программы.

? Подключена к: например, PC подсоединен к сегменту сети.

? Требуется для: например, технические средства требуются для работы приложения.

? Взаимоотношения на логическом уровне:

? Является копией: что-то является копией стандартного модуля, Базисной Конфигурации или программы.

? Связано с: процедурой, руководством и документацией, Соглашением об Уровне Услуг или группой заказчиков.

? Используется: например, Конфигурационная Единица, участвующая в предоставлении услуги, или программный модуль, к которому обращаются несколько программ.

Глубина CMDB

При определении Уровней Конфигурационных Единиц создается иерархия компонентов и элементов. Выбираются родительские Конфигурационные Единицы и определяется количество уровней, необхо­димых для их детализации. На самом высоком уровне находится сама ИТ-инфраструктура. Самым низким уровнем является наиболее детальный уровень, на котором необходимо осуществлять конт­роль. Включение Конфигурационных Единиц в Конфигурационную Базу Данных будет целесообраз­ным только в том случае, если информация об этих CI будет полезна для других процессов ITIL. Определяя уровни и глубину Конфигурационной Базы Данных, следует помнить, что изменение в любой Конфигурационной Единице, зарегистрированной в CMDB, должно пройти через формаль­ный процесс Управления Изменениями, прежде чем оно будет произведено. Поэтому регистрируя такой компонент как компьютерная мышь в Конфигурационной Базе Данных, создается ситуация, при которой любой Запрос на новую мышь уже не будет проходить как Запрос на Обслуживание[90], а должен будет проводиться через процесс Управления Изменениями в форме Запроса на Изменение (RFC). Это показательный пример для организаций, которые чрезмерно увлекаются детализацией.

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

? Чем больше уровней в базе данных, тем больше информации надо обрабатывать. Это ведет к уве­личению рабочей нагрузки и созданию более сложной CMDB.

? Чем меньше уровней, тем слабее контроль и хранится меньше информации об инфраструктуре.

Если степень детализации CMDB слишком мала, то становится невозможным эффективный мони­торинг изменений, происходящих в компонентах нижнего уровня. В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой едини­цы[91]. Например, PC с двумя видами жесткого диска будет проходить как Вариант "А" и Вариант "В". Если в дочернем компоненте много изменений, их нумерация становится сложной и трудной для со­провождения. Однако, если имеются уровни, расположенные ниже, то варианты можно поддержи­вать на соответствующем уровне. Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки. Кроме того, при выполнении диагностики можно ставить такие вопросы, как: "Какой драйвер нужен для этого типа технических средств?", "К какому сегменту подсоединена сетевая плата?" и "Какая программа использует эту библиотеку?".

Соглашения о присвоении имен[92]

У каждой Конфигурационной Единицы должно быть уникальное имя, которое отличает его от дру­гих единиц. Самым элементарным вариантом является простая система присвоения номеров с воз­можным делением на диапазоны для каждой области. Для вновь созданной Конфигурационной Единицы генерируется новый номер. Имена, по возможности, должны иметь смысловое значение для облегчения контактов с пользователями.

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

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

? Контролируемые документы, такие как Соглашения об Уровне Услуг (SLA), процедуры и органи­зационные схемы должны маркироваться с указанием номера Конфигурационной Единицы, номе­ра версии и даты выпуска версии.

? Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения[93] (DSL), см. главу "Управление Релизами". Все компоненты программного обеспече­ния должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии.

Атрибуты

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

Таблица 6.1. Примеры атрибутов

В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инци­дентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.

Таблица 6.2. Примеры других записей, связанных с Конфигурационными Единицами

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

Таблица 6.3. Атрибуты взаимоотношений

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

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

Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оператив­ной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют та­кую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предостав­ляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.

Для облегчения ввода и обновления атрибутов можно использовать открывающиеся меню[94]. Можно устанавливать связи и с другими надежными источниками для получения информации о месторас­положении Конфигурационной Единицы, пользователях, подразделениях, номерах телефонов, вла­дельцах и параметрах бюджета. Вариантов много, но всегда следует учитывать нагрузку, связанную с поддержкой актуальности этих файлов.

Базисная Конфигурация

Базисная Конфигурация – это мгновенный снимок группы Конфигурационных Единиц, сделан­ный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:

? авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов);

? стандартных Конфигурационных Единиц для учета информации о стоимости;

? базы[95] при разработке и тестировании новых Конфигураций;

? для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигура­цией после проведения изменений;

? стандарта для поставки Конфигураций пользователям, например, "стандартное рабочее место";

? базы при установке нового программного обеспечения.

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

Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем дают­ся Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и кото­рые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица являет­ся копией единицы из Каталога с ее номером и меткой.

До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:

? Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?

? Финансы: приемлемы ли затраты на поддержку?

? Влияние: приемлем ли уровень воздействия модели/продукта на услугу?

Регистрация

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

6.4.3. Мониторинг статуса

Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет ре­гистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.

Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы

Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом "неэксплуатирующиеся запасные части", то эти тех­нические средства нельзя перераспределять куда-либо еще без предварительного согласования, на­пример, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.

Может быть использована следующая классификация:

? Новые Конфигурационные Единицы:

? В разработке/заказе;

? Протестирована;

? Принята (по результатам тестирования).

? Существующие Конфигурационные Единицы:

? Получена (принята в операционную среду);

? Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;

? Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и до­кументация (также являющаяся Конфигурационной Единицей) будут предоставлены;

? На обслуживании;

? Не функционирует.

? Архивированные Конфигурационные Единицы:

? Выведена из операционной среды;

? Исключена (deleted);

? Удалена (removed);

? Похищена;

? Продана или истек срок аренды/лизинга;

? В архиве в ожидании безвозмездного дарения, продажи или уничтожения;

? Уничтожена.

? Все Конфигурационные Единицы:

? В наличии;

? Получена по заказу или доступна новая версия;

? Тестируется;

? Одобрена для инсталляции;

? Активная Конфигурационная Единица находится в использовании;

? Запасные части.

6.4.4. Контроль

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

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

Управление Конфигурациями контролирует все ИТ-компоненты, существующие в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение – при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library – DSL).

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

Если по согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инф­раструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигураци­онной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями[96]. Формализованные записи об изменениях являются основным источни­ком информации об изменениях в инфраструктуре, которая используется для обновления Конфигу­рационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операцион­ной средой и проведения закупок.

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

? добавление Конфигурационной Единицы;

? изменение статуса Конфигурационной Единицы, например, "работает" или "не работает" (полез­но для процесса Управления Доступностью);

? изменение владельца Конфигурационной Единицы;

? изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Еди­ницами;

? удаление Конфигурационной Единицы;

? возникновение новых взаимоотношений Конфигурационной Единицы с каким-либо сервисом, другой Конфигурационной Единицей, документацией и т. д.;

? возобновление или изменение лицензии;

? обновление детальной информации о Конфигурационной Единице после аудита.

6.4.5. Верификация и аудит

Аудит проводится для проверки, насколько точно отражена текущая ситуация в CMDB. Например, ин­струментальные средства аудита могут автоматически выполнять анализ рабочих станций и формиро­вать отчеты о текущей ситуации и статусе ИТ-инфраструктуры. Эта информация будет использоваться для проверки и обновления Конфигурационной Базы Данных. Аудит возможен в следующих ситуациях:

? после внедрения новой Конфигурационной Базы Данных;

? к примеру, спустя полгода с момента внедрения;

? перед серьезными изменениями и после них;

? после чрезвычайных обстоятельств;

? в любое другое удобное время.

При проведении аудита рассматриваются следующие вопросы:

? Регистрируются ли в CMDB данные всех Запросов на Изменения на всех этапах их реализации, и контролирует ли процесс Управления Конфигурациями эту регистрацию?

? Находится ли Конфигурационная База Данных в актуальном состоянии, если нет, то почему? Ка­кое воздействие это оказывает на процесс Управления Изменениями (анализ текущего воздейст­вия запланированных изменений)?

? Производится ли присвоение имен новым Конфигурационным Единицам в соответствии с согла­шением о присвоении имен?

? Правильно ли используются варианты?

? Правильно ли регистрируются Базисные Конфигурации и становятся ли они сразу же доступны­ми к использованию?

? Соответствует ли содержимое Библиотеки эталонного программного обеспечения (DSL) и Скла­да эталонного аппаратного обеспечения (DHS) информации в Конфигурационной Базе Данных? Если нет, то почему?

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

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

6.5. Контроль процесса

6.5.1. Отчеты и Ключевые показатели эффективности

В отчет по процессу Управления Конфигурациями возможно включение следующей информации:

? информация о качестве процесса;

? расхождения между регистрационными записями и реальной ситуацией, обнаруженные во время аудита (дельта);

? количество случаев, когда используется неавторизованная Конфигурация;

? количество случаев, когда зарегистрированная Конфигурация не находилась на своем месте;

? отклонения на Уровне Атрибутов, обнаруженные аудиторскими проверками;

? длительность обработки Запросов на Регистрацию информации;

? перечень Конфигурационных Единиц, в отношении которых количество зарегистрированных ин­цидентов или изменений превышало заданную величину;

? статистическая информация о структуре и составе ИТ-инфраструктуры;

? данные о росте и другая информация о развитии ИТ-инфраструктуры;

? сводные данные, отчеты и предложения по улучшению, например, рекомендации по изменению охвата (границ) процесса и Уровня Конфигурационных Единиц, отслеживаемых процессом Управления Конфигурациями, связанные с изменениями в бизнесе, технических средствах, рыночных ценах и т. д.;

? расходы на персонал при внедрении процесса.

6.5.2. Критические факторы успеха

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

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

6.5.3. Функции и роли

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

? предложения по изменению сферы действия и Уровня Детализации Процесса Управления Конфи­гурациями;

? информированность всей организации о существующем Процессе Управления Конфигурациями;

? обеспечение процесса персоналом и его обучение;

? разработка системы идентификации и соглашений о присвоении имен;

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

? оценка существующих систем и внедрение новых систем автоматизации процесса;

? планирование и внедрение системы наполнения информации в Конфигурационной Базе Данных;

? формирование отчетов;

? организация аудиторских проверок.

6.6. Затраты и проблемы

6.6.1. Затраты

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

? дополнительные технические средства и их конфигурирование;

? дополнительное программное обеспечение и его конфигурирование;

? лицензии, пропорционально количеству пользователей;

? разработку приложений и базы данных, наполнение их данными, настройку на требования заказ­чика и внедрение;

? поддержку и сопровождение базы данных;

? дополнительный персонал, необходимый для работы процесса.

6.6.2. Проблемы

ИТ-организация должна четко определить свои намерения относительно того, какие характеристи­ки ИТ-инфраструктуры должны регистрироваться и обеспечить необходимые руководящие ресурсы для исполнения намеченного. В организации должна существовать твердая приверженность в ис­пользовании Конфигурационной Базы Данных (CMDB). Необходимо произвести перенос всех ра­нее использованных данных из других баз в CMDB.

На успешную реализацию процесса могут повлиять следующие проблемы:

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

? Неадекватная система ручной обработки – некоторые организации стараются как можно доль­ше хранить данные на бумажных носителях и покупают автоматизированные средства только тог­да, когда работать становится невозможно. Это может приводить к задержкам в работе, путанице, потере персонала и ресурсов и т. д. Рекомендуется закупать автоматизированные средства обра­ботки как можно раньше, ориентируясь на функциональные требования процесса.

? Влияние срочных изменений – всегда будут возникать ситуации, когда нужно срочно произве­сти изменение. Часто это происходит во внерабочее время. Если изменяемые Конфигурационные Единицы находятся под контролем Конфигурационной Базы Данных, то рекомендуется немед­ленно произвести запись результатов изменения в CMDB, но может возникнуть ситуация, когда отсутствует сотрудник, ответственный за эту задачу. В этом случае регистрацию изменений и об­новление CMDB необходимо будет сделать при первой возможности.

? Чрезмерно плотный график работы – если график изменений (Запросов на Изменения) не оста­вляет времени на выполнение действий в рамках процесса Управления Конфигурациями, то в ра­боте могут появляться задержки и данный процесс будет восприниматься как препятствие. Следует составлять реалистичные графики, основываясь на прошлом опыте.

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

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

Глава 7 Управление Изменениями

7.1. Введение

Быстрое развитие ИТ-технологий и рынка привели к тому, что сейчас изменения стали обычным де­лом. Однако опыт показывает, что инциденты, влияющие на бизнес-приложения, часто бывают вы­званы изменениями. Причины таких инцидентов могут быть различными: халатность сотрудников, недостаток ресурсов, недостаточная подготовка, слабый анализ воздействия изменения, несовер­шенство испытаний или "болезни роста". Если инциденты, связанные с изменениями, не будут кон­тролироваться, из-под контроля может выйти все предоставление ИТ-услуг и сам бизнес. Число ин­цидентов может увеличиваться, каждый из них будет требовать принятия срочных мер, что в свою очередь может привести к возникновению новых инцидентов. Ежедневное планирование часто не в состоянии учитывать увеличивающуюся рабочую нагрузку. Это может повлиять на повседневную работу и на сопровождение ИТ-услуг.

Целью Процесса Управления Изменениями является руководство проведением изменений и ограничение числа инцидентов, вызванных изменениями. Девиз Процесса Управления Изме­нениями:

Не всякое изменение является улучшением, но всякое улучшение является изменением.

На рис. 7.1 показан цикл изменений, вызванный предложениями на новые разработки и улучшения (Процессы Предоставления услуг и Управления Проблемами), Запросами (адресованные в Процесс Управления Изменениями) и требуемыми решениями (Процесс Управление Проблемами):

? Инновации и усовершенствования – внедрение новых услуг и новых технических средств в ИТ-инфраструктуру становится причиной появления новых регулярно возникающих ошибок[98] в ИТ-инфраструктуре.

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

? Корректирующие меры — нацелены на исправление недавно появившихся регулярно возникаю­щих ошибок.

Рис. 7.1. Входы Процесса Управления Изменениями

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

7.1.1. Основные термины

Две точки принятия решения об изменениях

Существуют две точки принятия решения о проведении изменений:

? Руководитель Процесса Управления Изменениями – лицо, ответственное за предварительный просмотр (фильтрацию) и классификацию Запросов на Изменения[99] (RFC). В больших организа­циях в помощь Руководителю Процесса могут существовать Координаторы изменений, осуществ­ляющие взаимодействие между ним и различными подразделениями организации. Одной из задач Процесса Управления Изменениями является получение требуемой авторизации изменения. В определенной степени сам процесс уже имеет полномочия, но для проведения некоторых измене­ний может потребоваться согласование с руководством ИТ (например, с Руководящим комите­том[100] или Исполнительным комитетом[101]). Руководитель Процесса Управления Изменениями также несет ответственность за планирование и координацию проведения изменений.

? Консультативный комитет по изменениям[102] (CAB) – консультативный орган, регулярно собираю­щийся для оценки и планирования изменений. Чаще всего одно или несколько значительных из­менений выносятся на обсуждение Комитета. Отдельно создается комитет по срочным изменениям[103] (ЕС), который назначается руководством для принятия чрезвычайных решений. Состав Кон­сультативного комитета является гибким и включает представителей всех основных ИТ-подразде­лений:

? Руководителя по Управлению Изменениями (председатель);

? Руководитель по Управлению (Уровнями) Услуг;

? Представителей Службы Service Desk и Процесса Управления Проблемами;

? Руководителей линейных подразделений компании;

? Бизнес-руководителей (или их представители) со стороны заказчика;

? Представителей пользователей;

? Представителей разработчиков приложений;

? Администраторов программного обеспечения и системных администраторов;

? Представителей поставщиков.

Охват (сфера действия или границы)[104] процесса

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

Для того, чтобы обеспечить эффективное взаимодействие Процессов Управления Изменениями и Управления Конфигурациями, необходимо регистрировать изменения и обновлять соответствующие записи в CMDB. Можно допустить, что ряд повседневных заданий, точно определенных и подчиняющихся установленным процедурам (т. е. стандартных заданий), не требуют контроля со стороны Процесса Управления Изменениями. Примерами таких заданий могут быть установка кассет для резервного копирования, создание идентификаторов (ID) пользователей и т. д. Эти действия не обрабатываются как изменения, а самое большее классифицируются как Запросы на Обслуживание в рамках Процесса Управления Инцидентами. Внимательное изучение стандарт­ных действий может быть полезно для предотвращения излишней бюрократизации Процесса Уп­равления Изменениями.