Выбранный уровень УЭ зависит от требований бизнеса и услуг. Попробуйте заранее определить самый подробный уровень детализации УЭ, который может потребоваться, даже если вы сейчас не собираетесь наполнять CMDB на этом уровне. Полезно потратить время на эти действия и смотреть как можно дальше вперед. Это поможет избежать дорогостоящих реорганизаций CMDB в будущем. Тем не менее, заранее определить верный уровень УЭ не всегда легко. Если возможно, найдите средство поддержки Управления конфигурациями, которое не обладает чрезмерными ограничениями, связанными с разделением УЭ на элементы более низкого уровня. Если это невозможно, выберите средство, которое допускает запись атрибутов УЭ, таких как уровень сборки. Примеры разбивки инфраструктуры и конфигурации показаны на Рисунках 7.3. 7.4 и 7.5.
Рисунок 7.3 - Пример структуры разбивки конфигурации
Рисунок 7.5 - Пример структуры разбивки конфигурации (для инфраструктуры, показанной на Рисунке 7.4).
Несмотря на то, что «дочерний» УЭ может быть во владении «родительского» УЭ, он может «использоваться» любым количеством других УЭ. Если используются стандартные конфигурации (наборы конфигураций) ПО (например, все терминалы глобальной сети имеют доступ к идентичным наборам конфигураций), тогда эти наборы могут быть определены, и для них установлены связи «доступа». Это может значительно уменьшить необходимое количество связей по сравнению с ситуацией, когда используются связи для каждого индивидуального УЭ типа ПО.
В некоторых случаях сети могут считаться частью ИТ-инфраструктуры (или использоваться ею), но не могут быть переданы под контроль Управления конфигурациями. Например, внешняя глобальная сеть WAN, которая принадлежит другой организации, может быть представлена единым обобщенным УЭ со всеми подключениями к этой сети с типом взаимосвязей «используется» или «подключен». Рисунок 7.6 показывает, как эти взаимосвязи могут быть определены.
Использование УЭ правильного уровня - вопрос достижения равновесия между доступностью информации и правильно выбранным уровнем контроля, а также.
ресурсами и усилиями, необходимыми для поддержки этого уровня. Например, если Изменение должно быть сделано в модуле 1-2-2 на Рисунке 7.3. то лучше записать Изменение на уровне модуля, а не на уровне программы. Однако наполнение и сопровождение CMDB на уровне модулей повлечет за собой более значительные затраты.
С другой стороны, реальные Изменения должны быть сделаны на уровне, записанном в CMDB. Следовательно, если решено, что ПО будет записываться в CMDB на уровне программ, Изменения должны проводиться на этом уровне. Например, если один модуль должен быть изменен, то будет необходимо провести повторную компиляцию всей программы, чтобы сделать Изменение на уровне программы.
Если информация на детальном уровне УЭ не представляет ценности (например, если клавиатура обычно не заменяется отдельно или организация рассматривает ее как расходные материалы), такую информацию сохранять не следует. Информация об УЭ представляет ценность, только если она способствует управлению Изменениями, контролю Инцидентов и Проблем или контролю активов, которые могут переноситься, копироваться или меняться.
Организация должна планировать обзор уровней УЭ на регулярной основе - для подтверждения (или опровержения) того, что вплоть до самого высокого уровня детализации информация все еще ценна и полезна, и что обработка Изменений и Проблем, а также управление активами не является эффективным по той причине, что CMDB не обеспечивает достаточного уровня детализации.
Рисунок 7.6 - Пример внешней сети Типы УЭ и их жизненный цикл.
Компоненты должны классифицироваться по типам УЭ, поскольку это поможет определить и документировать используемые элементы, а также их статус и.
местоположение. Часто встречающиеся типы УЭ: программные продукты, бизнес-системы, системное ПО, серверы, мейнфрейм-системы, рабочие станции, ноутбуки, маршрутизаторы и хабы.
Для каждого типа УЭ также должно быть определено состояние в жизненном цикле. Например, Релиз приложения может быть зарегистрирован, утвержден, инсталлирован или снят с эксплуатации. Пример жизненного цикла пакетного Релиза приложения показан на Рисунке 7.7. Необходимо определить роль, которая может изменять состояние в жизненном цикле, например Управление конфигурациями, Управление релизами.
Рисунок 7.7 - Пример жизненного цикла Релиза приложения в ИТ-инфраструктуре.
При Управлении конфигурациями необходимо планировать, какие атрибуты должны быть записаны. Поскольку для разных типов УЭ требуемые атрибуты могут различаться, необходимо рассмотреть только текущие типы УЭ и типы УЭ, которые планируется использовать. Заметьте, что это решение может диктоваться некоторыми средствами поддержки. Приложение 7В дает предлагаемый список атрибутов, которые следует записывать. Полезно иметь атрибут для идентификации УЭ с высокой степенью риска или критические УЭ.
Взаимосвязи между УЭ.
Взаимосвязи между УЭ должны сохраняться для того, чтобы предоставлять информацию о зависимостях. Например:.
■ УЭ составляет часть другого УЭ (например, модуль ПО является частью программы, сервер - частью инфраструктуры офиса) - эта связь называется «родительской/дочерней»;.
■ УЭ подсоединен к другому УЭ (например, компьютер подсоединен к LAN-сети);.
■ УЭ использует другой УЭ (например, программа использует модуль из другой программы, бизнес-услуга использует сервер инфраструктуры).
Может быть множество других типов взаимосвязей, но все эти взаимосвязи содержатся в CMDB - это и составляет одно из основных отличий между тем, что записано в CMDB, и тем, что хранится в списке активов.
Требуется механизм, позволяющий связывать RFC, записи об Инцидентах (IR, или Incident Record), записи о Проблемах, записи об Известных ошибках и записи о Релизах с Учетными элементами ИТ-инфраструктуры, на которые они ссылаются. Все эти взаимосвязи должны быть включены в CMDB. RFC и все записи об Изменениях и Релизах должны идентифицировать затронутые УЭ. Эти учетные записи должны также определять и характер Изменений. Для получения подробной информации смотрите главу 9. «Управление Релизами».
Физические и электронные библиотеки ПО должны быть уникально идентифицированы с помощью следующей информации:.
■ содержание, местоположение и носитель для каждой библиотеки;.
■ условия постановки элемента на хранение, включая минимальный статус совместимости с содержанием библиотеки;.
■ как защитить библиотеки от нанесения преднамеренного или случайного вреда, а также эффективные процедуры восстановления;.
■ условия и контроль доступа для групп или типов пользователей для регистрации, чтения, обновления, копирования, переноса или удаления УЭ.
Идентификация конфигурационных базисов.
Конфигурационный базис может быть создан по любой или по всем нижеуказанным причинам:.
■ как твердая основа для последующей работы (например, точка в жизненном цикле УЭ, с которой можно двигаться дальше, как, например, «принятое» приложение);.
■ как запись того, какие УЭ затронул RFC и какие УЭ были реально изменены;.
■ как отправная точка, к которой можно выполнить откат, если что-то пойдет не так.
Каждый конфигурационный базис должен быть определен для конкретной цели. Входящая в него информация и Учетные элементы должны контролироваться в данном базисе, включая все коммерческие фирменные и патентованные продукты, вместе с сопутствующей документацией. Конфигурационные базисы должны включать соответствующую конфигурационную документацию, в том числе:.
■ записи о Релизах (текущие, прошлые и планируемые);.
■ другие записи об Изменениях (текущие, прошлые и планируемые);.
■ состояние системы и ее документацию, когда Изменение утверждено и когда оно проведено;.
■ состояние системы и ее документацию, когда проведен пакетный Релиз;.
■ аппаратное и программное обеспечение - стандартные спецификации.
Конфигурационные базисы должны быть учреждены формализованным соглашением в определенный момент времени и использоваться как отправные точки для формализованного контроля над конфигурацией. Конфигурационные базисы вместе с утвержденными изменениями к этим базисам определяют утвержденную на данный момент конфигурацию. Конкретные примеры базисов могут быть определены следующим образом:.
■ Необходимы определенные «стандартные» УЭ при закупках большого количества элементов одного типа (например, персональные компьютеры) на протяжении длительного времени. Если некоторые.
серверы должны включать дополнительные платы, они могут соответствовать «расширенному базису». Если все последующие компьютеры должны обладать этими платами, то тогда создается новый базис.
■ Релиз приложения и соответствующая документация:.
к которой можно вернуться (должна физически существовать или должна обладать способностью возвращения в предыдущее состояние);.
состояние ПО для распространения в удаленных офисах;.
состояние ПО, с которым необходимо проводить последующую работу;.
состояние, в котором должна находиться система перед тем, как пройдет модернизация для принятия нового аппаратного обеспечения;.
или ПО.
В любое время могут существовать несколько конфигурационных базисов, соотносящихся с различными этапами жизненного цикла «базового элемента». Например, базис для Релиза ПО, которое находится в эксплуатации, которое когда-то было в эксплуатации, а теперь находится в архиве, которое будет инсталлировано (подвержено Изменению под контролем Управления конфигурациями) и которое находится в тестировании. Более того, если, например, новое ПО вводится поэтапно по регионам, в эксплуатации в одно и то же время могут находиться несколько версий базиса. Следовательно, лучше всего ссылаться на номер каждой уникальной версии, чем на статус «в эксплуатации», «следующий», «предьвдущий».