Глубина CMDB

При определении Уровней Конфигурационных Единиц создается иерархия компонентов и элементов. Выбираются родительские Конфигурационные Единицы и определяется количество уровней, необхо­димых для их детализации. На самом высоком уровне находится сама ИТ-инфраструктура. Самым низким уровнем является наиболее детальный уровень, на котором необходимо осуществлять конт­роль. Включение Конфигурационных Единиц в Конфигурационную Базу Данных будет целесообраз­ным только в том случае, если информация об этих CI будет полезна для других процессов ITIL. Определяя уровни и глубину Конфигурационной Базы Данных, следует помнить, что изменение в любой Конфигурационной Единице, зарегистрированной в CMDB, должно пройти через формаль­ный процесс Управления Изменениями, прежде чем оно будет произведено. Поэтому регистрируя такой компонент как компьютерная мышь в Конфигурационной Базе Данных, создается ситуация, при которой любой Запрос на новую мышь уже не будет проходить как Запрос на Обслуживание^[90], а должен будет проводиться через процесс Управления Изменениями в форме Запроса на Изменение (RFC). Это показательный пример для организаций, которые чрезмерно увлекаются детализацией.

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-08-26