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

Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет ре­гистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Похищена;

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

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

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

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

• В наличии;

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

• Тестируется;

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

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

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

6.4.4. Контроль

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

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

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

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

Если но согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инф­раструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигураци­онной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями. Формализованные записи об изменениях являются основным источни­ком информации об изменениях в инфраструктуре, которая используется для обновления Конфигу­рационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требова- пня к уроопю зрелости процессов в организации, особенно к Управлению Изменениями, операцион­ной средой и проведения закупок.

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

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

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

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

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

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

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

• возобновление или изменение лицензии;

• обновление детальной информации о Конфигурационной Единице после аудит а.