Стандартная рабочая станция является типичным примером Базисной Конфигурации. Ограничивая количество разных стандартных рабочих станций, можно облегчить оценку результатов и определение ресурсов, необходимых для реализации новых функций и улучшения их тестирования. Базисные Конфигурации также могут помочь в проведении политики комбинирования и планирования изменений, например, для пакетных релизов. Они способствуют сокращению затрат на Управление и облегчают планирование проектов.
Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем даются Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и которые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.
До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:
? Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?
? Финансы: приемлемы ли затраты на поддержку?
? Влияние: приемлем ли уровень воздействия модели/продукта на услугу?
Регистрация
Первоначально База данных CMDB наполняется информацией из финансовых систем, записями о существующей ИТ-инфраструктуре, техническими данными от поставщиков. Регистрируется только информация из известных (проверенных) источников. Организация должна быть готова к поддержанию этой информации в актуальном состоянии.
6.4.3. Мониторинг статуса
Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет регистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.
Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы
Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом "неэксплуатирующиеся запасные части", то эти технические средства нельзя перераспределять куда-либо еще без предварительного согласования, например, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.
Может быть использована следующая классификация:
? Новые Конфигурационные Единицы:
? В разработке/заказе;
? Протестирована;
? Принята (по результатам тестирования).
? Существующие Конфигурационные Единицы:
? Получена (принята в операционную среду);
? Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;
? Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и документация (также являющаяся Конфигурационной Единицей) будут предоставлены;
? На обслуживании;
? Не функционирует.
? Архивированные Конфигурационные Единицы:
? Выведена из операционной среды;
? Исключена (deleted);
? Удалена (removed);
? Похищена;
? Продана или истек срок аренды/лизинга;
? В архиве в ожидании безвозмездного дарения,
продажи или уничтожения;
? Уничтожена.
? Все Конфигурационные Единицы:
? В наличии;
? Получена по заказу или доступна новая версия;
? Тестируется;
? Одобрена для инсталляции;
? Активная Конфигурационная Единица находится в использовании;
? Запасные части.
6.4.4. Контроль
Для поддержания Конфигурационной Базы (CMDB) в актуальном состоянии необходимо эффективное Управление Информацией. При любом изменении зарегистрированных характеристик Конфигурационных Единиц или взаимоотношений между ними, вызванном выполнением любого действия, это изменение должно быть отражено в базе данных.
Примечание. Изменять характеристики Конфигурационных Единиц можно только путем проведения изменений авторизованных процессом Управления Изменениями; Управление Инцидентами может изменять только статус существующих Конфигурационных Единиц.
Управление Конфигурациями контролирует все ИТ-компоненты, существующие в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library DSL).
Одна из задач контроля гарантировать регистрацию только авторизованных и включенных в Каталог Продуктов Конфигурационных Единиц. Для этого должно быть организовано активное взаимодействие процесса Управления Конфигурациями с поставщиками и процессами Управления Инцидентами, Проблемами и Изменениями.
Если по согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инфраструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигурационной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями. Формализованные записи об изменениях являются основным источником информации об изменениях в инфраструктуре, которая используется для обновления Конфигурационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операционной средой и проведения закупок.