Управление конфигурациями и CMDB: что это в ITSM

Кратко

Управление конфигурациями — это учёт ИТ-активов компании (серверов, приложений, лицензий, оборудования) и связей между ними: что от чего зависит, что на чём установлено, что сломается, если убрать один элемент. Хранилище этих данных называется CMDB (Configuration Management Database) — база данных управления конфигурациями. Практический смысл не в самом факте учёта, а в одном вопросе, на который CMDB отвечает быстро: если сейчас упадёт вот этот сервер, какие сервисы и каких клиентов это заденет. Это одна из практик ITSM — подхода к организации ИТ-услуг в целом, см. Что такое ITSM-система простыми словами.

Актуально на 23 сентября 2026 года.

Из чего состоит CMDB

Базовая единица CMDB — конфигурационная единица (Configuration Item, CI): любой объект, который стоит учитывать отдельно и у которого есть жизненный цикл, — сервер, виртуальная машина, приложение, лицензия, сетевое устройство, иногда — документ вроде договора поддержки.

Что фиксируют по каждой CIЗачем
Идентификатор и владелецКто отвечает за объект и с кем согласовывать изменение
Тип и статус (в работе, в резерве, списан)Понимать, что вообще актуально прямо сейчас
Связи с другими CIВидеть зависимости, а не только список объектов по отдельности
История измененийРазбирать инциденты по тому, что менялось перед сбоем

Главная ценность CMDB — не список сам по себе (это просто инвентарь), а связи между объектами. Инвентарная опись отвечает на вопрос «что у нас есть»; CMDB — на вопрос «что зависит от чего» и, соответственно, «что заденет отказ конкретного элемента».

Зачем управление конфигурациями нужно на практике

Ускоряет расследование инцидента. Когда падает сервис, первый практический вопрос — что с ним связано и что недавно менялось рядом. Без CMDB это восстанавливают по памяти сотрудников и переписке; с ней — смотрят связи объекта.

Снижает риск при изменениях. Перед плановым изменением (обновление, миграция, отключение сервера на обслуживание) видно заранее, какие сервисы и системы от объекта зависят, — это и есть основа для управления изменениями, соседнего процесса ITIL. Подробнее о разделении практик — в статье ITIL: что это простыми словами.

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

Чем управление конфигурациями отличается от соседних практик

Термин часто путают с близкими понятиями — разница принципиальная:

  • Управление конфигурациями (Configuration Management) vs управление активами (Asset Management). Asset Management — про финансовую и юридическую сторону объекта (стоимость, амортизация, договор); Configuration Management — про техническую сторону и связи. На практике их нередко ведут в одной системе, но вопросы, на которые они отвечают, разные.
  • Configuration Management vs Change Management. Управление изменениями — это процесс согласования и внесения изменений; CMDB — источник данных, на основании которых этот процесс принимает решения. Одно без другого работает плохо: изменения без CMDB согласуются вслепую, CMDB без процесса изменений быстро устаревает.
  • CMDB vs обычная инвентарная таблица в Excel. Формально это тоже учёт объектов, но без связей между ними и без процесса поддержания актуальности таблица превращается в снимок на день заполнения, а не в рабочий источник данных.

Когда CMDB нужна, а когда это лишняя сложность

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

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

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

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

Как начать без полномасштабного проекта

  • Начните с одной категории CI — например, только серверы или только критичные для бизнеса сервисы, а не весь ИТ-ландшафт разом. Общие принципы поэтапного внедрения без затягивания проекта — в статье Внедрение Service Desk: этапы и частые ошибки.
  • Зафиксируйте только связи, которые реально важны для расследования инцидентов и оценки риска изменений, а не любые технически возможные.
  • Назначьте владельца процесса, который отвечает за актуальность записей, — без ответственного CMDB устаревает первой же после запуска.
  • Свяжите обновление CMDB с процессом изменений: любое плановое изменение инфраструктуры должно сопровождаться обновлением записи, а не идти параллельно с ней.

Частые вопросы

CMDB — это программа или процесс?

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

Обязательна ли CMDB для работы по ITIL?

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

Чем CMDB отличается от системы учёта заявок?

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

Как это устроено в TehProf.kz Support

TehProf.kz Support — система для обработки обращений: заявки, статусы, SLA, каналы связи и переписка с клиентом. Учёта ИТ-активов, объектов обслуживания и связей между ними (CMDB) в продукте нет — это не служба, спроектированная под сервисную инженерию оборудования, а служба для переписки по обращениям. Если у компании есть отдельная CMDB или система учёта активов, заявки в TehProf.kz Support можно связывать со сделками, компаниями и контактами Битрикс24, но не с техническими объектами инфраструктуры.

Связанные статьи

Нужна поддержка, которая так и работает?

TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.