CMDB как код: факты Ansible, нормализация и контроль изменений

Почему CMDB перестает быть полезной

«Мертвый реестр» - это CMDB, которая формально существует, но ей не доверяют. Записи устарели, часть полей заполнена «для галочки», а решения все равно принимают по чатам, Excel и памяти отдельных людей.

Чаще всего все начинается с ручного заполнения. Пока серверов десятки, кто-то еще успевает обновлять карточки после изменений. Но когда появляются регулярные патчи, замены дисков, миграции ВМ и срочные правки «на ночь», реестр начинает отставать. Люди заняты инцидентами и проектами, а обновление CMDB не выглядит срочным, пока не случится проверка или авария.

Ситуацию усугубляет отсутствие владельца данных. Админы считают, что это задача эксплуатации, эксплуатация - что это задача ИБ или архитекторов, а владельцы сервисов видят CMDB только в отчетах.

Симптомы обычно заметны сразу:

• у одного сервера разные имена в мониторинге, инвентаризации и CMDB
• поля «ОС», «ответственный», «среда» заполнены не везде или разным языком
• даты изменений не сходятся с реальными окнами работ
• новые серверы появляются в сети, но не появляются в CMDB
• никто не может сказать, какая запись «правильная»

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

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

CMDB как код простыми словами

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

Обычная «табличка в Excel» ломается в двух местах. Во-первых, непонятно, кто и когда вносил правку, и можно ли ей верить. Во-вторых, обновление постоянно откладывают: нет времени, нет владельца, нет понятных правил. В итоге CMDB превращается в архив догадок.

В подходе «как код» источником фактов становятся сами машины (например, через Ansible facts). А вы добавляете слой правил: какие поля важны, как они называются, как сверять значения и что считать ошибкой. Затем изменения фиксируются так же строго, как изменения в коде: видно, что поменялось, где и когда.

Успех здесь измеряется не количеством заполненных полей, а тремя вещами:

• точность: данные совпадают с реальностью на серверах
• полнота: покрыты нужные группы систем, а не «пара критичных»
• скорость обновления: изменения попадают в CMDB быстро, а не раз в квартал

Чтобы начать без перегруза, выберите минимальный набор: уникальный идентификатор хоста, ОС и версия, роли или назначение, основные ресурсы (CPU/RAM/диски), сетевые идентификаторы (IP/MAC), владелец или команда поддержки. Этого достаточно, чтобы ловить дрейф конфигураций и не получить «мертвый реестр» уже в первый месяц.

Источник правды и границы ответственности

Чтобы CMDB как код не превратилась в спорный справочник, заранее решите, где именно находится «правда» для каждого типа данных. Одна и та же запись о сервере может иметь разные официальные источники: железо и серийники лучше брать из закупок или от производителя, сетевые параметры - из IPAM, учетные данные и политики - из систем безопасности, а «живые» признаки ОС и пакетов - из Ansible facts.

Полезно разделить два слоя: факты и намерения. Факты отвечают на вопрос «что сейчас»: версия ядра, список дисков, включенные службы. Намерения отвечают «как должно быть»: целевой образ ОС, разрешенные пакеты, обязательные агенты. Когда эти слои смешаны, CMDB начинает врать. Админ обновил пакет, а «должно быть» не поменяли, и непонятно, это дрейф или новое правило.

Границы ответственности проще закрепить через владельцев данных. Обычно работает такая схема:

• инфраструктура: хосты, виртуализация, сеть, базовые параметры ОС
• безопасность: шифрование, учетные политики, агенты EDR, критичность
• приложения: сервис, среда (dev/test/prod), зависимости, окна работ

Дальше договоритесь о минимальном обязательном наборе полей. Например: уникальный идентификатор, владелец, среда, роль, критичность, источник данных и отметка времени последнего подтверждения. Все остальное делайте необязательным. Иначе люди начнут заполнять «для галочки», и вы снова получите «мертвый реестр».

Модель данных: что именно вы храните в CMDB

Чтобы CMDB не превратилась в «мертвый реестр», сначала договоритесь не про инструмент, а про модель данных: какие объекты вы описываете, какие поля считаете обязательными, и что для вас является «одной и той же машиной». В подходе CMDB как код это особенно важно: автосбор фактов быстро заполнит «все подряд», а пользы не будет.

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

• сервер (физический или виртуальный) как главный объект учета
• ОС и базовые параметры (дистрибутив, версия, ядро)
• сеть (интерфейсы, IP, VLAN/подсеть, DNS-имя)
• диски и файловые системы (размер, тип, точки монтирования)
• сервисы и приложения (что запущено и кто владелец)

