Процесс Управления Изменениями использует Конфигурационную Базу Данных для оценки степени воздействия планируемых изменений. Данный процесс авторизует проведение изменений, и эти изменения должны быть связаны с соответствующими Конфигурационными Единицами. Управление Изменениями несет ответственность за регистрацию Запросов на Изменения и предоставляет важную входную информацию для обновления Конфигурационной Базы Данных.
Процесс Управления Релизами дает информацию о планах выпуска релизов и их версиях, например, о плановых датах основных и второстепенных релизов, а также о произведенных изменениях. Перед выполнением изменения процесс запрашивает информацию о Конфигурационной Единице, например, статус CI, ее расположение, исходный код и т. д.
Процессу Управления Уровнем Услуг нужна информация о характеристиках услуг и взаимоотношениях между услугами и лежащей в их основе инфраструктурой. Данные из Соглашений об Уровне Услуги в качестве атрибутов могут храниться в Конфигурационной Базе Данных вместе с другой информацией о Конфигурационных Единицах. Данные об Уровне Сервиса (например, "золотой", "серебряный", "бронзовый") записываются для соответствующей сервисной Конфигурационной Единицы или CI для используемого программного или технического компонента.
Процессу Управления Финансами необходима информация об использовании услуг, например, у кого имеется в распоряжении PC. Процесс объединяет эту информацию с данными из Соглашений об Уровне Услуг (SLA) для определения цены. Данный процесс также ведет мониторинг инвестиций и стоимости ИТ-компонентов (Управление Активами).
Процесс Управления Доступностью использует Конфигурационную Базу Данных для определения Конфигурационных Единиц, задействованных в услуге, для составления плана изменений и для выявления слабых мест, например, с помощью методики CFIA (Component Failure Impact Analysis – анализ влияния сбоев компонентов на предоставление сервиса). Доступность услуги (цепь компонентов инфраструктуры) определяется тем, насколько надежным является самый слабый компонент (звено цепочки). Процесс Управления Конфигурациями предоставляет информацию о составе цепочки, а также о каждом ее звене.
Процесс Управления Непрерывностью ИТ-услуг использует стандартные Конфигурации из Конфигурационной Базы Данных (Базисные Конфигурации) для формулирования требований к восстановлению услуг в случае возникновения чрезвычайных обстоятельств и проверяет наличие этих Конфигураций на запасной территории.
Процесс Управления Мощностями использует данные из Конфигурационной Базы Данных для оптимизации ИТ-инфраструктуры, распределения рабочей нагрузки и разработки плана мощностей.
Хотя процесс Управления Конфигурациями, как и другие процессы, представляет собой логическую последовательность действий, в данном процессе они не всегда выполняются строго последовательно. Виды деятельности при Управлении Конфигурациями имеют тенденцию выполняться параллельно. Приведенная ниже последовательность, прежде всего, отражает очередность действий при разработке процесса, а также при обработке и реализации новых информационных требований.
- Планирование: определяются стратегия, политика и задачи процесса, анализируется имеющаяся информация, определяются инструментальные средства и ресурсы, создаются интерфейсы с другими процессами, проектами, поставщиками и т. д.
- Идентификация: формируется процесс поддержки базы данных в актуальном состоянии. В этот этап входит разработка модели данник для регистрации всех ИТ-компонентов инфраструктуры, взаимоотношений между ними и информации о владельце этих компонентов или лица, ответственного за них, статусе единиц, а также об имеющейся документации. Также должны быть разработаны процедуры создания новых Конфигурационных Единиц и для изменения уже существующих. Поскольку потребности в информации постоянно меняются, определение состава данных о Конфигурации также меняется.
- Контроль: контроль обеспечивает актуальное состояние Конфигурационной Базы Данных путем принятия, регистрации и мониторинга авторизованных и идентифицированных Конфигурационных Единиц. Наличие контроля гарантирует, что ни одна Конфигурационная Единица не будет добавлена, изменена, заменена или удалена без соответствующего документа, например, утвержденного Запроса на Изменение или скорректированной спецификации.
- Мониторинг статуса: хранение текущей информации и истории статуса Конфигурационной Единицы на протяжении ее жизненного цикла. С помощью мониторинга статуса можно отследить, как меняется статус единицы, например "в разработке", "в тестировании", "в наличии", "в использовании", - "выведено из рабочей среды".
- Верификация: верификация Конфигурационной Базы Данных путем аудита ИТ-инфраструктуры на наличие в ней зарегистрированных Конфигурационных Единиц и правильности регистрационных записей.
- Отчетность: предоставление информации в другие процессы и подготовка отчетов об использовании Конфигурационных Единиц, тенденциях и т. д.
Ниже дается подробное описание этих действий.
Задачи процесса Управления Конфигурациями, сфера его действия, а также приоритеты должны определяться в рамках Сервис-менеджмента и обязаны соответствовать бизнес-целям организации. Соответствующие этапы в реализации Управления Конфигурациями выходят за рамки данной книги.
Идентификация связана с определением и поддержкой соглашений о присвоении имен и нумерации версий физических компонентов инфраструктуры, взаимоотношений между ними и атрибутов. Базисные Конфигурации Аппаратного Обеспечения, используемого в настоящий момент и в будущем, описываются в форме специальных групп Конфигурационных Единиц (кластеров CI). Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в следующем:
Какие услуги и связанные с ними компоненты ИТ-инфраструктуры должны находиться под контролем Сервис-менеджмента и какая информация необходима для этого-
При разработке системы идентификации должны быть приняты решения относительно охвата (границ)[87]процесса и уровня детализации регистрируемой информации. Для каждого параметра (характеристики) следует определить владельца или заинтересованное лицо[88]. Чем больше параметров регистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос "Что же регистрировать-" может быть сведен к перечню конкретных вопросов для определения требуемой информации, например:
- Какие ресурсы имеются для сбора и обновления информации-
- Насколько зрелыми являются наши административные и материально-технические (логистические) процессы-
- На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распространение компонентов отдельно от основного компонента-
- Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и контролироваться-
- Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диагностики этих сбоев-
- Для каких компонентов следует регистрировать статус и его предысторию-
- Какие компоненты используются в организации в различных версиях или вариантах-
- Изменения в каких компонентах могут повлиять на возможности и доступность услуг-
- Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери-
- Какова настоящая и будущая информационная потребность у других процессов-
- Для каких компонентов требуется такая информация, как серийный номер, дата покупки и поставщик, и какая информация необходима для бухгалтерии-
- Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг-
- Какая информация необходима для выставления счетов заказчикам-
- Насколько реальны наши стремления, не нужна ли корректировка-
Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить. Следует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине). Понятие детализации включает в себя: количество уровней в базе данных, взаимоотношения, подлежащие мониторингу, соглашения о присвоении имен и атрибуты. Все они будут рассмотрены ниже.
Охват (сфера действия, границы) [89]
При создании Конфигурационной Базы Данных и обновлении модели данных следует определиться, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфигурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как "электронные органайзеры" (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса- Границы, определенные для процесса Управления Конфигурациями, влияют на границы, в которых, например, процесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, проводимый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и т. д.