назад Оглавление вперед


[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [ 25 ] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]


25

6. УЙРАКЛЕНИЕ Ш1йфИ6-УИА1-ША<И

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Scope. Stakeholder.



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

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

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

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

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

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

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

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

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

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

Scope



6. YiimiAmM- к€тФшгтмтш

Охват

ИТ-инфраструктура

Услуга А

Услуга В

Приложение А

а №4

/Модуль А

О №5

Модуль В

Автоматическая телефонная станция

Система 21

NIC 12

С1№8

Модем 5

Линия 1,

Линия 2,

Линия 3, аналоговая

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

(ИСТОЧНИК: OGC)

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

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

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

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

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

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

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

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

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

[Старт] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [ 25 ] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72]