Дальше определите идентификацию. Hostname удобен, но ненадежен: его меняют, клонируют, ошибаются в регистре. Лучше иметь «жесткий» ключ (серийный номер, UUID, asset tag) и один-два «мягких» (hostname, основной IP). В CMDB полезно хранить все варианты, но выбрать один главный.

Смысл данным дают связи: сервер привязан к площадке и стойке, к роли (например, БД, веб, терминальный), к владельцу (команда или подразделение) и к критичности. Тогда при изменении, например, сетевого интерфейса понятно, какой сервис и какой владелец затронут.

Зафиксируйте правила представления. Они кажутся мелочью, но именно они спасают от «каши» в отчетах:

• размеры только в GiB (или только в GB), без смешивания
• CPU: отдельно «ядра» и отдельно «потоки», не одно поле
• имена: единый формат hostname и окружения (prod/test/dev)
• справочники: роли, площадки, владельцы только из списка
• пустые значения: лучше null, чем текст «unknown»

Пошаговый поток: сбор фактов Ansible до записи в CMDB

Чтобы CMDB не превращалась в «мертвый реестр», ей нужен повторяемый поток данных: от инвентаря до фиксации изменений. Важно, чтобы поток работал одинаково для продакшена и теста, а также для разных площадок и филиалов.

1) От инвентаря к наблюдаемой реальности

Начните с четкого перечня: какие хосты вы считаете «в учете», и как они группируются. Обычно достаточно двух-трех разрезов: среда (prod/dev), площадка (DC1/DC2), роль (web/db/backup). Если сервер не попал в инвентарь Ansible, он не попадет и в CMDB. Это нормально, если правило известно всем.

Дальше включите сбор фактов и добавьте то, что стандартные facts не покрывают: наличие агента мониторинга, версию критичного пакета, параметры RAID, метки виртуализации. Делайте это отдельными простыми проверками, чтобы их было легче поддерживать.

2) Преобразование в запись CMDB

После выполнения плейбука результаты нужно выгрузить в единый формат (обычно JSON), чтобы их можно было одинаково обработать независимо от источника. Затем прогоните валидацию: обязательные поля (hostname, серийный номер или UUID, OS), типы (число, строка, список), допустимые диапазоны (например, размер диска не может быть отрицательным). Ошибки валидации не должны тихо «проходить», иначе в CMDB попадет мусор.

Затем зафиксируйте результат как артефакт и сформируйте отчет по изменениям. Рабочий минимум выглядит так:

• выбрать целевые группы хостов и отметить среду и площадку
• собрать стандартные facts и добавить 2-5 кастомных проверок
• привести вывод к одному JSON-шаблону
• проверить схему и обязательные поля, отклонить неверные записи
• записать версию данных и показать diff: что добавилось, изменилось, исчезло

Если в филиале заменили сервер на новый, CMDB должна показать смену идентификатора и характеристик как контролируемое изменение, а не как «потерянный» хост.

Нормализация: как превратить факты в понятные записи

Ansible facts полезны, но в чистом виде это «шумная» телеметрия: разные имена, разные форматы версий, много временных полей. Если писать это в CMDB как код без обработки, быстро появится витрина, где невозможно сравнить серверы между собой и отследить изменения.

Нормализация начинается с простого правила: на каждую сущность в CMDB должен быть один понятный «канонический» вид. Все варианты из источников приводятся к нему.

Единые имена и словари

Чаще всего ломается сравнение из-за разного именования одного и того же. Интерфейс может прийти как ens192, eth0 или как MAC без имени, а диск - как /dev/sda, naa.* или серийник из RAID. Нужен слой сопоставления: вы выбираете, что считается «основным именем», и как находить то же устройство при следующем сборе.

То же с ОС: договоритесь о едином словаре. Не храните «Ubuntu 20», «20.04» и «Ubuntu20.04» как разные значения. Приводите к одному формату, например: os_family=ubuntu, os_version=20.04, kernel=5.15.0-....

Чтобы не плодить дубли, заранее определите порядок идентификаторов. Хорошая практика: первичный ключ - инвентарный ID или серийник, затем UUID, затем FQDN, затем IP (как самый ненадежный). Если два сервера «спорят» за один идентификатор, это не «особенность учета», а инцидент качества данных.

Теги и «сырье» отдельно

Нормализованные записи полезны, когда к ним добавлены одинаковые метки: окружение (prod/test), критичность, владелец, уровень поддержки, площадка. Эти поля лучше заполнять из инвентаря и процессов, а не угадывать по hostname.

Храните «сырые» Ansible facts отдельно от нормализованных данных. Сырые факты нужны для аудита и разборов, но в отчетах и проверках дрейфа используйте нормализованный слой. Тогда изменения будут сравнимыми, а CMDB не превратится в свалку полей, которые никто не понимает.

Фиксация изменений и контроль дрейфа конфигураций

