При определении структуры Конфигурационной Базы Данных руководствуются следующими соображениями:
? Чем больше уровней в базе данных, тем больше информации надо обрабатывать. Это ведет к увеличению рабочей нагрузки и созданию более
сложной CMDB.
? Чем меньше уровней, тем слабее контроль и хранится меньше информации об инфраструктуре.
Если степень детализации CMDB слишком мала, то становится невозможным эффективный мониторинг изменений, происходящих в компонентах нижнего уровня. В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой единицы. Например, PC с двумя видами жесткого диска будет проходить как Вариант "А" и Вариант "В". Если в дочернем компоненте много изменений, их нумерация становится сложной и трудной для сопровождения. Однако, если имеются уровни, расположенные ниже, то варианты можно поддерживать на соответствующем уровне. Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки. Кроме того, при выполнении диагностики можно ставить такие вопросы, как: "Какой драйвер нужен для этого типа технических средств?", "К какому сегменту подсоединена сетевая плата?" и "Какая программа использует эту библиотеку?".
Соглашения о присвоении имен
У каждой Конфигурационной Единицы должно быть уникальное имя, которое отличает его от других единиц. Самым элементарным вариантом является простая система присвоения номеров с возможным делением на диапазоны для каждой области. Для вновь созданной Конфигурационной Единицы генерируется новый номер. Имена, по возможности, должны иметь смысловое значение для облегчения контактов с пользователями.
Соглашения о присвоении имен также можно использовать для физической маркировки Конфигурационных Единиц, для упрощения их идентификации при инвентаризации (аудите), в процессе сопровождения и регистрации инцидентов. Некоторые из предложенных библиотекой ITIL правил присвоения имен:
? Метки на аппаратных средствах должны быть легко различимыми и легкими в чтении для пользователей, они должны прочно фиксироваться на поверхности. По договоренности со сторонним поставщиком услуг, в договорах о поддержке могут существовать ссылки на эти метки. Пользователи также должны указывать метки при сообщении об инциденте.
? Контролируемые документы, такие как Соглашения об Уровне Услуг (SLA), процедуры и организационные схемы должны маркироваться с указанием номера Конфигурационной Единицы, номера версии и даты выпуска версии.
? Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения (DSL), см. главу "Управление Релизами". Все компоненты программного обеспечения должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии.
Атрибуты
Помимо структуры Уровней Конфигурационных Единиц, взаимоотношений между ними и соглашений о присвоении имен, детальная проработка модели CMDB также включает в себя описание атрибутов. Атрибуты используются для хранения информации, имеющей отношение к Конфигурационной Единице. При формировании CMDB можно использовать приведенные ниже атрибуты.
| АТРИБУТ | ОПИСАНИЕ |
| Номер/метка Конфигурационной Единицы или штриховой код | Уникальный идентификатор Конфигурационной Единицы. Часто это номер, автоматически присваиваемый базой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер |
| Номер лицензии или серийный номер | Идентификационный номер поставщика в виде серийного номера или номера лицензии |
| Номер инвентаризационной системы | Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с этой средой |
| Номер модели/ идентификационный номер Каталога | Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, например, PAT-NL-C366-4000-T |
| Наименование модели | Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MHZ |
| Изготовитель | Изготовитель Конфигурационной Единицы |
| Категория | Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.) |
| Тип | Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль |
| Гарантийный срок | Срок действия гарантии |
| Номер версии | Номер версии Конфигурационной Единицы |
| Расположение | месторасположение Конфигурационной Единицы, например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица |
| Владелец | Имя владельца или лица, ответственного за Конфигурационную Единицу |
| Дата начала ответственности | Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу |
| Источник/поставщик | Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика "X" и т. д. |
| Лицензия | Номер лицензии и ссылка на лицензионное соглашение |
| Дата поставки | Дата поставки Конфигурационной Единицы в организацию |
| Дата приемки | Дата приемки Конфигурационной Единицы в операционную среду |
| Статус (текущий) | Текущее состояние Конфигурационной Единицы, например, "в тестировании", "в работе", "выведено из операционной среды" |
| Статус (запланированный) | Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий |
| Стоимость | Стоимость приобретения Конфигурационной Единицы |
| Остаточная | Текущая стоимость Конфигурационной Единицы с учетом амортизации амортизационная стоимость |
| Комментарии | Текстовое поле для комментариев, например, для описания отличий одного варианта от другого |