Определения

Конфигурационная единица (CI) – ИТ- компонент, который:

· контролируется ИТ-организацией;

· наличие и версия которого зарегистрированы.

Конфигурационная база данных – совокупность СI и их связей.

СI это –

· технические средства

· все виды ПО

· активное и пассивное сетевое оборудование

· серверы

· системные блоки

· документация

· деловые процедуры

· бизнес-пользователи

· персонал ИТ-организации

 

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

услуг?

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

1 Configuration Management Data Base - CMDB.

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

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

Если Управление Конфигурациями применено к информационным системам, а не только к информационным технологиям, то Конфигурационная База Данных¹ (CMDB) может хранить и управлять детальной информацией:

· о пользователях,

· персонале ИТ-организации

· и бизнес- структурах.

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

 

Авторизованная (базисная) конфигурация – нормальная, проектная, эталонная конфигурация IT-инфраструктуры.

Фактическая конфигурация – конфигурация де-факто с учетом всех «заплаток» врменных решения и обходных путей. Аналог – нормальная диспетчерская схема городской электрической сети и оператиная схема – с учетом всех вынужденных переключений, связанных с авариями в кабельных сетях и подстанциях.

 

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

Некоторые платформы предоставляют такой вид контроля.

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

 

He следует путать Конфигурационную Базу Данных со складскими или инвентаризационными базами данных (ТАМ НЕТ (или почти нет) технологических СВЯЗЕЙ!).

 

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

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

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

Таблица 1. Основные отличия Управления конфигурациями от технического отслеживания ИТ активов

№	Управление конфигурациями	Техническое отслеживание ИТ активов
1.	Учет элементов с точки зрения разработки, поддержки и предоставления ИТ услуг	Учет элементов с точки зрения финансового контроля
2.	Связи между элементами нужны для оценки технического воздействия (например, доступности ИТ услуги)	Связи между элементами нужны для оценки финансового воздействия (например, для расчета совокупной стоимости владения, ТСО)
3.	Жизненный цикл элементов, как правило, начинается с поставки на склад или даже с установки по месту эксплуатации	Жизненный цикл элементов, как правило, начинается с закупки
4.	Как правило, интеграция с бухгалтерским учетом не требуется	Требуется достаточно сильная интеграция с бухгалтерским учетом (интерфейсы между процессами и системами автоматизации)
5.	Как правило, учет связей с контрактами на поставку, номерами договоров, партиями поставки не требуется	Обычно требуется учет связей с контрактами на поставку, номерами договоров, партиями поставки

 

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

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

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

2. 2. Связь процесса управления конфигурациями с другими процессами.

 

Входом для процесса Управления Конфигурациями является информация об изменениях и информация из процесса Управления Закупками, а выходом — отчеты для других процессов и ИТ- руководства.

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

 

· Процесс управления Инцидентами (ПУИ):

ПУИПоставляет:

Ø Регистрационные данные инцидентов

Ø Привязки Инцидентов к CI

ПУИИспользует: связи CI с:

Ø Проблемой

Ø Известной ошибкой ли обходным решением

Ø Заказчиком

Ø Услугой

 

· Процесс управления Проблемами (ПУПр)

ПУПрПоставляет:

Ø Регистрационные данные по проблемам

Ø Привязки проблем или известных ошибок к CI

ПУПр Использует:

Ø сравнение авторизованной конфигурации с фактической конфигурацией CMDB для выявления возможных дефектов и отклонений в инфраструктуре.

· Процесс управления Изменениями (ПУИз)

ПУИзПоставляет:

Ø Привязывает изменения к CI (включая ПО, АО, услуги…)

Ø Авторизует проведение изменений (придает легитимность проводимым изменениям)

ПУИзИспользует:

Ø СМДВ для оценки степени воздействия планируемых изменений.

· Процесс управления Релизами (ПУР)

ПУРПоставляет:

Ø Информацию о планах выпуска релизов и их версиях.

Ø Информацию о произведенных в релизах изменениях CI

ПУРИспользует:

Ø Информацию об CI, например: статус, расположение, исходный код….

· Процесс управления Уровнем услуг (ПУУу)

ПУРПоставляет:ничего

ПУУу Использует:

Ø Данные из соглашений об Уровне Услуги и о характеристиках услуг (например, «золотой, «сеебряный», «Бронзовый…)

Ø Информацию о взаимоотношениях между услугами и обеспечивающей инфраструктурой

· Процесс управления Финансами (ПУФ)

ПУФ Поставляет:

Ø Информацию о стоимости ИТ-активов.

ПУФ Использует:

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

 

· Процесс управления Доступностью (ПУД)

ПУД Поставляет:

