🧠 Skills: CMDB — кладбище данных или реальный инструмент. Зависит от одного решения

Коллеги, у большинства из нас есть CMDB. У меньшинства она актуальна. Это не проблема инструмента — это проблема подхода.

Классический путь: потратили месяц на заполнение, полгода спустя данные устарели, никто не верит, никто не обновляет. Инструмент есть, пользы нет.

Главная ошибка — CMDB заполняется вручную и живёт отдельно от реальных изменений инфраструктуры. Основная проблема CMDB — сложность актуализации данных. Идея CMDB формировалась в эпоху статичных «железных» конфигураций. Для современных динамичных сред нужен другой подход.

Единственный подход который работает в 2026 — автообнаружение + IaC как источник истины:

РАБОЧАЯ СХЕМА ДЛЯ CMDB:

Источники данных (автоматически, не вручную):
  ├── Terraform/Ansible state → что задеплоено и как
  ├── Netbox/NetAct → сетевые устройства и IP
  ├── Zabbix/Prometheus → что живёт и что мониторится
  └── AD/Entra → пользователи и машины

Принцип: если изменение не прошло через IaC —
оно не существует с точки зрения CMDB.

Что хранить в CMDB (только это, ничего лишнего):
  [CI]        Сервер / VM / контейнер
  [Атрибуты]  ОС, IP, owner, окружение (prod/stage/dev)
  [Связи]     Что от чего зависит (БД → приложение → балансер)
  [Статус]    Active / Decommissioned / Maintenance

Что НЕ хранить:
  ✗ Версии ПО (это в Ansible inventory)
  ✗ Пароли и ключи (это в Vault)
  ✗ История изменений (это в Git)

Ключевой вопрос перед добавлением любого атрибута в CMDB: кто будет поддерживать это актуальным и как? Если ответа нет — атрибут не нужен.

Зачем это нужно:
CMDB с актуальными зависимостями отвечает на вопрос "что упадёт если я выключу этот сервер?" за секунды, а не за час расследования. Это разница между проактивным и реактивным администрированием.

Итог: хорошая CMDB — это не большая, а актуальная. Лучше 50 записей которым все верят, чем 5000 которые никто не читает.

#skills #cmdb #itsm #infrastructure #sysadmin #admin_future