Jan van Bon - ИТ СЕРВИС–МЕНЕДЖМЕНТ. Вводный курс на основе ITIL

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

? Верификация: верификация Конфигурационной Базы Данных путем аудита ИТ-инфраструкту­ры на наличие в ней зарегистрированных Конфигурационных Единиц и правильности регистра­ционных записей.

? Отчетность: предоставление информации в другие процессы и подготовка отчетов об использова­нии Конфигурационных Единиц, тенденциях и т. д.

Ниже дается подробное описание этих действий.

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

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

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

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

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

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

При разработке системы идентификации должны быть приняты решения относительно охвата (гра­ниц) [87] Scope. процесса и уровня детализации регистрируемой информации. Для каждого параметра (харак­теристики) следует определить владельца или заинтересованное лицо [88] Stakeholder. . Чем больше параметров ре­гистрируется, тем больше усилий потребуется на обновление этой информации. Общий вопрос "Что же регистрировать?" может быть сведен к перечню конкретных вопросов для определения тре­буемой информации, например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Охват (сфера действия, границы) [89] Scope.

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

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

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

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

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