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

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

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

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

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

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

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

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

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

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

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

Атрибуты

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

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

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

В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инци­дентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.

АТРИБУТ ОПИСАНИЕ Номера запросов на изменения (RFC) Номер (номера) Запросов на изменение (RFC), открытых в настоящий момент или ранее для данной Конфигурационной Единицы Номера изменений Номер (номера) изменений, открытых в настоящий момент или ранее для данной Конфигурационной Единицы Номера проблем Номер (номера) проблем, открытых в настоящий момент или ранее для данной Конфигурационной Единицы Номера инцидентов Номер (номера) инцидентов, связанных с данной Конфигурационной Единицей

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

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

АТРИБУТ ОПИСАНИЕ Взаимоотношения с родительскими Конфигурационными Единицами Ключ или номер родительской Конфигурационной Единицы Взаимоотношения между дочерними Конфигурационными Единицами Ключ или номер дочерней Конфигурационной Единицы Другие взаимоотношения Взаимоотношения между Конфигурационной Единицей и другими единицами, отличными от родительских и дочерних, например, эта Конфигурационная Единица имеет статус "используется" или "подключена к..."

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

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