6.4. Виды деятельности

1. Планирование

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

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

Идентификация связана с определением и поддержкой соглашений о присвоении имен и нумерации версий физических компонентов инфраструктуры, взаимоотношений между ними и атрибутов. Ба­зисные Конфигурации Аппаратного Обеспечения, используемого в настоящий момент и в будущем, описываются в форме специальных групп Конфигурационных Единиц (кластеров CI). Общий вопрос, на который должна дать ответ идентификация ИТ-компонентов состоит в сле­дующем:

Какие услуги и связанные с ними компоненты ИТ-инфраструктуры должны находиться под контролем Сервис-менеджмента и какая информация необходима для этого?

При разработке системы идентификации должны быть приняты решения относительно охвата (гра- ниц) процесса и уровня детализации регистрируемой информации. Для каждого параметра (харак­теристики) следует определить владельца или заинтересованное лицо². Чем больше параметров ре­гистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос «Что же регистрировать?» может быть сведен к перечню конкретных вопросов для определения тре­буемой информации, например:

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

• Насколько зрелыми являются наши административные и материально-технические (логистиче­ские) процессы?

• На каких уровнях организация выполняет инсталляцию, замену, разработку и/или распростране­ние компонентов отдельно от основного компонента?

• Какие виды деятельности, выполняемые сторонними организациями, должны измеряться и конт­ролироваться?

• Какие компоненты могут повлиять на услуги в случае сбоя и какая нужна информация для диаг­ностики этих сбоев?

• Для каких компонентов следует регистрировать статус и его предысторию?

• Какие компоненты используются в организации в различных версиях или вариантах?

• Изменения в каких компонентах могут повлиять на возможности и доступность услуг?

• Какие компоненты являются дорогостоящими и их следует защищать от кражи или утери?

• Какова настоящая и будущая информационная потребность у других процессов?

• Для каких компонентов требуется такая информация, как серийный номер, дата покупки и по­ставщик, и какая информация необходима для бухгалтерии?

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

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

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

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

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

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

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

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

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

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

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

Уровень Детализации CMDB

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

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

Взаимоотношения между Конфигурационными Единицами

Информация о взаимоотношениях между Конфигурационными Единицами является очень полез­ной для диагностики ошибок и прогнозирования доступности услуг. Можно определить много раз­ных типов взаимоотношений на логическом и физическом уровнях. • Взаимоотношения на физическом уровне:

• Является частью: это взаимоотношения типа «parent/child» («родитель/ребенок»), например, дисковод является частью PC, а программный модуль — частью программы.

• Подключена к: например, PC подсоединен к сегменту сети.

• Требуется для: например, технические средства требуются для работы приложения.

В зависимости от возможностей используемых инструментальных средств (программною обеспечения) автоматизации Сервис-менеджмента в CMDB включается информация о взаимоотношениях с инци­дентами и другие аналогичные им взаимоотношения в виде атрибутов или в какой-либо другой форме.

Обычно номера соответствующих Конфигурационных Единиц входят в состав регистрационных запи­сей инцидентов, проблем и изменений. Независимо от выбранного подхода должны поддерживаться вза­имоотношения между Конфигурационными Единицами и следующими записями (табл. 2).

Как уже обсуждалось, поддержка информации о взаимоотношениях между Конфигурационными Единицами является важным аспектом процесса Управления Конфигурациями. В зависимости от типа базы данных эти взаимоотношения могут быть представлены в виде атрибутов С1 или в отдель­ной таблице.

В некоторых базах данных есть дополнительная возможность для записи изменений содержимого поля, что обеспечивает ведение журнала истории. Это помогает, например, получать информацию о простоях, ремонте, техническом обслуживании по истории состояния поля «Текущий статус», кроме того, это полезно для отслеживания истории владения.

Кроме рассмотренных выше атрибутов, необходимыми являются перечни атрибутов с технической информацией о каждом типе Конфигурационной. Единицы. У каждого типа свои характеристики. Например, для PC это емкость жесткого диска, изготовитель BIOS и версия BIOS, размер оператив­ной памяти, IP-адрес и т. д. Многие инструменты системного администрирования фиксируют та­кую информацию, в этом случае достаточно установить связь с типом Конфигурационной Единицы, чтобы избежать дублирования информации. Однако следует помнить, что такие системы предостав­ляют текущую информацию, не указывая, является ли она результатом реализации утвержденных изменений или же это результат неавторизованных действий.

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

Базисная Конфигурация

Базисная Конфигурация — это мгновенный снимок группы Конфигурационных Единиц, сделан­ный в определенный момент времени. Базисную Конфигурацию можно использовать в качестве:

• авторизованного/поддерживаемого продукта, который можно включить в ИТ-инфраструктуру (такие Базисные Конфигурации включаются в Каталог Продуктов);

• стандартных Конфигурационных Единиц для учета информации о стоимости;

• базы² при разработке и тестировании новых Конфигураций;

• для выполнения возврата к исходному состоянию, если возникают проблемы с повой Конфигура­цией после проведения изменений;

• стандарта для поставки Конфигураций пользователям, например, «стандартное рабочее место»;

• базы при установке нового программного обеспечения.

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

Другим полезным применением Базисной Конфигурации является Каталог Продуктов. В нем дают­ся Сертифицированные Конфигурации, которые можно использовать в ИТ-инфраструктуре и кото­рые доступны для заказа пользователями. В этом случае новая Конфигурационная Единица являет­ся копией единицы из Каталога с ее номером и меткой.

До того как новая модель или продукт будут добавлены в инфраструктуру, они должны появиться в Каталоге. Для этого нужно принять решения но трем вопросам:

• Бизнес: отвечает ли модель/продукт бизнес-интересам пользователя?

• Финансы: приемлемы ли затраты на поддержку?

• Влияние: приемлем ли уровень воздействия модели/продукта на услугу? Регистрация

Первоначально База данных CMDB наполняется информацией из финансовых систем, записями о существующей ИТ-инфраструктуре, техническими данными от поставщиков. Регистрируется толь­ко информация из известных (проверенных) источников. Организация должна быть готова к под­держанию этой информации в актуальном состоянии.