Управление Сервисными Активами и Конфигурациями. CMDB и ITIL.

Управление Сервисными Активами и Конфигурациями (Service Asset and Configuration Management), как данный процесс правильно называется в ITIL® v3, – один из самых трудных для понимания и внедрения процессов ITIL®, во всяком случае, такая оценка следует из опросов наших слушателей.

Попробуем понять эти трудности, разобрав некоторые риски, которые сопутствуют практикам данного процесса.

Для начала (как всегда) разберемся с основными понятиями рассматриваемого процесса. В процессе Управления Сервисными Активами и Конфигурациями появились новые понятия, которых не было в ITIL® второй версии. Кратко углубимся в основные понятия, используя определения из Глоссария.

Система управления конфигурациями (Configuration Management System, CMS) - набор инструментов и баз данных, которые используются для управления данными о Конфигурациях Поставщиком ИТ услуг.

CMS также содержит информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. Может содержать данные о сотрудниках, поставщиках, местоположениях, бизнес-единицах, заказчиках и пользователях CMS включает в себя инструменты для сбора, хранения, управления, обновления и представления информации о всех CI и их взаимоотношениях.

База данных управления конфигурациями (Configuration Management Database, CMDB) - база данных, используемая для хранения записей о конфигурациях на всем протяжении их жизненного цикла. Система управления конфигурациями (Configuration Management System, CMS) управляет одной и более CMDB и каждая CMDB содержит атрибуты CI и их связи другими CI.

Запись о CI (Сonfiguration Record) - запись, содержащая детальную информацию о CI. Каждая запись документирует жизненный цикл единственной CI. Запись о конфигурации хранятся в CMDB.

Конфигурационная единица (configuration item, CI) - актив, компонент сервиса или другой элемент, который находится или будет находиться под контролем процесса управления конфигурациями. Могут быть:

• CI жизненного цикла сервиса
• Сервисные CI
• Организационные CI
• Внутренние CI
• Внешние CI
• Интерфейсные CI

Проиллюстрируем данные положения небольшой схемой, взятой из книги Service Transition:

Из схемы и определений мы видим, что:

• CMS – более широкое понятие, чем CMDB и может содержать в себе объекты, не являющиеся CI.

• Речь уже идет не только о базе данных, но о целой системе взаимосвязанных между собой баз данных, инструментария, сайтов и интерфейсов, имеющих разные уровни хранения, представления и отображения.

• Перечень того, что может быть CI, значительно расширен и в него могут входить как физические, так и логичекие CI, как IT, так и бизнес объекты.

Конечно же, далеко не все компании имеют такую грандиозную систему управления конфигурациями даже в мечтах, но видение ITIL® впечатляет. Итак, какие же трудности и риски ожидают людей, решивших воплотить в жизнь данный процесс, какие ошибки они чаще всего совершают? Разберем некоторые из них:

Неверно или нечетко определены цели и задачи процесса

С самого начала, еще на этапе планирования, нужно четко расставить акценты, поскольку сам процесс, структура CMS и организация взаимодействия с другими процессами или подразделениями драматически зависят от того, какие задачи должны быть решены. Возможные варианты:

Но представим себе, что мы разобрались с требуемыми задачами. Тогда нас ожидает первый подводный камень:

Подход: «собираем все данные, которые возможно», что ведет к перегрузке процесса, а также к невозможности его поддерживать

Типичная ошибка в начале строительства данного процесса: все зачарованы возможностью собрать в CMDB максимально возможное количество информации. Как следствие, ужасно напрягаются все силы, проводится тотальная инвентаризация, в базу забивается все вплоть до последней дохлой мыши и – вот оно, счастье! Но нет, счастья, как всегда, нет, потому что мало все собрать один раз, надо все это богатство поддерживать в актуальном состоянии, отображая в CMDB все изменения, реально происходящие с многочисленными CI. Поскольку об этом заранее никто не подумал и сил на поддержку не запасал, наступает быстрая деактуализация части (а если не повезет, то и большей части) данных в CMDB и как следствие – ужасное разочарование и неверие в могущество ITIL®. А вот и второй подводный камень, тесно связанный с первым:

Потеря актуальности конфигурационной информации со временем, что вызывает ошибки, а также трудности и избыточные затраты при исправлении

Управление конфигурациями – особенный процесс, метафорически напоминающий воспитание маленького ребенка: мало его родить, надо о нем постоянно заботиться и это уже навсегда. Мало не подавиться большим куском на старте, надо еще поддерживать все актуальным в ходе процесса. На практике встречаются ситуации, когда по тем или иным причинам происходит потеря актуальности данных в CMDB, поэтому важно определить факт наступления такого состояния и продумать рациональные меры по его исправлению. Самой действенной мерой выявления является аудит, то есть сверка данных CMDB и реальных CI. К сожалению, проведение аудита является дорогим удовольствием, требует привлечения дополнительных ресурсов и, как минимум, правильного определения охвата аудита. На практике чаще всего проводится выборочный аудит.

Поддержка данных в CMDB в актуальном состоянии столь же важна, как и информативность самой базы. Требования к данным в CMDB:

И здесь уместно рассмотреть следующее положение, которое также требует аккуратного и продуманного подхода. Это:

Установление обоснованного уровня точности, т.е. корреляции между моделью и реальной конфигурацией

Решить данную задачу нелегко, потому что здесь нужно верно решить уравнение с несколькими неизвестными:

Поскольку с первого раза решить все правильно будет непросто, задача решается в несколько итераций. При последующих итерациях могут решаться следующие задачи:

При всех итерациях необходимо определять ресурсы, необходимые для поддержки данных CMDB в актуальном состоянии. Наличие (отсутствие) таких ресурсов является критически важным.

Выводы

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