ИТ-отдел компании на 500 рабочих мест получает заявку: не работает 1С у Иванова. Чтобы понять, какой сервер обслуживает запрос, какая база подключена, какой канал передачи данных задействован и какие зависимости есть у этого сервиса, дежурный инженер тратит 40 минут - он собирает картинку вручную из разных источников.
Если бы в компании была развёрнута CMDB с актуальными связями между сервисами и инфраструктурой, а поверх - ITSM с правильно настроенным процессом, тот же запрос закрылся бы за 10 минут. В этой статье разбираем, что такое CMDB и ITSM, как они работают в паре и зачем это нужно бизнесу.
Что такое CMDB и что такое ITSM
CMDB (Configuration Management Database) - это база, где хранятся все элементы ИТ-инфраструктуры и связи между ними. Каждый элемент называется конфигурационной единицей (CI, Configuration Item). Например, в CMDB компании есть сервер, база 1С на нём, договор с интернет-провайдером и бизнес-сервис «Приём заказов», который зависит от всех трёх: если сервер остановится или связь пропадёт, база сразу покажет, что пострадает приём заказов. Кроме того, в CMDB попадают программное обеспечение, сетевое оборудование, пользователи и владельцы сервисов. CMDB - не просто реестр оборудования, а модель инфраструктуры: каждый объект описан вместе со своими зависимостями, владельцем и ролью в бизнес-сервисах.
ITSM (IT Service Management) - управление ИТ-сервисами как комплекс процессов: обработка инцидентов, запросов, проблем, изменений, поставок и мощностей. ITSM определяет, как ИТ-отдел работает с заявками, как планирует изменения, как отвечает за уровни обслуживания.
CMDB - это база знаний об инфраструктуре, ITSM - набор процессов, который этой базой пользуется. Без CMDB ITSM работает вслепую: инженер не знает, какие объекты затронет изменение и что именно зависит от проблемного сервиса. Без ITSM CMDB не обновляется: инженеры меняют инфраструктуру, не фиксируя изменения в базе, и через полгода модель расходится с реальностью. Два инструмента имеют смысл только в паре.
Как они связаны на практике
Связь CMDB с процессами ITSM
При регистрации инцидента поле «затронутый сервис» автоматически даёт инженеру связку с серверами, базами данных и владельцами сервиса. Диагностика сокращается с десятков минут до нескольких - именно потому, что актуальная база конфигурационных единиц уже содержит нужные зависимости. Инженер видит полную картину без ручного сбора данных. Связи и владельцев сервиса используют для маршрутизации реакции — алертинг и эскалация инцидентов.
При планировании изменения CMDB показывает, какие сервисы пострадают при перезагрузке сервера или обновлении системы. Руководитель техподдержки заранее оценивает риски и оповещает затронутых пользователей, а не разбирает последствия после факта. При расследовании проблемы CMDB помогает найти паттерн: несколько повторяющихся инцидентов связаны с одной и той же конфигурационной единицей - это указывает на корневую причину.
Связь с процессами ITIL
CMDB - основа для практики Service Configuration Management в ITIL 4. ITSM-система реализует ключевые практики фреймворка: Incident Management, Service Request Management, Problem Management, Change Enablement, Service Level Management. Каждая из них опирается на данные о конфигурационных единицах: кто владелец, что от чего зависит, каков SLA по сервису.
Без структурированной модели данных процессы ITIL упрощаются до трекера задач. Без CMDB ИТ-директор не может ответить: почему этот сервис падает второй раз за месяц? Он видит поток заявок, но не видит картину: какие сервисы нагружены инцидентами, где системные проблемы, где узкие места в изменениях.
CMDB и ITSM работают в паре. Внедрять только одно из двух - типичная ошибка, которая даёт либо бесполезную базу, либо процессы без данных.
Как наполнить CMDB и не превратить её в свалку
Главный принцип - начинать с критичных сервисов: 1С, корпоративная почта, видеоконференцсвязь, основные клиентские системы. Попытка занести в базу весь парк за один заход заканчивается тем, что внедрение затягивается, а к моменту запуска половина данных уже не отражает реального состояния инфраструктуры — команда разочаровывается в инструменте ещё до того, как он начинает работать.
Источники наполнения CMDB:
- Ручной ввод для уникальных CI и связей, которые автодискавери не увидит: договоры с вендорами, бизнес-сервисы верхнего уровня, нестандартные зависимости;
- Автодискавери из систем мониторинга и Microsoft Configuration Manager - автоматическое обнаружение хостов, ПО и сетевых устройств без ручного труда;
- Импорт из результатов аудита и инвентаризации - разовое наполнение базы по итогам полного обследования инфраструктуры;
- Синхронизация с Active Directory для пользователей, групп и их привязки к сервисам;
- Синхронизация с CMDB сетевого оборудования для сетевой топологии и связей между узлами.
Если в компании ещё не проводился аудит ИТ-инфраструктуры, начинать наполнение CMDB разумно с него, иначе модель будет строиться на разрозненных представлениях команды о парке. Качество данных важнее охвата. Лучше 200 CI с актуальными связями и назначенными владельцами, чем 5000 мёртвых записей. Регулярная сверка с реальной инфраструктурой - минимум раз в квартал, по критичным сервисам - раз в месяц. Реалистичный горизонт пилота на 50–100 критичных CI: 2–3 месяца. Полноценная CMDB на 500+ CI — от 6 месяцев до года, итерациями.
Российские и зарубежные ITSM-платформы
Что доступно сегодня и как выбирать
Западные классики - ServiceNow, BMC Helix, Atlassian Jira Service Management, мощные платформы с развитой функциональностью CMDB. С 2022 года поставка и поддержка в РФ ограничены, что создаёт риски для компаний, которые уже на них работают.
Российские ITSM-системы - Naumen Service Desk, ITSM 365, SimpleOne, EvaTeam, Itilium, ITHELPER, включены в реестр отечественного ПО Минцифры и активно развиваются. Большинство поддерживают CMDB, интеграцию с AD и автодискавери. Для среднего и крупного бизнеса, который переходит с западных продуктов, это основная зона выбора.
Open-source решения - iTop, GLPI, Zammad - подходят для небольших компаний и пилотных проектов. Они бесплатны, но требуют ресурс на настройку и поддержку.
Критерии выбора ITSM-системы для компании: размер и сложность парка, готовность платить за SaaS против on-prem, наличие готовой интеграции с уже работающими инструментами - мониторингом, AD, бухгалтерской системой. Не выбирать платформу по бренду - критичнее процессная зрелость команды и качество поддержки интеграций. Есть ли у команды описанный процесс обработки инцидентов? Кто назначен владельцем изменений? Если ответы «нет» — платформа не поможет. Подбор платформы логично рассматривать в рамках общей организации ИТ-инфраструктуры: инструмент должен вписываться в архитектуру, а не диктовать её.
Сравнение сегментов ITSM-платформ:
| Сегмент | Примеры платформ | Типовая зона применимости | Комментарий |
|---|---|---|---|
| Западные (коммерческие) | ServiceNow, BMC Helix, Atlassian Jira Service Management | Крупные международные компании, холдинги с развитыми ИТ-процессами | С 2022 года поставка и поддержка в РФ ограничены |
| Российские (коммерческие) | Naumen Service Desk, ITSM 365, SimpleOne, EvaTeam, Itilium, ITHELPER | Средний и крупный бизнес, госсектор, компании под регуляторные требования | Есть в реестре отечественного ПО Минцифры, активно развиваются |
| Open-source | iTop, GLPI, Zammad | Малый бизнес, пилотные проекты, команды с ресурсом на самостоятельное сопровождение | Бесплатны, требуют ресурс на настройку и поддержку |
Типичные ошибки внедрения
Большинство неудачных проектов по внедрению CMDB и ITSM повторяют одни и те же ошибки:
- Попытка наполнить CMDB всем парком за один заход - три месяца внедрения превращаются в два года, а данные устаревают быстрее, чем заносятся.
- Внедрение ITSM «для галочки» без описанных процессов и регламентов - платформу купили, заявки поступают, но не по процессу: без эскалаций, без SLA, без назначения ответственных.
- Отсутствие выделенного владельца CMDB - без ответственного за актуальность база устаревает за полгода и теряет практическую ценность.
- Подмена ITSM трекером задач - без процессов Incident Management, Problem Management и Change Enablement это просто очередь заявок без аналитики и управления качеством.
- Перенасыщение модели CMDB - заводят CI для каждой розетки и флешки. Поддержка такой базы съедает больше рабочего времени, чем даёт пользы.
- Внедрение без обучения пользователей и техподдержки - система есть, но никто не умеет с ней работать по назначению, и через год её используют только для переписки.
Что измерять после внедрения
Внедрение завершено - начинается регулярная работа по поддержанию качества. Для CMDB ключевые метрики: процент охваченных CI от общего парка, актуальность связей (сколько зависимостей подтверждено за последний квартал), время обновления записи после изменения в инфраструктуре. Если инженеры обновляют CMDB через несколько недель после изменения — модель постепенно расходится с реальностью. Проверку времени и состава изменений дополняет централизованное логирование.
Для ITSM-процессов ориентир - MTTR (среднее время восстановления сервиса после инцидента), FCR (доля заявок, закрытых с первого обращения без переназначения), соотношение инцидентов к запросам. Ориентир MTTR по критичным сервисам — до 4 часов, FCR — выше 70%. Если показатели хуже — смотрите на качество данных в CMDB, а не на процессы. Рост доли инцидентов на фоне стабильного парка - сигнал о накопленных проблемах, которые CMDB помогает локализовать.
Практика регулярных ревью владельцами сервисов - минимум раз в квартал каждый владелец сервиса подтверждает актуальность CI и связей в своей зоне ответственности. Это дешевле, чем полный аудит, и надёжнее, чем полагаться только на автодискавери. Владелец сервиса знает о своей области больше, чем любая система мониторинга.
Ответы на частые вопросы
Что такое CMDB простыми словами?
Это база, в которой записаны все элементы ИТ-инфраструктуры и то, как они зависят друг от друга: какой сервис работает на каком сервере, какая база к нему подключена, кто за них отвечает. По ней инженер за минуты видит, что затронет сбой или изменение.
Чем CMDB отличается от инвентаризации?
Инвентаризация даёт список объектов: сколько серверов, какое ПО, где стоит оборудование. CMDB хранит те же объекты вместе со связями между ними и с бизнес-сервисами, поэтому отвечает не только на вопрос «что у нас есть», но и на вопрос «что сломается, если это отключить». Результаты инвентаризации часто используют для первичного наполнения CMDB.
Можно ли вести CMDB в Excel?
При 50–100 конфигурационных единицах можно: таблицы с объектами и связями справляются. Дальше связи вручную уже не поддерживаются, изменения не фиксируются вовремя, и модель быстро расходится с реальностью. На этом этапе нужна ITSM-система с CMDB и автодискавери.
Есть ли ITSM-системы с CMDB в реестре российского ПО?
Да. Naumen Service Desk, ITSM 365, SimpleOne, EvaTeam, Itilium и ITHELPER включены в реестр отечественного ПО Минцифры, и большинство из них поддерживают CMDB, интеграцию с AD и автодискавери.
Сколько длится внедрение?
Пилот на одном критичном сервисе занимает 1–3 месяца, пилот на 50–100 критичных CI обычно укладывается в 2–3 месяца. Полноценная CMDB на 500+ CI строится итерациями от 6 месяцев до года.
Заключение
Решение про CMDB и ITSM строится в несколько шагов. Сначала оцените размер парка и зрелость ИТ-процессов. Для небольших компаний до 100 пользователей хватает упрощённой модели ITSM с трекером и базового CMDB на 30–50 ключевых CI. Для среднего и крупного бизнеса нужна полноценная ITSM-платформа с CMDB и автодискавери, иначе управляемость теряется вместе с ростом парка.
Начинайте с критичных сервисов и расширяйтесь итерациями. Выделите владельца CMDB и установите регламент сверки. Обучите команду и пользователей, прежде чем запускать процессы в рабочем режиме. Без этого даже самая дорогая платформа через год превращается в красивую витрину без практического смысла. CMDB и ITSM - это не разовое внедрение, а постоянная практика управления инфраструктурой, которая окупается снижением времени на устранение сбоев и предсказуемостью изменений.