Ошибки, которые лишают CMDB ценности

Вы задумывались о том, почему так много проектов по созданию CMDB (базы данных управления конфигурациями) заканчиваются разочарованием? Часто на такую базу возлагают большие надежды, и они небезосновательны – при грамотном управлении база способна существенно помочь в решении широкого круга задач.

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

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

Давайте перед разбором ошибок зафиксируем термины:

Конфигурационная единица (КЕ) — любой компонент, которым необходимо управлять для предоставления ИТ-услуги.

CMDB — база данных, где хранится информацию о КЕ, а именно значения их атрибутов и связей на протяжении всего жизненного цикла.

Что же может пойти не так?

1. Отсутствие понимания задач до начала внедрения (или доработки) CMDB

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

Например, если CMDB создаётся без согласования с командой управления инцидентами, в неё могут не попасть ключевые атрибуты серверов, влияющие на время восстановления, — такие как контакты ответственных, связи с бизнес-услугами или история изменений. В итоге при сбое инженеры тратят часы на поиск информации вручную, хотя, казалось бы, CMDB существует.

2. Попытка сразу внести в CMDB всё

Попытка сразу внести в CMDB, особенно на начальном этапе ее создания, всю информацию обо всех ИТ-услугах обычно оказывается непосильной задачей. Это неизбежно приводит к непредсказуемо фрагментарной, незавершённой базе, лишённой практической ценности. И даже если удается, приложив значительные усилия или с помощью внешних консультантов, собрать максимальный объем данных, сложность базы и количество информации становится препятствием к возможности найти в ней необходимую информацию.

Представьте, что вы пытаетесь сразу внести в CMDB все сетевые устройства, серверы, ПО, виртуальные машины и мобильные устройства, включая исторические данные за несколько лет. Команда тонет в ручном вводе, процессы не отлажены, и через три месяца база содержит лишь 40% запланированного, причём данные разрознены и плохо связаны. Ценность такого инструмента близка к нулю.

3. Отсутствие плана по внедрению и наполнению

Работа без плана не дает возможность распределить ответственность по наполнению базы информацией (в результате чего какая-то часть конфигурационных единиц может быть забыта), уложиться в срок с реализацией, принять обоснованные решения о последовательности наполнения CMDB информацией. В итоге второстепенные задачи могут быть решены вперёд более важных.

Вот пример такой ситуации (которая, увы, не редка): поняв, что CMDB может принести много пользы, в компании стартует проект по наполнению CMDB. Команда управления услугами вносит данные о бизнес-приложениях, инженеры инфраструктуры — о серверах, а сетевая команда параллельно пытается описать топологию. Поскольку нет общего плана и приоритетов, каждая группа действует самостоятельно. Через месяц выясняется, что критичные для инцидент-менеджмента связи между приложениями и серверами не установлены, зато детально описаны неиспользуемые тестовые среды. В результате CMDB всё ещё не готова поддержать ни решение инцидентов, ни оценку изменений, ни управление мощностями, ни какие-либо другие виды активностей, хотя значительные усилия уже затрачены.

4. Отсутствие процессов сверки данных и обновления

Можно заполнить CMDB большим количеством данных, но как только в составе или атрибутах конфигурационных единиц что-то поменяется (а изменения в услугах происходят постоянно), без регулярного обновления и верификации база начнет терять актуальность. Решения, принятые на основе неактуальной информации, будут неверными, доверие к CMDB будет подорвано, и вся работа по её разработке и внедрению станет сделанной зря.

Может случиться ситуация, что после миграции виртуальных машин на новый кластер в CMDB остались старые записи о физических серверах. Команда планирования мощностей, опираясь на эти данные, заказывает дополнительное оборудование, которое на самом деле не требуется. Результат — необоснованные затраты и подорванное доверие к данным CMDB.

5. Отсутствие интеграции с другими ИТ-процессами

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

Возможно, CMDB у вас обновляется, но процесс управления изменениями не требует сверки с ней перед утверждением. В результате изменение вносится без учёта зависимостей, что приводит к коллапсу смежной услуги. Или служба поддержки не обучена работе с CMDB и продолжает звонить системным администраторам для уточнения конфигурации, вместо того чтобы обратиться к централизованному источнику истины.

Какие можно сделать выводы

Успешное использование CMDB требует не только понимания этих ошибок, но и грамотной организации самого процесса её проектирования, внедрения и эксплуатации. Если у вас возник вопрос «Как это сделать правильно?» – приходите на курс VAP: Управление изменениями и конфигурациями в ИТ. Он даст вам необходимые знания и инструменты.

А какие ошибки в работе с CMDB замечали вы? Поделитесь опытом в комментариях.