Что такое CMDB-системы и управление конфигурациями

ИТ-инфраструктура крупной компании растёт почти каждую неделю. Появляются новые серверы, сервисы, контейнеры и интеграции, а число связей между всеми этими элементами увеличивается вместе с ними. В какой-то момент ни один человек уже не держит в голове полную картину того, что от чего зависит.

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

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

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

Сама по себе такая система работает редко. Она плотно переплетена с управлением ИТ-услугами (его называют ITSM), с практиками DevOps, с наблюдаемостью за системами (observability), с управлением изменениями (по-английски change management). Если этот источник устарел, все перечисленные процессы идут почти вслепую.

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

Управление конфигурациями: единая система собирает сведения обо всех слоях инфраструктуры, связывает их с бизнес-сервисами.

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

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

Если коротко, это CMDB - единое хранилище, где описаны все значимые компоненты ИТ-инфраструктуры с их взаимосвязями. Сюда попадают серверы, программы, СУБД, сети, лицензии, договоры и даже сотрудники, которые за всё это отвечают.

Базовый элемент, из которого собирается любая такая CMDB, называют конфигурационной единицей. В английском варианте это configuration item, в сокращении — просто CI. По определению ITIL, CI — это любая деталь, которой приходится управлять, чтобы ИТ-услуга работала.

В роли CI может выступать почти всё: железный сервер, виртуальная машина, контейнер, сетевой маршрутизатор, программа, целый бизнес-сервис. При этом у разных типов CI характеристики разные. У сервера это серийный номер, модель; у виртуальной машины — объём памяти, число процессорных ядер; у лицензии — срок действия, поставщик.

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

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

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

CMDB и управление ИТ-активами: в чём разница

Систему управления конфигурациями часто путают с управлением ИТ-активами (ITAM), хотя задачи у них разные. ITAM отвечает на вопрос «что у нас есть»: ведёт инвентаризацию оборудования, ПО, лицензий, следит за их жизненным циклом, стоимостью владения и соответствием требованиям. Карта зависимостей отвечает на вопрос «как это связано»: показывает связи между компонентами, их влияние на ИТ-услуги.

Разницу удобно показать на простом примере. Компьютер, мышь — это активы, оба попадут в систему учёта ИТ-активов. Но в карту зависимостей есть смысл заводить только компьютер: у него есть связи, от которых зависит работа сервисов. У мыши такой сети зависимостей нет, поэтому в карте инфраструктуры ей делать нечего.

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

И компьютер, и мышь — активы, но в CMDB попадает только то, у чего есть зависимости.

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

Почему бизнесу нужна CMDB

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

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

DevOps и высоконагруженные системы (highload) только обостряют проблему. Релизы выходят постоянно, инфраструктура поднимается и гасится автоматически, конфигурации меняются по нескольку раз в день. Документация, которую ведут руками, не успевает за этим темпом в принципе.

Из отсутствия единого источника конфигураций вырастает целый набор типовых болей:

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

Для регулируемых отраслей последний пункт особенно чувствителен: после ужесточения 152-ФЗ о персональных данных в 2025 году цена утечки или простоя измеряется уже не только репутацией, но риском многомиллионных штрафов и остановки бизнеса.

Вот наглядный пример из жизни. Сведения одной системы лежат в зоне ответственности одного отдела, сведения зависимой системы — у другого. Первый отдел выводит свой компонент на обслуживание, даже не догадывается, что без него встанет сервис соседей. В лучшем случае это путаница, в худшем — крупный простой, который стоит компании реальных денег. Цена таких сбоев растёт: по оценкам Uptime Institute, более половины организаций считают последствия последнего крупного простоя дороже 100 тыс. долларов, а каждая пятая — дороже 1 млн долларов.

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

Преимущества CMDB

Если свести всё к конкретным результатам, грамотно выстроенная система даёт бизнесу несколько ощутимых выгод:

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

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

Важно. CMDB окупается не тем, что красиво рисует схемы, а тем, что сокращает простои, ускоряет разбор инцидентов и убирает «сюрпризы» при изменениях. Это прямая экономия, особенно в крупных и распределённых компаниях.

Что важно учесть при использовании CMDB

Та самая статистика Gartner — лишь четверть компаний получает реальную отдачу — объясняется не слабостью технологии, а тем, как к ней подходят. Чтобы система действительно работала, а не превращалась в красивую, но мёртвую схему, стоит держать в голове несколько вещей:

