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

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

Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

? Похищена;

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

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

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

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

? В наличии;

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

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

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

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

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

6.4.4. Контроль

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

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

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

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

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

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

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

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

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

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

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

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

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

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