Практически в каждой компании, внедрившей ITSM, есть CMDB. Формально. На бумаге — есть. В реальности — часто это «склад данных», куда один раз загрузили список серверов и забыли. Данные устарели, связи не поддерживаются, а при инциденте никто не идёт в CMDB — идут к инженеру, который «всё знает». Знакомо? Я видел это не раз. И каждый раз CMDB умирала по одним и тем же причинам. Почему CMDB умирает Ручной ввод без автоматизации. Кто-то вручную заносит серверы. Через месяц появляется новый — его забывают. Через два — меняется владелец. Через три CMDB не отражает реальность, и ей перестают доверять. Нет владельцев конфигурационных единиц (CI). Записи есть, но непонятно, кто отвечает за их актуальность. Без владельцев данные «стареют» молча. CMDB не связана с изменениями и инцидентами. Если при изменении не обновляется CMDB, она теряет смысл. Если при инциденте в неё не смотрят — она не нужна. CMDB должна быть встроена в процесс, а не жить отдельно. Нет метрик качества. Пока не измеряем полноту и актуальность — не управляем. Как сделать CMDB живой 1. Автоматизируйте сбор данных. Используйте Discovery, UCMDB, агенты, интеграции с мониторингом и виртуализацией. В одном из проектов мы интегрировали CMDB на SimpleOne с Discovery и UCMDB — это дало автоматическое обнаружение серверов и сетевого оборудования. Ручной ввод сократился, полнота выросла. Но автоматизация не отменяет контроль: нужны правила классификации и подтверждения. 2. Назначьте владельцев CI. У каждой критичной CI должен быть владелец — человек или подразделение. Он отвечает за актуальность атрибутов, статус жизненного цикла и связи. Без этого CMDB — «ничей» документ. 3. Свяжите CMDB с изменениями и инцидентами. В CMDB должны быть связи: «сервис → приложение → сервер → СУБД». Тогда при инциденте сразу видно, какие сервисы затронуты. При изменении — какие CI зависят от компонента. В проекте ITAM/ITSM на SimpleOne мы выстраивали эти связи. Это ускорило анализ влияния изменений и сократило время диагностики инцидентов. Практика: при каждом изменении — обязательный шаг «обновить CMDB». Встройте это в Change Management. 4. Определите метрики качества. Без метрик CMDB — вера, а не управление. Измеряйте: полноту (доля CI с заполненными атрибутами), актуальность (доля обновлённых за период), долю автоматического сбора, связанность (доля CI со связями), использование (сколько раз CMDB применялась при инцидентах и изменениях). Выведите на дашборд и показывайте руководству. 5. Встройте CMDB в процессы. CMDB должна быть частью Incident Management (анализ влияния, поиск корневой причины), Change Management (оценка влияния, план отката), Problem Management (анализ повторяющихся инцидентов), Asset Management (жизненный цикл, лицензии). Когда CMDB встроена в процессы, она становится нужной. А когда нужна — её поддерживают. Мини-кейс В одном проекте CMDB формально была, но ей не пользовались. Мы сделали три шага: интегрировали с Discovery и UCMDB, назначили владельцев для критичных CI, встроили обязательное обновление CMDB в Change Management. Через несколько месяцев CMDB стала использоваться при анализе влияния изменений и инцидентов. Время диагностики сократилось, количество «сюрпризов» при изменениях уменьшилось. Чек-лист: с чего начать Оцените текущее состояние: полнота, актуальность, доля ручного ввода. Определите критичные сервисы и CI. Назначьте владельцев CI. Настройте автоматический сбор (Discovery, UCMDB, интеграции). Встройте обновление CMDB в Change Management. Определите метрики и выведите на дашборд. Проведите обучение участников процессов. Регулярно пересматривайте CMDB — это живой организм. Главное CMDB — не просто база данных, а инструмент управления ИТ-сервисами. Если она актуальна, связана с процессами и используется в изменениях и инцидентах — она работает. Если нет — это мёртвый склад, который никто не открывает. Начните с малого: автоматизация, владельцы CI, связь с изменениями. И CMDB оживёт.