1. У системы должны быть чёткая цель, владелец. Она нужна не «вообще» — она нужна под конкретные процессы: управление инцидентами, изменениями, планирование. Если цель не сформулирована, хранилище быстро наполняется лишними записями, которые никто не использует.
2. Не стоит тащить в неё всё подряд. Соблазн сделать «единый источник правды» буквально — сложить в одно место вообще всё — обычно оборачивается лишней работой, кашей. Эффективнее федерация: финансовые сведения остаются в системе ИТ-финансов, лицензии — в инструменте учёта ПО, а карта зависимостей подтягивает их по ссылке, хранит у себя только то, что нужно для анализа связей.
3. Ставку лучше делать на автоматический сбор, а не на ручной ввод. Чем больше источников обнаружения, интеграций, тем точнее картина, тем дольше всё остаётся актуальным. Ручное ведение допустимо лишь там, где иначе нельзя — например, для обычных мониторов, которые средства обнаружения попросту не видят.
4. Стоимость платформы не главное. Дорогое решение само по себе ничего не гарантирует — гораздо важнее, чтобы у неё был ответственный, понятный сценарий применения, работающий механизм обновления.

Как работает управление конфигурациями в CMDB

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

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

Когда таких связей много, из них складывается топология — карта всей инфраструктуры. На её основе строится service mapping, то есть привязка технических компонентов к бизнес-сервисам. Графически это выглядит как сеть узлов, соединяющих их линий.

Главная польза от такой карты — сопоставление зависимостей, анализ влияния изменений. Перед тем как обновить СУБД либо перезагрузить сервер, инженер видит на схеме, какие сервисы и пользователи это затронут.

Разберём это на коротком сценарии. Команда планирует обновить сервис лимитов из примера выше. По связям сразу видно, что от него зависит платёжное приложение, через него — бизнес-сервис онлайн-оплаты. Значит, работы нужно проводить в окно с низкой нагрузкой и предупредить смежные команды заранее.

Карта зависимостей: перед обновлением сервиса лимитов сразу видно, что работа затронет платёжное приложение и бизнес-сервис онлайн-оплаты.

Именно поэтому CMDB считается фундаментом управления изменениями. Без неё каждое изменение — лотерея, а с ней — управляемая операция с понятными последствиями. Для высоконагруженных (highload), enterprise-систем, где простой стоит особенно дорого, это критично.

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

Какие данные хранятся в CMDB

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

Перечислим основные группы объектов, которые обычно ведут в базе:

• серверы, виртуальные машины с их характеристиками, статусом;
• контейнеры, кластеры Kubernetes, в которых живут современные приложения;
• приложения, микросервисы, обеспечивающие бизнес-функции;
• API, интеграционные потоки между системами;
• СУБД, их экземпляры;
• сетевое оборудование: маршрутизаторы, коммутаторы, файерволы;
• бизнес-сервисы, связанные с ними SLA;
• владельцы сервисов, ответственные за каждый уровень.

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

Чтобы стало понятнее, что именно описывают как CI, ниже собраны CMDB примеры в виде таблицы.

Попадают в базу объекты по-разному. Часть сведений собирается автоматически средствами обнаружения, часть подтягивается через интеграции, что-то приходится вносить вручную. Например, обычный монитор автоматические средства обнаружения не видят, поэтому его заводят руками.

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

На заметку. Полезно начинать не с попытки описать всё подряд, а с критичных для бизнеса элементов: ключевых серверов, приложений, сетевого оборудования. Расширять состав лучше постепенно, по мере того как появляется реальная потребность.

CMDB-системы: какие бывают решения

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

1. Первая группа — классические enterprise-платформы. Это мощные решения для крупных компаний с тысячами конфигурационных единиц, развитыми средствами обнаружения, федерацией, тонкой настройкой прав доступа. Они дороги во внедрении, зато тянут самые сложные ландшафты.
2. Вторая группа — cloud-native решения. Такие программы изначально заточены под облака, контейнеры и быстро меняющуюся, эфемерную инфраструктуру. Они опираются на обнаружение по событиям, хорошо переживают ситуацию, когда сотни компонентов поднимаются, гаснут автоматически.
3. Третья группа — это CMDB open source. Открытые продукты вроде iTop, GLPI и Ralph привлекательны тем, что у них нет лицензионных платежей, есть активное сообщество и широкие возможности для доработки. Взамен компания берёт на себя установку, поддержку и развитие силами своих инженеров.
4. Четвёртая группа — встроенное решение внутри ITSM. Здесь конфигурационный каталог встроен прямо в систему управления ИТ-услугами либо service desk. Это самый частый путь для среднего бизнеса: не нужно покупать отдельный продукт, а сведения сразу связаны с заявками, инцидентами.

Чтобы сравнить подходы, сведём плюсы, минусы в таблицу.

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

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

Как CMDB связана с ITSM, DevOps и мониторингом

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

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

В управлении изменениями она заранее показывает, какие компоненты пострадают от планируемой работы. Команда оценивает риски, выбирает безопасное окно и предупреждает смежников. В регулируемых отраслях она ещё упрощает аудит: вся история изменений зафиксирована.