Ø Информацию о доступности услуг, перечисленных в SLA.

ПУД Использует:

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

· Процесс управления мощнстями (ПУМ)

ПУМ Поставляет:

Ø ничего

ПУМ Использует:

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

 

3. 3. Виды деятельности процесса управления конфигурациями

 

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

■ Планирование: определяются:

Ø стратегия, политика и задачи процесса,

Ø анализируется имеющаяся информация,

Ø определяются инструментальные средства и

Ø определяются ресурсы,

Ø создаются интерфейсы с другими процессами, проектами, поставщиками и т. д.

■ Идентификация:

Ø формируется процесс поддержки базы данных в актуальном состоянии.

Ø разработка модель данных СMDB

Ø процедуры создания новых Конфигурационных Единиц и для изменения уже существующих.

■ Контроль:

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

Ø Наличие контроля гарантирует, что ни одна Конфигурационная Единица не будет добавлена, изменена, заменена или удалена без соответствующего документа, например, утвержденного Запроса на Изменение или скорректированной спецификации.

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

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

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

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

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

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

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

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

Идентификация связана с:

Ø Определением состава объектов инфраструктуры, контролируемых через CMDB, а также их взаимосвязей (объектная модель)

Ø определением и поддержкой соглашений о присвоении имен и

Ø нумерацией версий компонентов инфраструктуры,

Ø определением состава атрибутов (атрибутивная модель).

Ø Определением состава регистрируемых событий (событийная модель).

 

Базисные Конфигурации объектов IT-инфрпаструктуры, используемых в настоящий момент и в будущем описываются в форме специальных групп Конфигурационных Единиц (кластеров CI).

 

Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в следующем:

 

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

 

При разработке системы идентификации должны быть приняты решения:

Ø относительно охвата (границ)^[1] процесса и

Ø уровня детализации регистрируемой информации.

 

Для каждого параметра (характеристики) следует определить владельца или заинтересованное лицо².

Чем больше параметров регистрируется, тем больше усилий потребуется на обновление этой информации.

 

Общий вопрос «Что же регистрировать?» может быть сведен к перечню конкретных вопросов для определения требуемой информации, например:

 

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

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

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

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

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

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

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

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

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

 

Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить.

Следует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине)..

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

 

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

 

Например, следует ли включать в сферу действия данного процесса такие компоненты, как «электронные органайзеры» (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса?

 

Границы, определенные для процесса Управления Конфигурациями, влияют на:

Ø границы, в которых, например, процесс Управления Проблемами выполняет диагностирование,

Ø на анализ степени воздействия, проводимый процессом Управления Изменениями,

Ø на планирование, выполняемое процессом Управления Доступностью и т. д .

 

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

Примерами таких областей могут стать:

Ø настольные рабочие места,

Ø системы передачи данных,

Ø файловые сервисы,

Ø сервисы печати и прикладного ПО,

Ø центральная процессинговая система,

Ø базы данных,

Ø телефонные услуги.

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

 

Границы Конфигурационной Базы Данных могут включать:

Ø аппаратное и программное обеспечение,

Ø а также документацию, например, Соглашения об Уровне Услуг (SLAs),

Ø процедуры,

Ø руководства,

Ø технические спецификации,

Ø организационные схемы,

Ø персонал и

Ø планы проектов.

 

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

В этом случае процессы Управления Конфигурациями и Управления Изменениями могут контролировать эти характеристики документов.

 

На рис.2 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных.

Отслеживание этих взаимоотношений облегчает определение степени воздействия инцидентов на услуги.

Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предоставление сервиса.

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

У такой «сервисной» Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг.

В приведенном примере услуга ««В»» полностью выходит за границы базы данных.

Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге ««А»», входя в сферу действия Конфигурационной Базы Данных (например, находятся в рассматриваемой организации), это означает, что услуга «А» не может полноценно поддерживаться.

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

Будут ли единицы со статусом «в разработке» или «заказана» включены в базу данных или же их включат в CMDB только после того, как они будут введены в работу?

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

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

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

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

Определение Уровня Детализации для каждого типа Конфигурационных Единиц является важным этапом разработки процесса Управления Конфигурациями.

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

При определении глубины Конфигурационной Базы Данных и взаимоотношений между Конфигурационными Единицами, отражаемыми в CMDB, нужно добиться сбалансированности:

· требований к CMDB — с одной стороны, и

· загруженности персонала и имеющихся ресурсов — с другой.

Количество взаимоотношений растет экспоненциально количеству уровней.

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

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

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

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

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

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

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

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

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

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

Рис. 6 .4. Взаимоотношения между Конфигурационными Единицами типа «parent/child» («родитель/ребенок») ( источник: OGC)

3.2.4. Глубина CMDB

При определении Уровней Конфигурационных Единиц создается иерархия компонентов и элементов.

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

На самом высоком уровне находится сама ИТ- инфраструктура.

Самым низким уровнем является наиболее детальный уровень, на котором необходимо осуществлять контроль.

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

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

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

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

 

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

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

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

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

В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой единицы.

Например, PC с двумя видами жесткого диска будет проходить как Вариант «А» и Вариант «В».

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

Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки.

Кроме того, при выполнении диагностики можно ставить такие вопросы, как: «Какой драйвер нужен для этого типа технических средств?», «К какому сегменту подсоединена сетевая плата?» и «Какая программа использует эту библиотеку?».

 

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

У каждой Конфигурационной Единицы должно быть уникальное имя, которое отличает его от других единиц.

Самым элементарным вариантом является простая система присвоения номеров с возможным делением на диапазоны для каждой области.

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

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

 

Атрибуты

Атрибут	Описание
Номер/метка Конфигурационной Единицы или штриховой код	Уникальный идентификатор Конфигурационной Единицы. Часто это номер, а втоматически присваиваемый баой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер
Номер лицензии или серийный номер	Идентификационный номер поставщика в виде серийного номера или номера лицензии
Номер инвентаризационной системы	Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть раными. Данный атрибут обеспечивает связь с этой средой
Номер модели/ идентификационный номер Каталога	Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, н апример, P AT- NL-C366-4000-T
Наименование модели	Полное наименование модели, в которое часто входит идентификатор версии, н апример, P IIMMX400MHZ
Изготовитель	Изготовитель Конфигурационной Единицы
Категория	Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, д окументация и т. д .)

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

 

