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


[Старт] [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]


27

•Существующие Конфигурационные Единицы:

-Получена (принята в операщюнную среду);

-Открыт Запрос на Изменение (RFC) Ко1гфигурационной Единицы, запрошена новая версия;

-Изменение зтверждено и включено в план изменений, новая Конфигурационная Ед1П1ица и документация (также являюп(аяся Кош})игурациониой Единицей) будут предоставлены;

-На обслуживании;

-Не функционирует.

•Архивированные Ко1гфигурационные Единицы:

-Выведена из операционной средьг,

-Исключена (deleted);

-Удалена (removed);

-Похип1ена;

-Продана или истек срок аренды/лизинга;

-В архиве в ожидании безвозмездного дарения, продажи или уничтожения;

-Уничтожена.

•Все ЕСонфигурационные Единицы:

-В наличии;

-Получена по заказу или доступна новая ве1)Сия;

-Тестируется;

-Одобрена для инсталляции;

-Активная Конфигурационная Единица находится в использовании;

-Запасные части.

6.4.4. Контроль

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

Пргтечание. Изменять характеристики Конфигурационных Единиц можно только путем проведения из.менений авторизированных процессом Управления Изменениями; Управление Инцидентами может изменять только статус существующих Конфигурационных Единиц.

Управление Конфигурациями контролирует все ИТ-компоненты, суптествуюииш в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение - при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library - DSL).

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

Если но согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инфраструктуре, процесс Управлештя Конфигурациями обязан отразить эти изменения в Кон()игураци-онной Базе Данных. Хотя публикации ПТЕ не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями. Формализованные записи об изменешшх являются основным источником инс1юрмации об измспстгиях в инфраструктуре, которая используется для обновления Конфигурационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требова-

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



пня к уровню зрелости ироцессов в организацгн!, особенно к Управлению Изменениями, операгпюп-нон средой и ироведения закупок.

Для того, чтобы авторизованная Коифи1ура1и1онная База Данных отражала реальную ситуацию, необходимо проводит]! мониторинг следуюнщх действий:

•добавление Коифигу])ацио1И101"1 Е/шницы;

•изменение статуса Конфигурационной Е/итинцы, например, «работает» или «не работает» (полезно для процесса Управления Доступностью);

•изменение владельца Конфигурационной Ед1П1ицы;

•изменение взаимоотнонгений Конфигурационной Единицы с другими Конфигурационными Еди-тщами;

•удаление Кодфигурациоппой Единицы;

•возникновение новых взаимоотношений Конфигурационной Единит»! с каким-либо сервисом, другой Копфигурацио1И1ой Единицей, документацией и т. д.;

•возобновление или изменение лицензии;

•обновление детальной 1И!формации о Конфигурациопной Единице после аудита. 6.4.5. Верификация и аудит

Аудит проводится д.ая и[ювсрки, насколько точ1ю отражена текущая ситуация в CMDB. Например, инструментальные средства ауд1гга могуг автоматически выполнять анализ рабочих станций и формировать отчет))! о текущей ситуации и статусе ИТ-И1к1)раструктуры. Эта информагпвд будет использоваться для проверки и обновления Конфигурационной Базы Данных. Ау/пгг возможен в следуюпп1х ситуациях:

•после внедрения новой Конфигуращюпной Базы Данных;

•к примеру, спустя полгода с момента внедрения;

•перед серьез1гг.1ми изменениями и после них;

•после чрезвычайных обстоятельств;

•в любое другое удобное время.

Нри проведении аудита рассматриваются следующие вопросы:

•Регистрируются ли в CMDB данные всех Запросов иа Изменения на всех :танах их реализации, и контролирует ли процесс Управлеш1я Конфигурациями эту регистрацию?

•Находится ли Конфигуращюиная База Данных в актуальном состоянии, если нет, то почему? Какое 1юзлейс1вие это оказывает на процесс Управления Изменениями (анализ текущего воздействия .занланироваипых изменений)?

•Ироизводичся ли присвоение имен новым Кон(1)игураниои11ьь\1 Единшигм в соответствии с соглашением о ирисвоении имен?

•Правилык) ли используются варианты?

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

•Соответствует ли содержимое Библиотеки эталонного програмлгного обеспечешгя (DSL) и Склада эталонного аппаратного обеспечения (DI1S) информации в Копфигуращюниой Базе Данных? Если иет, то почему?

Аудиторские проверки также можно проводить, выбирая об7)ектг.1 случайным образом или проводить там, где Руководитель Процесса Уиравления Конфигурациями считает, что информаття молсет бьггь ])екорректной. ¥хлп существует связь с автоматическими инструментальными средства.ми аудита, тогда можно делать аудит соответствуюнщх областей или (1)ормировать по ним делыа-отчеты практически ежедневно.

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



6.5. Контроль процесса

6.5.1.Отчеты и Ключевые показатели эффективности

В отчет по процессу Упраилеппя Кон()пгурацпями иозможпо включение слелуюн1С11 пиформатши:

•информация о качес!ве процесса;

•расхождения между регистрационпг.1.\н1 записями и реальной сптуацпеГ!, обнаруженные во время аудита (дельта);

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

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

•отклоне1П1я на Уровне Атрибутов, обнаруженгиле ауднторскилш проверками;

•длительность обработки Запросов на Регистрацию информашш;

•перечень Конфшуращюнных Единиц, в отногиении которых количество зарегнстрированых инцидентов или изменений превышало заданную величину;

•статистическая информация о структуре и составе ИТ-нп())раструктуры;

•данные о росте и другая информация о развитии ИТ-ии())рас-труктуры;

•сводные дашшге, отчеты и предложения по улу>ниению, например, рекомендащ-ц] ira изменению охвата (фаниц) процесса и Уровня Кон(})игурационных Единиц, отслеживаемых «[юцессом Управления Конфигурациями, связанные с изменениями в бизнесе, техгнтческих с]юдс1вах, рыночных ценах и т. д.;

•расходы иа персонал нрн внедрении процесса.

6.5.2.Критические факторы успеха

Условием успешной работы по Унравле1И1Ю Конфи17ра1П1ямп является полученне необходимой ии-форма)П1И для поддержания базы данных в актуальном состоянии. Это означает, что обязательно нужно поддерживать взаимосвязи с процессом Управлением Изменениями, а для [регистрируемых характеристик всегда должен быть найден тот, кому они требуются..

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

6.5.3.функции и роли

Работа процессов происходит в j-оризонтальной плоскости, отпоснтельно вертикальной иерархической структуры организации. Это возможно только при четком расп))еделении ответственпостей и полномочи!! по ИХ рсализацин. Для повышения гибкости может быть использован ролевой подход. В пеболыпих орга1П1за1П1Ях нлн в силу экономических причин возмож1ю комбинирование ролей, па-пример. Руководителя Процесса Управления Изменениями и Управления Конфигурациями. В задачи Руководителя Процесса Управления Конфигурациями может входить следующее:

•пpeдroжeтнш по изменению сферы действия и Уровня Детализации Процесса Управления Конфигурациями;

•информированность всей оргапизатцш о cyiuecTnyionicM Процессе Управления Когфигура1пп1ми;

•обеспечение процесса персоналом и его обучение;

•разработка системы пдеитификации н соглашений о присвоении имен;

•разработка интерфейсов с другими процессами;

•оценка су1цествуюпп1х систем и впед1)епие новых систем автоматизации процесса;

•ruiaiHiponannc и внедрение системы наполнетшя ин([юрмацни в Конфигурационной Базе Данных;

Quick wms.

[Старт] [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]