- •Учебный вопрос 1. Введение в управление конфигурациями. Основные понятия.
- •Основные понятия
- •Цель процесса
- •Учебный вопрос 2. Связь процесса управления конфигурациями с другими процессами.
- •Учебный вопрос 3. Виды деятельности процесса управления конфигурациями
- •Планирование
- •Идентификация
- •Охват (сфера действия, границы)
- •Взаимоотношения между Конфигурационными Единицами
- •Глубина cmdb
- •Уровень Детализации cmdb
- •Мониторинг статуса
- •Контроль
- •Верификация и аудит
- •Учебный вопрос 4. Критические факторы успеха, показатели эффективности и проблемы процесса
- •Отчеты и Ключевые показатели эффективности
- •Критические факторы успеха
- •Проблемы
- •Учебный вопрос 5. Разработка требований к cmdb и cms
Охват (сфера действия, границы)
При создании Конфигурационной Базы Данных и обновлении модели данных следует определиться, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфигурациями.
Например, следует ли включать в сферу действия данного процесса такие компоненты, как «электронные органайзеры» (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса?
Границы, определенные для процесса Управления Конфигурациями, влияют на:
границы, в которых, например, процесс Управления Проблемами выполняет диагностирование,
на анализ степени воздействия, проводимый процессом Управления Изменениями,
на планирование, выполняемое процессом Управления Доступностью и т. д .
Сферу действия процесса можно разделить на области, каждая со своими требованиями и подходом к проектированию.
Примерами таких областей могут стать:
настольные рабочие места,
системы передачи данных,
файловые сервисы,
сервисы печати и прикладного ПО,
центральная процессинговая система,
базы данных,
телефонные услуги.
Для разработки каждой области может быть инициирован отдельный проект в соответствующей управленческой среде.
Границы Конфигурационной Базы Данных могут включать:
аппаратное и программное обеспечение,
а также документацию, например, Соглашения об Уровне Услуг (SLAs),
процедуры,
руководства,
технические спецификации,
организационные схемы,
персонал и
планы проектов.
Как и другие Конфигурационные Единицы, эти документы физически могут находиться в разных местах, но информация о них находится в базе данных с номерами версий, датами публикаций, именами авторов и т. д .
В этом случае процессы Управления Конфигурациями и Управления Изменениями могут контролировать эти характеристики документов.
На рис.2 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных.
Отслеживание этих взаимоотношений облегчает определение степени воздействия инцидентов на услуги.
Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предоставление сервиса.
Такая информация в дальнейшем может быть использована для улучшения услуг.
У такой «сервисной» Конфигурационной Единицы могут быть взаимоотношения с другими единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг.
В приведенном примере услуга ««В»» полностью выходит за границы базы данных.
Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге ««А»», входя в сферу действия Конфигурационной Базы Данных (например, находятся в рассматриваемой организации), это означает, что услуга «А» не может полноценно поддерживаться.
Я рисунок в 27 слайд не знаю как вставить
Рис.
2. Охват Конфигурационной Базы Данных
(источник: OGC)
После определения областей, включенных в сферу действия процесса, возможно определить этапы жизненного цикла Конфигурационных Единиц, которые будут содержаться в CMDB.
Будут ли единицы со статусом «в разработке» или «заказана» включены в базу данных или же их включат в CMDB только после того, как они будут введены в работу?
Преимущество включения в базу данных продуктов, находящихся на стадии разработки, состоит в том, что в этом случае их спецификации уже нельзя будет менять без получения одобрения, и их передача в рабочую среду будет происходить согласованно.
От этого выбора будет зависеть мониторинг статуса CI в рамках процесса Управления Конфигурациями, к тому же это позволит расширить диапазон контроля жизненного цикла продукта в рамках этого процесса.