Тип	Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль
Гарантийный срок	Срок действия гарантии
Номер версии	Номер версии Конфигурационной Единицы
Расположение	Месторасположение Конфигурационной Единицы например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица
Владелец	Имя владельца или лица, ответственного за Конфигурационную Единицу
Дата начала ответственности	Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу
Источник/поставщик	Источник Конфигурационной Единицы, например, собственная разработка, з акуплена у поставщика «X» и т. д .
Лицензия	Номер лицензии и ссылка на лицензионное соглашение
Дата поставки	Дата поставки Конфигурационной Единицы в организацию
Дата приемки	Дата приемки Конфигурационной Единицы в операционную среду
Статус (текущий)	Текущее состояние Конфигурационной Единицы, например, «в тестировании», « в работе», « выведено из операционной среды»
Статус (запланированный)	Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий
Стоимость	Стоимость приобретения Конфигурационной Единицы
Остаточная стоимость	Текущая стоимость Конфигурационной Единицы с учетом амортизации; амортизационная стоимость
Комментарии	Текстовое поле для комментариев, например, для описания отличий одного варианта от другого

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

 

 

В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инцидентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме. Атрибут Описание Номера запросов на изменения (RFC) Номер (номера) Запросов на изменение (RFC), открытых в настоящий момент или ранее для данной Конфигурационной Единицы Номера изменений Номер (номера) изменений, открытых в настоящий момент или ранее для данной Конфигурационной Единицы Номера проблем Номер (номера) проблем, открытых в настоящий момент или ранее для данной Конфигурационной Единицы Номера инцидентов Номер (номера) инцидентов, связанных с данной Конфигурационной Единицей

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

 

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

 

Атрибут	Описание
Взаимоотношения с родительскими Конфигурационными Единицами	Ключ или номер родительской Конфигурационной Единицы
Взаимоотношения между дочерними Конфигурационными Единицами	Ключ или номер дочерней Конфигурационной Единицы
Другие взаимоотношения	Взаимоотношения между Конфигурационной Единицей и другими единицами, отличными от родительских и дочерних, например, эта Конфигурационная Единица имеет статус «используется» или «подключена к .»

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

 

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

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

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

 

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

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

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

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

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

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

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

Стандартная рабочая станция является типичным примером Базисной Конфигурации.

Полезным применением Базисной Конфигурации является Каталог Продуктов.

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

В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.

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

Для этого нужно принять решения по трем вопросам:

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

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

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

Регистрация

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

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

Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус.

Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет регистрировать.

Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.

 

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

Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными или неавторизованными изменениями или инцидентами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Похищена;

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

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

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

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

- В наличии;

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

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

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

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

3.4. Контроль

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

Примечание.

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

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

 

Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение — при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library — DSL).

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

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

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

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

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

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

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

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

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

 

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

Аудит проводится для проверки, насколько точно отражена текущая ситуация в CMDB.. Аудит возможен в следующих ситуациях:

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

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

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

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

 

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

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

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

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

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

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