С наблюдаемостью, мониторингом связь двусторонняя. Системы мониторинга поставляют актуальные статусы компонентов, а модель, в свою очередь, объясняет, к какому бизнес-сервису относится конкретная метрика либо авария. Так строится ресурсно-сервисная модель, где состояние сервиса автоматически пересчитывается по состоянию его частей.

Для DevOps, SRE особенно важна связь с конвейером CI/CD. Когда новая версия проходит сборку и развёртывание, конфигурация должна обновляться автоматически, без ручного ввода. Иначе модель начнёт отставать от реальности уже через несколько релизов.

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

• Incident management — быстрый поиск затронутых компонентов, первопричины;
• Change management — оценка влияния изменений до их внедрения;
• Observability, monitoring — привязка статусов, метрик к сервисам;
• CI/CD — автоматическое обновление конфигураций после каждого релиза;
• SRE, Platform Engineering — единая картина зависимостей для надёжности платформы.

Единый источник правды редко работает в одиночку: она становится общим источником данных для управления инцидентами, изменениями, мониторинга, CI/CD и SRE — и остаётся актуальной за счёт автоматического обновления по событиям.

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

Почему CMDB становится критически важной для микросервисной архитектуры

Микросервисная архитектура поменяла правила игры. Вместо одного крупного приложения теперь работают десятки и сотни мелких сервисов, каждый из них общается с соседями через сеть API-вызовов. Зависимостей стало на порядок больше.

Kubernetes, service mesh добавили динамики. Поды поднимаются и гаснут, нагрузка распределяется автоматически, адреса меняются. Это уже не нишевая история: по результатам ежегодного исследования CNCF за 2025 год, Kubernetes используют в продакшене 82% компаний, работающих с контейнерами, против 66% двумя годами ранее. В такой среде статичная табличка устаревает буквально за минуты, вместе с ней теряется понимание того, что на что влияет.

Отдельная сложность — распределённые системы, эфемерная инфраструктура. Компонент, который существовал утром, к обеду может быть пересоздан с другими параметрами. Отследить такие изменения глазами и руками физически невозможно.

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

Именно поэтому в микросервисном мире такая модель перестаёт быть «приятным дополнением». Управлять зависимостями вручную здесь невозможно в принципе, единственный рабочий вариант — автоматический сбор и постоянно обновляемая карта связей.

На заметку. Чем динамичнее инфраструктура, тем меньше смысла в ручном ведении. Для микросервисов, Kubernetes важна не сама модель, а её способность обновляться автоматически по событиям из оркестратора, конвейера.

Как внедряют CMDB в крупных компаниях

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

• Первый шаг — обнаружение, или discovery. Здесь собирают сведения об инфраструктуре из всех доступных источников: сетевых сканеров, систем учёта активов, мониторинга, конвейеров доставки, экспертных знаний инженеров. Чем больше источников, тем полнее картина.
• Второй шаг — нормализация. Собранную информацию приводят к единым стандартам, убирают дубликаты и мусор. Если загрузить всё «как есть», без проверки, выстроить корректные связи, ресурсно-сервисную модель не получится.
• Третий шаг — назначение владельцев. У каждой группы конфигурационных единиц должен быть ответственный, который отвечает за её актуальность. Хранилище без владельцев умирает первым.

Дальше идут интеграции, управление, постоянная актуализация. Систему связывают с ITSM, мониторингом, DevOps-конвейером, договариваются о правилах ведения, настраивают регулярную сверку с реальностью. Хороший ориентир — сверка не реже раза в квартал, а ещё лучше автоматическое обновление по событиям.

Частые ошибки при внедрении CMDB

Теперь о граблях, на которые наступают чаще всего:

• «Мёртвая» система — наполнили один раз, забыли, сведения устарели;
• Ручное обновление — инженеры вносят изменения от случая к случаю, расхождение копится;
• Отсутствие владельцев — никто не отвечает за актуальность, ответственность размывается;
• Отсутствие интеграций — система живёт отдельно от мониторинга, CI/CD, поэтому не успевает за релизами;
• Лишние объекты — тянут всё подряд, среди мусора теряется важное.

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

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

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

Платформенный подход к управлению инфраструктурой

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

Именно так устроена экосистема Digital Q от «Диасофт». Это набор low-code платформ, которые покрывают разработку, доставку, интеграцию и эксплуатацию в общем контуре. Конфигурационные сведения при этом не приходится переносить руками из одной системы в другую.

Управление конфигурациями в экосистеме держится на платформе Digital Q.CMDB. Она ведёт единый каталог ИТ-компонентов, описывает инфраструктурную, продуктовую конфигурацию стендов, помогает планировать поставки продуктов на нужные окружения. По сути это тот самый единый источник правды об инфраструктуре.