Сбор Ansible facts сам по себе не спасает от дрейфа. Польза появляется, когда изменения фиксируются, объясняются и регулярно проверяются. В подходе «CMDB как код» это достигается разделением: Git хранит правила и преобразования, а CMDB хранит состояние и историю.

Версии, дифы и шум

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

Чтобы дифы были полезными, заранее договоритесь, какие поля считаются изменением, а какие - шумом. К шуму чаще всего относятся временные метрики, счетчики, аптайм, порядок интерфейсов и поля, которые «прыгают» от перезагрузки.

Review нужен не для каждого чиха, а для изменений, которые влияют на риск. Например:

• версия ОС и ядра, пакеты и патчи
• открытые порты и правила фаервола
• состав дисков и RAID, параметры файловых систем
• членство в домене, локальные админы, sudoers
• критичные параметры сервисов (БД, веб, резервное копирование)

История и регулярные сверки

Хорошая запись об изменении содержит «кто, когда и почему». «Кто» - исполнитель (CI/CD, инженер, подрядчик), «почему» - тикет или короткая причина, «что» - диф нормализованных полей.

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

Как не получить «мертвый реестр»: рабочие правила

«Мертвый реестр» появляется, когда CMDB заполняют вручную, редко обновляют и пытаются сделать идеальной сразу. В CMDB как код цель другая: хранить минимум, который помогает принимать решения, и обновлять его автоматически.

Начните с малого, но полезного

Не описывайте весь серверный мир с первого дня. Выберите 20% полей, которые дают 80% пользы: идентификатор хоста, окружение (prod/test), роль, владелец, ОС и версия, CPU/RAM, критичные сервисы. Остальное добавляйте только когда под это есть конкретный вопрос бизнеса или эксплуатации.

Дальше закрепите правило: если поле не используется ни в одном отчете, проверке или решении об изменениях, оно кандидат на удаление.

Обновление должно быть регулярным и без просьб

Актуальность не удержать, если обновление запускают «когда вспомнили». Задайте расписание и триггеры: после деплоя, после патчей, при перезагрузке или по ночам. Лучше чаще и небольшими порциями, чем редко и огромным пакетом.

Помогает короткий набор правил:

• перед вводом нового хоста в эксплуатацию обязателен опрос и запись базовых фактов
• любое изменение конфигурации считается завершенным только после обновления записи
• если хост не обновлялся дольше допустимого, он помечается как «сомнительный» и не участвует в критичных решениях
• для разных данных разные сроки: железо можно реже, пакеты и открытые порты чаще
• исключения согласуются заранее: что делать с «неопрашиваемыми» узлами (изоляция, ручной владелец, временный статус)

Для новых серверов можно сделать «ворота»: без успешного сбора фактов сервер не получает статус production. Это дисциплинирует процесс лучше любых напоминаний.

Типовые ошибки и ловушки при CMDB как код

Самая частая причина, почему реестр «умирает», проста: в него кладут все подряд. Ansible facts дают сотни полей, но если никто не использует их в решениях (инвентаризация, лицензии, емкость, безопасность), это превращается в склад мусора. Через пару месяцев данные перестают проходить проверку здравым смыслом, и CMDB игнорируют.

Вторая ловушка - нет стабильного идентификатора. Хост переименовали, IP поменялся, виртуалку пересоздали, и история «потерялась». Для серверов и ПК надежнее опираться на то, что меняется редко: серийный номер, asset tag, UUID, инвентарный номер. Имя хоста и IP стоит хранить, но не использовать как главный ключ.

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

Еще одна тихая проблема - одинаковые поля с разным смыслом в разных командах. «Окружение» для одних значит prod/test, для других - площадка, для третьих - уровень критичности. Без словаря значений нормализация будет давать шум, а отчеты - противоречия.

Отдельно не игнорируйте права доступа. Если «менять может любой», CMDB быстро станет полем боя. Минимальный набор правил обычно такой:

• ограничить, кто может править справочники и нормализаторы
• разделить права на «правка вручную» и «обновление автосбором»
• логировать, кто и что изменил, с причиной
• защищать критичные поля (идентификаторы, связи, владельца)
• закрепить владельцев данных по доменам (ОС, железо, сеть)

В организациях с большим парком эти ошибки проявляются особенно быстро. Поэтому лучше заложить правила до первого массового импорта.

Короткий чек-лист перед запуском в прод

Перед тем как включать CMDB как код в продакшене, полезно быстро проверить «живучесть» процесса. Вы должны заранее знать, что считается ошибкой, как отличать один сервер от другого и кто принимает решения, когда данные не сходятся.

Проверьте базовые опоры качества данных:

