Идентификация

• Какие требования вытекают из условий, закрепленных в Соглашениях об Уровне Услуг?

• Какая информация необходима для выставления счетов заказчикам?

• Насколько реальны наши стремления, не нужна ли корректировка?

Ответы на эти вопросы дают представление об объеме работ, которые необходимо выполнить. Сле­дует принять решение об охвате (ширине, границах) CMDB и уровне ее детализации (глубине). По­нятие детализации включает в себя: количество уровней в базе данных, взаимоотношения, подлежа­щие мониторингу, соглашения о присвоении имен и атрибуты. Все они будут рассмотрены ниже.

Охват (сфера действия, границы)¹

При создании Конфигурационной Базы Данных и обновлении модели данных следует определить­ся, какая часть ИТ-инфраструктуры будет находиться под контролем процесса Управления Конфи­гурациями. Например, следует ли включать в сферу действия данного процесса такие компоненты, как «электронные органайзеры» (PDA), сетевые копировальные устройства, факсы, клавиатуры и ИТ-персонал, или же они должны находиться за пределами действия процесса? Границы, опреде­ленные для процесса Управления Конфигурациями, влияют на границы, в которых, например, про­цесс Управления Проблемами выполняет диагностирование, на анализ степени воздействия, прово­димый процессом Управления Изменениями, планирование, выполняемое процессом Управления Доступностью и т. д.

Кроме того, работая над границами процесса можно произвести анализ вклада ИТ-услуг в конечную деятельность заказчика или степень воздействия на нее, а также рассмотреть соглашения с пользователями об уровне поддержке и услугах.

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

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

На рис. 6.3 показаны взаимоотношения между услугами и компонентами Конфигурационной Базы Данных. Отслеживание этих взаимоотношений облегчает определение степени воздействия инцидентов на услуги. Это также позволяет создавать отчет обо всех компонентах, вовлеченных в предоставление сервиса. Такая информация в дальнейшем может быть использована для улучшения луг. У такой «сервисной» Конфигурационной Единицы могут быть взаимоотношения с друг: единицами, такие как договоренности с заказчиком в форме Соглашения об Уровне Услуг. В при денном примере услуга «В» полностью выходит за границы базы данных. Из рисунка видно, что не все Конфигурационные Единицы, участвующие в услуге «А», входят в сферу действия Конфигурационной Базы Данных (например, находятся в рассматриваемой организации), это означает, что луга «А» не может полноценно поддерживаться.

¹ Scope.

6. УПРАВЛЕНИЕ КОНФИГУРАЦИЯМИ

Рис. 6.3. Охват Конфигурационной Базы Данных

(ИСТОЧНИКOGC)

После определения областей, включенных в сферу действия процесса, возможно определить этапы жизненного цикла Конфигурационных Единиц, которые будут содержаться в CMDB. Будут ли еди­ницы со статусом «в разработке» или «заказана» включены в базу данных или же их включат в CMDB только после того, как они будут введены в работу? Преимущество включения в базу данных продуктов, находящихся на стадии разработки, состоит в том, что в этом случае их спецификации уже нельзя будет менять без получения одобрения, и их передача в рабочую среду будет происхо­дить согласованно. От этого выбора будет зависеть мониторинг статуса CI в рамках процесса Управ­ления Конфигурациями, к тому же это позволит расширить диапазон контроля жизненного цикла продукта в рамках этого процесса.