Платформа здесь не изолирована, а связана с соседними. Конфигурация обновляется при доставке релизов через Digital Q.DevOps — конвейер для непрерывной интеграции, тестирования, доставки, развёртывания. После установки поставки текущая конфигурация стенда обновляется автоматически, без ручного ввода.

За сервисную часть отвечает платформа Digital Q.ServiceDesk — единый контур ITSM, Service Desk, ESM. Заявки, инциденты, изменения связываются с конкретными конфигурационными единицами, поэтому инженер сразу видит контекст: какое ПО, оборудование затронуто, какие сервисы зависят от проблемного компонента. Соблюдение сроков при этом контролируется по SLA, заданным для каждого сервиса.

Состояние компонентов в реальном времени отслеживает платформа мониторинга Digital Q.Health. Её компонент «Управление метриками» собирает, рассчитывает показатели из разных источников, контролирует пороговые значения, рассылает предупреждения при выходе за допустимые диапазоны — ещё до того, как отклонение перерастёт в инцидент.

Эти показатели насыщают ресурсно-сервисную модель, статус бизнес-сервиса автоматически пересчитывается по состоянию его частей. А Digital Q.Integration связывает все системы между собой: это промышленная интеграционная платформа на основе популярных open source решений (Kafka, Artemis), через которую текут сведения о конфигурациях, событиях.

На заметку. Ценность платформенного подхода не в отдельных продуктах, а в их связке. Когда конфигурационный каталог, DevOps, мониторинг, интеграция работают в одном пространстве, конфигурации обновляются сами, инфраструктура остаётся управляемой даже при микросервисной сложности.

Часто задаваемые вопросы о CMDB

Чем система управления конфигурациями отличается от учёта ИТ-активов?

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

Нужна ли CMDB среднему бизнесу или это история только для крупных компаний?

Зависит не столько от размера компании, сколько от сложности инфраструктуры. Если речь о нескольких десятках рабочих станций, стандартном наборе офисного ПО, обычно хватает простого учёта активов. Карта зависимостей оправдана, когда компонентов уже сотни, между ними много связей, число ИТ-услуг растёт. Среднему бизнесу чаще всего подходит вариант, встроенный в ITSM-систему.

Можно ли вести конфигурационный каталог вручную?

На старте, для небольшого ландшафта — да. Но чем динамичнее инфраструктура, тем быстрее ручной каталог отстаёт от реальности: при микросервисах, Kubernetes компоненты поднимаются, гаснут быстрее, чем кто-то успевает обновить таблицу. Поэтому для зрелого ландшафта рабочий вариант один — автоматический сбор, обновление по событиям из конвейера, мониторинга.

Сколько времени занимает внедрение?

Зависит от масштаба инфраструктуры, зрелости процессов. Базовый вариант под критичные сервисы можно запустить относительно быстро, а полноценный охват в крупной компании с тысячами конфигурационных единиц, множеством интеграций — это уже проект на несколько месяцев. Поэтому состав обычно расширяют постепенно, а не пытаются описать всё сразу.

Что делать, если сведения устарели?

Устаревание — главная болезнь таких CMDB: по оценкам аналитиков, точность сведений в среднестатистическом хранилище держится около 60%. Лечится это регламентом актуализации, автоматизацией — интеграцией с мониторингом, CI/CD, обязательным обновлением конфигурации при каждом изменении, регулярной сверкой с реальностью: как минимум раз в квартал, а лучше автоматически по событиям.

Заключение

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

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

Без такой опоры эффективно управлять корпоративными ИТ практически невозможно. Инциденты тянутся дольше, изменения ломают «неожиданные» системы, а аудит и IT-комплаенс буксуют из-за устаревших сведений. С CMDB все эти процессы получают надёжную опору.

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

Будущее за платформенным подходом, автоматизацией. Аналитики смотрят ещё дальше: по прогнозам Gartner, его всё чаще связывают с CMDB под управлением ИИ, — такие решения должны сами выявлять расхождения с реальностью, прогнозировать сбои, а единый источник правды об инфраструктуре рассматривают как опору не только для эксплуатации, но для FinOps, безопасности. Когда система обновляется сама, по событиям из конвейера, мониторинга, а все инструменты живут в едином пространстве, компания управляет реальной инфраструктурой, а не её устаревшим описанием. Именно это означает порядок вместо хаоса.

Если вы хотите выстроить управление конфигурациями на единой платформе, где конфигурационный каталог, DevOps-конвейер, мониторинг, ITSM работают в одном контуре, обмениваются информацией автоматически, — познакомьтесь с экосистемой Digital Q от «Диасофт». Оставьте заявку — наши эксперты помогут оценить вашу инфраструктуру, подобрать сценарий внедрения под задачи бизнеса.

Илья Виссарионов Директор департамента "Аппаратно-системная платформа", Диасофт

Опубликовано: 09.06.2026 Время чтения: 28 минут