• обязательные поля описаны и валидируются (например, имя узла, среда, владелец, критичность). Пустые значения не «молча» записываются, а возвращают понятную ошибку
• есть устойчивые ключи идентификации и правила дублей: что первично (серийник, UUID, asset tag), что делать при конфликте, как «склеивать» записи при переименовании
• разделены данные, которые обнаруживаются автоматически (Ansible facts), и данные, которые задаются людьми (назначение, владелец, проект). Для ручных полей есть простой способ обновления без правки кода

Дальше убедитесь, что актуальность будет поддерживаться не героизмом:

• запуск по расписанию определен, а не «когда вспомним». Есть отчет: что изменилось, что сломалось, какие хосты не ответили
• для дрейфа заданы пороги и реакция: какие изменения допустимы, какие требуют тикета или согласования

Назначьте владельца процесса и точку входа для изменений. Например: когда команда эксплуатации добавляет новый класс серверов (условно, S200 для стойки), кто обновляет маппинг фактов в модель и кто утверждает новые обязательные поля.

Если эти пункты закрыты, запуск в прод будет похож на управляемый процесс, а не на «реестр ради реестра».

Пример сценария: как поддерживать актуальность на практике

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

Решили внедрить CMDB как код и начать с простых правил. В inventory Ansible разделили хосты по площадкам и ролям (db, app, infra), а на каждом хосте закрепили базовые теги: владелец сервиса, критичность (high/medium/low) и среда (prod/test/dev). Важно, что владелец и критичность задаются людьми и проходят согласование, а факты по железу и ОС приходят автоматически.

Сначала собирали только то, что помогает в ежедневной работе и влияет на риск:

• ОС и версия, ядро, архитектура
• CPU, RAM, размер дисков и свободное место по ключевым точкам
• сетевые адреса и основной интерфейс
• серийный номер или идентификатор VM, модель (если доступно)
• набор «контрольных» пакетов и статус агента мониторинга

Потом настроили нормализацию: привели названия ОС к одному справочнику (например, «Ubuntu 22.04 LTS» без вариантов написания), единицы измерения - к одному формату (GiB), а сетевые интерфейсы - к правилу primary_ip. Отдельно договорились, что считать «значимым изменением»: смена ОС, увеличение или уменьшение ресурсов, появление нового диска, смена primary IP, отключение мониторинга, изменения в списке только тех пакетов, которые входят в allowlist (например, ssh, nginx, postgres).

Через месяц эффект стал заметен. Инциденты закрываются быстрее: дежурный сразу видит, что изменилось с прошлого успешного прогона и кому принадлежит сервис. Согласования стали проще: если просят «временно добавить диск», изменение фиксируется автоматически и не теряется. На аудите проще отвечать, какие системы в проде и кто за них отвечает. Планирование тоже точнее: обновления и миграции опираются на фактические параметры, а не на записи «в реестре годичной давности».

Следующие шаги: пилот, закрепление процесса и поддержка

Начните с малого, но формально. «Мертвый реестр» чаще появляется не из-за инструментов, а потому что никто не отвечает за данные и изменения. Первый шаг - договориться, что именно считается правдой, и кто подтверждает спорные поля.

Зафиксируйте минимальную модель данных: 15-30 полей, без попытки описать все сразу. Обычно достаточно идентификатора узла, среды (prod/dev), роли, ОС, версии ядра, CPU/RAM/дисков, сетевых интерфейсов, установленных пакетов по ключевым группам и тега владельца.

Дальше настройте регулярный сбор фактов Ansible по расписанию и единый формат выгрузки. Важно, чтобы это был один «контракт данных» для всех команд: одинаковые имена полей, единицы измерения и правила заполнения пустых значений.

Перед записью добавьте три защитных слоя: валидацию, нормализацию и отчет об изменениях. Валидация ловит «кривые» значения (например, отрицательный размер диска или неожиданную архитектуру). Нормализация приводит данные к одному виду (GiB vs GB, разные названия ОС, разные формы серийников). Отчет по изменениям показывает, что именно поменялось с прошлого запуска и требует ли это реакции.

Чтобы не распылиться, проведите пилот на одной группе серверов, где проще получить обратную связь, например на 20-50 однотипных узлах. Дальше расширяйте охват поэтапно: сначала инфраструктурные сервисы, затем бизнес-системы.

Проверьте, что процесс закреплен:

• есть владелец модели данных и владелец процесса сбора
• сбор работает по расписанию и имеет мониторинг
• изменения не «теряются»: есть журнал и понятный путь эскалации
• раз в месяц модель пересматривается и чистится от лишнего

Если нужна помощь с архитектурой, интеграцией и инфраструктурой для такого процесса, можно подключать GSE.kz (gse.kz) как системного интегратора: от подбора и поставки серверов до внедрения и 24/7 поддержки в рамках единого контура ответственности.