3. Мониторинг статуса

Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус.

Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет регистрировать.

Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.

Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом «неэксплуатирующиеся запасные части», то эти технические средства нельзя перераспределять куда-либо еще без предварительного согласования, например, в рамках развертывания плана восстановления после чрезвычайных ситуаций.

Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными или неавторизованными изменениями или инцидентами.

Может быть использована следующая классификация статусов.

• Новые Конфигурационные Единицыы

• В разработке/заказе;

• Протестирована;

• Принята (по результатам тестирования).

• Существующие Конфигурационные Единицы:

• Получена (принята в операционную среду);

• Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;

• Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и документация (также являющаяся Конфигурационной Единицей) будут предоставлены;

• На обслуживании;

• Не функционирует.

• Архивированные Конфигурационные Единицы^

• Выведена из операционной среды;

• Исключена (deleted);

• Удалена (removed);

• Похищена;

• Продана или истек срок аренды/лизинга;

• В архиве в ожидании безвозмездного дарения, продажи или уничтожения;

• Уничтожена.

• Все Конфигурационные Единицы:

• В наличии;

• Получена по заказу или доступна нова версия; - Тестируется;

• Одобрена для инсталляции;

• Активная Конфигурационная Единица находится в использовании;

• Запасные части.

4. Контроль

Для поддержания Конфигурационной Базы (CMDB) в актуальном состоянии необходимо эффективное Управление Информацией. При любом изменении зарегистрированных характеристик Конфигурационных Единиц или взаимоотношений между ними, вызванном выполнением любого действия, это изменение должно быть отражено в базе данных.

Примечание.

• Изменять характеристики Конфигурационных Единиц можно только путем проведения изменений авторизированных процессом Управления Изменениями;

• Управление Инцидентами может изменять только статус существующих Конфигурационных Единиц.

Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение — при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library — DSL).

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

По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операционной средой и проведения закупок.

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

• добавление Конфигурационной Единицы;

• изменение статуса Конфигурационной Единицы, например, «работает» или «не работает» (полезно для процесса Управления Доступностью);

• изменение владельца Конфигурационной Единицы;

• изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Единицами;

• удаление Конфигурационной Единицы;

• возникновение новых взаимоотношений Конфигурационной Единицы с каким-либо сервисом, другой Конфигурационной Единицей, документацией и т. д.;