2. Уровень Детализации cmdb

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Глубина cmdb

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Атрибуты

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

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

1. Naming convention.

2. Definitive Software Library - DSL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регистрация

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