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