Статус компонента также помогает определить, какие действия можно выполнять с ним. Например, если составлен отчет об элементах со статусом "неэксплуатирующиеся запасные части", то эти технические средства нельзя перераспределять куда-либо еще без предварительного согласования, например, в рамках развертывания плана восстановления после чрезвычайных ситуаций. Изменение статуса Конфигурационной Единицы может быть вызвано авторизованными изменениями или неавторизованными изменениями или инцидентами.
Может быть использована следующая классификация:
- Новые Конфигурационные Единицы:
- В разработке/заказе;
- Протестирована;
- Принята (по результатам тестирования).
- Существующие Конфигурационные Единицы:
- Получена (принята в операционную среду);
- Открыт Запрос на Изменение (RFC) Конфигурационной Единицы, запрошена новая версия;
- Изменение утверждено и включено в план изменений, новая Конфигурационная Единица и документация (также являющаяся Конфигурационной Единицей) будут предоставлены;
- На обслуживании;
- Не функционирует.
- Архивированные Конфигурационные Единицы:
- Выведена из операционной среды;
- Исключена (deleted);
- Удалена (removed);
- Похищена;
- Продана или истек срок аренды/лизинга;
- В архиве в ожидании безвозмездного дарения, продажи или уничтожения;
- Уничтожена.
- Все Конфигурационные Единицы:
- В наличии;
- Получена по заказу или доступна новая версия;
- Тестируется;
- Одобрена для инсталляции;
- Активная Конфигурационная Единица находится в использовании;
- Запасные части.
Для поддержания Конфигурационной Базы (CMDB) в актуальном состоянии необходимо эффективное Управление Информацией. При любом изменении зарегистрированных характеристик Конфигурационных Единиц или взаимоотношений между ними, вызванном выполнением любого действия, это изменение должно быть отражено в базе данных.
Примечание. Изменять характеристики Конфигурационных Единиц можно только путем проведения изменений авторизованных процессом Управления Изменениями; Управление Инцидентами может изменять только статус существующих Конфигурационных Единиц.
Управление Конфигурациями контролирует все ИТ-компоненты, существующие в организации, и отвечает за их регистрацию в системе. Аппаратные средства можно регистрировать при их заказе или получении, а программное обеспечение – при его включении в Библиотеку эталонного программного обеспечения (Definitive Software Library – DSL).
Одна из задач контроля – гарантировать регистрацию только авторизованных и включенных в Каталог Продуктов Конфигурационных Единиц. Для этого должно быть организовано активное взаимодействие процесса Управления Конфигурациями с поставщиками и процессами Управления Инцидентами, Проблемами и Изменениями.
Если по согласованию с Управлением Изменениями произведены некоторые изменения в ИТ-инфраструктуре, процесс Управления Конфигурациями обязан отразить эти изменения в Конфигурационной Базе Данных. Хотя публикации ITIL не дают четких указаний по этому вопросу, на практике ответственность за регистрацию Запросов на Изменение (RFC) происходит под контролем процесса Управления Изменениями[96]. Формализованные записи об изменениях являются основным источником информации об изменениях в инфраструктуре, которая используется для обновления Конфигурационной Базы Данных. По существу процесс Управления Конфигурациями предъявляет требования к уровню зрелости процессов в организации, особенно к Управлению Изменениями, операционной средой и проведения закупок.
Для того, чтобы авторизованная Конфигурационная База Данных отражала реальную ситуацию, необходимо проводить мониторинг следующих действий:
- добавление Конфигурационной Единицы;
- изменение статуса Конфигурационной Единицы, например, "работает" или "не работает" (полезно для процесса Управления Доступностью);
- изменение владельца Конфигурационной Единицы;
- изменение взаимоотношений Конфигурационной Единицы с другими Конфигурационными Единицами;
- удаление Конфигурационной Единицы;
- возникновение новых взаимоотношений Конфигурационной Единицы с каким-либо сервисом, другой Конфигурационной Единицей, документацией и т. д.;
- возобновление или изменение лицензии;
- обновление детальной информации о Конфигурационной Единице после аудита.
Аудит проводится для проверки, насколько точно отражена текущая ситуация в CMDB. Например, инструментальные средства аудита могут автоматически выполнять анализ рабочих станций и формировать отчеты о текущей ситуации и статусе ИТ-инфраструктуры. Эта информация будет использоваться для проверки и обновления Конфигурационной Базы Данных. Аудит возможен в следующих ситуациях:
- после внедрения новой Конфигурационной Базы Данных;
- к примеру, спустя полгода с момента внедрения;
- перед серьезными изменениями и после них;
- после чрезвычайных обстоятельств;
- в любое другое удобное время.
При проведении аудита рассматриваются следующие вопросы:
- Регистрируются ли в CMDB данные всех Запросов на Изменения на всех этапах их реализации, и контролирует ли процесс Управления Конфигурациями эту регистрацию-
- Находится ли Конфигурационная База Данных в актуальном состоянии, если нет, то почему- Какое воздействие это оказывает на процесс Управления Изменениями (анализ текущего воздействия запланированных изменений)-
- Производится ли присвоение имен новым Конфигурационным Единицам в соответствии с соглашением о присвоении имен-
- Правильно ли используются варианты-
- Правильно ли регистрируются Базисные Конфигурации и становятся ли они сразу же доступными к использованию-
- Соответствует ли содержимое Библиотеки эталонного программного обеспечения (DSL) и Склада эталонного аппаратного обеспечения (DHS) информации в Конфигурационной Базе Данных- Если нет, то почему-
Аудиторские проверки также можно проводить, выбирая объекты случайным образом или проводить там, где Руководитель Процесса Управления Конфигурациями считает, что информация может быть некорректной. Если существует связь с автоматическими инструментальными средствами аудита, тогда можно делать аудит соответствующих областей или формировать по ним дельта-отчеты практически ежедневно.
Если обнаруживаются расхождения, то инструментальные средства аудита не должны автоматически обновлять Конфигурационную Базу Данных. Все расхождения свидетельствуют о том, что изменения были произведены в обход процесса Управления Изменениями, и теперь эти прецеденты должны быть изучены.
В отчет по процессу Управления Конфигурациями возможно включение следующей информации:
- информация о качестве процесса;
- расхождения между регистрационными записями и реальной ситуацией, обнаруженные во время аудита (дельта);
- количество случаев, когда используется неавторизованная Конфигурация;
- количество случаев, когда зарегистрированная Конфигурация не находилась на своем месте;
- отклонения на Уровне Атрибутов, обнаруженные аудиторскими проверками;
- длительность обработки Запросов на Регистрацию информации;
- перечень Конфигурационных Единиц, в отношении которых количество зарегистрированных инцидентов или изменений превышало заданную величину;
- статистическая информация о структуре и составе ИТ-инфраструктуры;
- данные о росте и другая информация о развитии ИТ-инфраструктуры;
- сводные данные, отчеты и предложения по улучшению, например, рекомендации по изменению охвата (границ) процесса и Уровня Конфигурационных Единиц, отслеживаемых процессом Управления Конфигурациями, связанные с изменениями в бизнесе, технических средствах, рыночных ценах и т. д.;
- расходы на персонал при внедрении процесса.
Условием успешной работы по Управлению Конфигурациями является получение необходимой информации для поддержания базы данных в актуальном состоянии. Это означает, что обязательно нужно поддерживать взаимосвязи с процессом Управлением Изменениями, а для регистрируемых характеристик всегда должен быть найден тот, кому они требуются.
Внедрение процесса важно правильно разбить на этапы. Попытки ввести требование регистрации компонентов инфраструктуры без соответствующей подготовки обычно заканчиваются неудачей, т. к. дисциплина, необходимая для Управления Конфигурациями, не может появиться мгновенно. Записи, которые велись до ввода процесса, должны быть выведены из обращения во избежание дублирования. При запуске процесса в работу важно продемонстрировать несколько явных преимуществ, которые дает Управление Конфигурациями (быстрые удачи[97]). Кроме того, важно, чтобы обязанности по регистрации были закреплены за теми сотрудниками, у кого есть не только необходимые навыки, но и должное отношение к работе.
Работа процессов происходит в горизонтальной плоскости, относительно вертикальной иерархической структуры организации. Это возможно только при четком распределении ответственностей и полномочий по их реализации. Для повышения гибкости может быть использован ролевой подход. В небольших организациях или в силу экономических причин возможно комбинирование ролей, например, Руководителя Процесса Управления Изменениями и Управления Конфигурациями. В задачи Руководителя Процесса Управления Конфигурациями может входить следующее: