Базисная Конфигурация
Базисная Конфигурация – это мгновенный снимок группы Конфигурационных Единиц, сделанный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:
• авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов);
• стандартных Конфигурационных Единиц для учета информации о стоимости;
• базы [95] Starting point.
при разработке и тестировании новых Конфигураций;
• для выполнения возврата к исходному состоянию, если возникают проблемы с новой Конфигурацией после проведения изменений;
• стандарта для поставки Конфигураций пользователям, например, «стандартное рабочее место»;
• базы при установке нового программного обеспечения.
Стандартная рабочая станция является типичным примером Базисной Конфигурации. Ограничивая количество разных стандартных рабочих станций, можно облегчить оценку результатов и определение ресурсов, необходимых для реализации новых функций и улучшения их тестирования. Базисные Конфигурации также могут помочь в проведении политики комбинирования и планирования изменений, например, для пакетных релизов. Они способствуют сокращению затрат на Управление и облегчают планирование проектов.
Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем даются Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и которые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица является копией единицы из Каталога с ее номером и меткой.
До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения по трем вопросам:
• Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?
• Финансы: приемлемы ли затраты на поддержку?
• Влияние: приемлем ли уровень воздействия модели/продукта на услугу?
Регистрация
Первоначально База данных CMDB наполняется информацией из финансовых систем, записями о существующей ИТ-инфраструктуре, техническими данными от поставщиков. Регистрируется только информация из известных (проверенных) источников. Организация должна быть готова к поддержанию этой информации в актуальном состоянии.
6.4.3. Мониторинг статуса
Цикл жизни компонента можно разделить на несколько этапов, каждому из которых присваивается свой статус. Этапы зависят от тех характеристик ИТ-инфраструктуры, которые организация хочет регистрировать. Регистрация даты каждого изменения статуса дает важную информацию о жизненном цикле продукта: о времени заказа, времени инсталляции, о сопровождении и поддержке продукта.

Рис 6.6. Пример мониторинга статуса Конфигурационной Единицы
Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом «неэксплуатирующиеся запасные части», то эти технические средства нельзя перераспределять куда-либо еще без предварительного согласования, например, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.
Может быть использована следующая классификация:
• Новые Конфигурационные Единицы:
- В разработке/заказе;
- Протестирована;
- Принята (по результатам тестирования).
• Существующие Конфигурационные Единицы:
- Получена (принята в операционную среду);
- Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;
- Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и документация (также являющаяся Конфигурационной Единицей) будут предоставлены;
- На обслуживании;
- Не функционирует.
• Архивированные Конфигурационные Единицы:
- Выведена из операционной среды;
- Исключена (deleted);
- Удалена (removed);
- Похищена;
- Продана или истек срок аренды/лизинга;
- В архиве в ожидании безвозмездного дарения, продажи или уничтожения;
- Уничтожена.
• Все Конфигурационные Единицы:
Читать дальше