ИТ-отдел компании на 500 рабочих мест получает заявку: не работает 1С у Иванова. Чтобы понять, какой сервер обслуживает запрос, какая база подключена, какой канал передачи данных задействован и какие зависимости есть у этого сервиса, дежурный инженер тратит 40 минут - он собирает картинку вручную из разных источников.
Если бы в компании была развёрнута CMDB с актуальными связями между сервисами и инфраструктурой, а поверх - ITSM с правильно настроенным процессом, тот же запрос закрылся бы за 10 минут. В этой статье разбираем, что такое CMDB и ITSM, как они работают в паре и зачем это нужно бизнесу.
Что такое CMDB и что такое ITSM
CMDB (Configuration Management Database) - это база конфигурационных единиц (CI) и их взаимосвязей. В неё попадают сервисы, серверы, программное обеспечение, базы данных, сетевое оборудование, договоры с поставщиками, пользователи и связи между всеми этими объектами. 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-платформ:
Типичные ошибки внедрения
Большинство неудачных проектов по внедрению 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 и ITSM строится в несколько шагов. Сначала оцените размер парка и зрелость ИТ-процессов. Для небольших компаний до 100 пользователей хватает упрощённой модели ITSM с трекером и базового CMDB на 30–50 ключевых CI. Для среднего и крупного бизнеса нужна полноценная ITSM-платформа с CMDB и автодискавери, иначе управляемость теряется вместе с ростом парка.
Начинайте с критичных сервисов и расширяйтесь итерациями. Выделите владельца CMDB и установите регламент сверки. Обучите команду и пользователей, прежде чем запускать процессы в рабочем режиме. Без этого даже самая дорогая платформа через год превращается в красивую витрину без практического смысла. CMDB и ITSM - это не разовое внедрение, а постоянная практика управления инфраструктурой, которая окупается снижением времени на устранение сбоев и предсказуемостью изменений.
