ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL
Шрифт:
? Копии программного обеспечения должны храниться в Библиотеке эталонного программного обеспечения [93] (DSL), см. главу "Управление Релизами". Все компоненты программного обеспечения должны иметь номер CI, а инсталлированное ПО еще и номер версии и номер копии.
Атрибуты
Помимо структуры Уровней Конфигурационных Единиц, взаимоотношений между ними и соглашений о присвоении имен, детальная проработка модели CMDB также включает в себя описание атрибутов. Атрибуты используются для хранения информации, имеющей отношение к Конфигурационной Единице. При формировании CMDB можно использовать приведенные ниже атрибуты.
93
Definitive Software Library – DSL.
АТРИБУТ | ОПИСАНИЕ |
Номер/метка
| Уникальный идентификатор Конфигурационной Единицы. Часто это номер, автоматически присваиваемый базой данных. Хотя не все Конфигурационные Единицы имеют физические метки, у всех есть уникальный номер |
Номер лицензии или серийный номер | Идентификационный номер поставщика в виде серийного номера или номера лицензии |
Номер инвентаризационной системы | Инструментальные средства инвентаризации (аудита) часто используют свои собственные идентификаторы, которые в разных областях инфраструктуры могут быть разными. Данный атрибут обеспечивает связь с этой средой |
Номер модели/ идентификационный номер Каталога | Уникальный идентификатор, используемый в Каталоге Поставщика. У каждой версии модели свой номер, например, PAT-NL-C366-4000-T |
Наименование модели | Полное наименование модели, в которое часто входит идентификатор версии, например, PIIMMX400MHZ |
Изготовитель | Изготовитель Конфигурационной Единицы |
Категория | Классификация Конфигурационной Единицы (например, технические средства, программное обеспечение, документация и т. д.) |
Тип | Описание типа Конфигурационной Единицы, предоставляет детальную информацию о категории, например, Аппаратная Конфигурация, пакет программ или программный модуль |
Гарантийный срок | Срок действия гарантии |
Номер версии | Номер версии Конфигурационной Единицы |
Расположение | месторасположение Конфигурационной Единицы, например, библиотека или носитель, на котором находится программное обеспечение, или территория/комната, где находится Конфигурационная Единица |
Владелец | Имя владельца или лица, ответственного за Конфигурационную Единицу |
Дата начала ответственности | Дата, когда вышеуказанное лицо стало ответственным за Конфигурационную Единицу |
Источник/поставщик | Источник Конфигурационной Единицы, например, собственная разработка, закуплена у поставщика "X" и т. д. |
Лицензия | Номер лицензии и ссылка на лицензионное соглашение |
Дата поставки | Дата поставки Конфигурационной Единицы в организацию |
Дата приемки | Дата приемки Конфигурационной Единицы в операционную среду |
Статус (текущий) | Текущее состояние Конфигурационной Единицы, например, "в тестировании", "в работе", "выведено из операционной среды" |
Статус (запланированный) | Следующий планируемый статус Конфигурационной Единицы с указанием даты и требуемых действий |
Стоимость | Стоимость приобретения Конфигурационной Единицы |
Остаточная | Текущая стоимость Конфигурационной Единицы с учетом амортизации амортизационная стоимость |
Комментарии | Текстовое поле для комментариев, например, для описания отличий одного варианта от другого |
Таблица 6.1. Примеры атрибутов
В зависимости от возможностей используемых инструментальных средств (программного обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инцидентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.
АТРИБУТ | ОПИСАНИЕ |
Номера запросов на изменения (RFC) | Номер (номера) Запросов на изменение (RFC), открытых в настоящий момент или ранее для данной Конфигурационной Единицы |
Номера изменений | Номер (номера) изменений, открытых в настоящий момент или ранее для данной Конфигурационной Единицы |
Номера проблем | Номер (номера)
|
Номера инцидентов | Номер (номера) инцидентов, связанных с данной Конфигурационной Единицей |
Таблица 6.2. Примеры других записей, связанных с Конфигурационными Единицами
Обычно номера соответствующих Конфигурационных Единиц входят в состав регистрационных записей инцидентов, проблем и изменений. Независимо от выбранного подхода должны поддерживаться взаимоотношения между Конфигурационными Единицами и следующими записями (табл. 2).
АТРИБУТ | ОПИСАНИЕ |
Взаимоотношения с родительскими Конфигурационными Единицами | Ключ или номер родительской Конфигурационной Единицы |
Взаимоотношения между дочерними Конфигурационными Единицами | Ключ или номер дочерней Конфигурационной Единицы |
Другие взаимоотношения | Взаимоотношения между Конфигурационной Единицей и другими единицами, отличными от родительских и дочерних, например, эта Конфигурационная Единица имеет статус "используется" или "подключена к..." |
Таблица 6.3. Атрибуты взаимоотношений
Как уже обсуждалось, поддержка информации о взаимоотношениях между Конфигурационными Единицами является важным аспектом процесса Управления Конфигурациями. В зависимости от типа базы данных эти взаимоотношения могут быть представлены в виде атрибутов CI или в отдельной таблице.
В некоторых базах данных есть дополнительная возможность для записи изменений содержимого поля, что обеспечивает ведение журнала истории. Это помогает, например, получать информацию о простоях, ремонте, техническом обслуживании по истории состояния поля "Текущий статус", кроме того, это полезно для отслеживания истории владения.
Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оперативной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют такую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предоставляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.
Для облегчения ввода и обновления атрибутов можно использовать открывающиеся меню [94] . Можно устанавливать связи и с другими надежными источниками для получения информации о месторасположении Конфигурационной Единицы, пользователях, подразделениях, номерах телефонов, владельцах и параметрах бюджета. Вариантов много, но всегда следует учитывать нагрузку, связанную с поддержкой актуальности этих файлов.
Базисная Конфигурация
Базисная Конфигурация – это мгновенный снимок группы Конфигурационных Единиц, сделанный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:
94
Т. е. меню со списком выбора вариантов.
– Прим. ред.
? авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов);
? стандартных Конфигурационных Единиц для учета информации о стоимости;
? базы [95] при разработке и тестировании новых Конфигураций;
? для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигурацией после проведения изменений;
? стандарта для поставки Конфигураций пользователям, например, "стандартное рабочее место";
95
Starting point.
? базы при установке нового программного обеспечения.
Стандартная рабочая станция является типичным примером Базисной Конфигурации. Ограничивая количество разных стандартных рабочих станций, можно облегчить оценку результатов и определение ресурсов, необходимых для реализации новых функций и улучшения их тестирования. Базисные Конфигурации также могут помочь в проведении политики комбинирования и планирования изменений, например, для пакетных релизов. Они способствуют сокращению затрат на Управление и облегчают планирование проектов.
Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем даются Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и которые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.
До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:
? Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?