Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

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

Если степень детализации CMDB слишком мала, то становится невозможным эффективный мони­торинг изменений, происходящих в компонентах нижнего уровня. В этом случае любое изменение в компонентах родительской Конфигурационной Единицы приведет к созданию варианта этой едини­цы [91] Варианты используются, если имеются несколько существующих одновременно форм Конфигурационной Единицы, т. е. если существуют па­раллельные отношения. Версии появляются, например, если одновременно используется и новая, и старая версии Конфигурационной Единицы, т. е. когда существуют последовательные отношения. Использование этих двух концептуальных понятий помогает при планировании изме­нений. Если в последующем каждый из вариантов будет разрабатываться отдельно, то для каждого из них нужно вводить отдельную систему нумерации версий, что нежелательно, т. к. это делает ИТ-инфраструктуру более сложной и ведет к увеличению работ по сопровождению. В большинстве случаев рекомендуется продолжать разработку исходного экземпляра всех вариантов, а там, где возможно, использовать новую версию для создания необходимых вариантов. – Прим. автора. . Например, PC с двумя видами жесткого диска будет проходить как Вариант "А" и Вариант "В". Если в дочернем компоненте много изменений, их нумерация становится сложной и трудной для со­провождения. Однако, если имеются уровни, расположенные ниже, то варианты можно поддержи­вать на соответствующем уровне. Для дочерних компонентов также можно регистрировать больше атрибутов и связывать с ними известные ошибки. Кроме того, при выполнении диагностики можно ставить такие вопросы, как: "Какой драйвер нужен для этого типа технических средств?", "К какому сегменту подсоединена сетевая плата?" и "Какая программа использует эту библиотеку?".

Соглашения о присвоении имен [92] Naming Convention.

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

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

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

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

? Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения [93] Definitive Software Library – DSL. (DSL), см. главу "Управление Релизами". Все компоненты программного обеспече­ния должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии.

Атрибуты

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

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