Asset Management и CMDB в helpdesk: что инвентаризовать и зачем

Зачем нужна CMDB

Стандартная отговорка «у нас 200 человек, всё помним наизусть» работает ровно до первого крупного инцидента. Когда падает сервер 1С, и нужно за 5 минут понять, у кого из 200 сотрудников он работает, а у кого нет — этим знанием обладают 2-3 человека в IT, и они в отпуске.

CMDB — Configuration Management Database — решает три практические задачи:

• Impact analysis: при инциденте сразу видно, кого затронет (через граф зависимостей сервис → пользователи).
• Привязка к заявкам: оператор открывает обращение и видит, на каком ноутбуке работает пользователь, какая версия Windows, какие приложения, история ремонтов.
• Расчёт TCO: видно, сколько денег уходит на конкретный класс активов (ноутбуки старше 5 лет ломаются в 3 раза чаще — данные подскажут, что пора менять).

Самая дорогая ошибка — пытаться внедрить полноценную CMDB по ITIL с самого начала. Это не работает. Реальный путь — начать с lite-варианта (учёт основного железа + ПО + привязка к пользователям) и расширять только когда чувствуешь, что данных не хватает.

Что включать в инвентаризацию

Условные «обязательные» категории активов для среднего бизнеса:

1. Конечные устройства: ноутбуки, ПК, мониторы, периферия. Минимум — серийник, модель, инвентарный номер, кому выдано, дата выдачи, статус (active / repair / decommissioned).
2. Серверы и виртуальные машины: hostname, IP, ОС, роль (DB / app / file), кто администратор, какие сервисы зависят.
3. Сетевое оборудование: маршрутизаторы, свитчи, точки доступа. Опционально, но критично если у вас многоофисная инфраструктура.
4. Лицензии ПО: какие закуплены, сколько, кому назначены, дата окончания (см. отдельную статью про учёт лицензий).
5. Сервисы: внутренние (1С, ЭДО, CRM) и внешние (SaaS-подписки). Здесь и кроется ценность CMDB — связь сервисов с железом.

Что не стоит инвентаризовать в helpdesk на старте: кабели, мыши/клавиатуры по штучно, лицензии типа Microsoft Office E1 если они corporate-wide. Это микроменеджмент, который не окупится.

CMDB lite vs полноценная — где граница

Полная CMDB по ITIL — это десятки типов CI (Configuration Item), связи многие-ко-многим, авторазрешение CMDB-CMDB, импорты из discovery-сканеров типа Lansweeper или ManageEngine. Для большинства компаний это overkill: внедрение занимает 6-12 месяцев, а пользы — на 80% меньше чем от lite.

CMDB lite — это:

• 2-3 типа активов: оборудование, ПО/лицензия, сервис
• Связи один-ко-многим: «у этого пользователя 2 устройства», «этот сервис зависит от этих 3 серверов»
• Ручное ведение или semi-auto (импорт CSV/Excel раз в квартал)
• Привязка к заявкам — оператор видит контекст оборудования при работе с тикетом

Когда «расти» до полной CMDB: появилось 500+ активов и команда тратит больше 4 часов в неделю на ведение, либо начались compliance-требования (ФСТЭК, ISO 27001), которые требуют доказуемого журнала изменений.

Как связать оборудование с заявками

Главная польза CMDB в helpdesk проявляется в двух местах:

При создании заявки. Пользователь в портале выбирает «у меня проблема с ноутбуком», и в выпадающем списке появляется ровно его ноутбук (по привязке user → equipment). Оператор сразу видит модель, ОС, кому выдан, историю ремонтов. Никаких «уточните пожалуйста, какой у вас ноут».

При impact-анализе. Заявок одновременно несколько от разных людей — оператор группирует их по затронутому сервису. Видит, что все 7 заявок касаются доступа к 1С. Открывает CI «1С», видит — там общий сервер, и его последний reboot был час назад. Это уже не 7 разных проблем, а один Major Incident, и решается одной заявкой в инфраструктуру.

В TIQQET это реализовано через раздел «Оборудование» + поле «связанные заявки» в карточке актива. У пользователя в портале — свой раздел «Моё оборудование» с историей. Оператор может одним кликом увидеть всё, что когда-либо ломалось у конкретного устройства.

Где обычно ломается процесс

Три самых частых ошибки при внедрении CMDB:

1. «Заведём в Excel, а потом перенесём». Никогда не переносится. Excel живёт годами, превращается в источник правды для 2-3 человек, остальная команда в нём не работает, данные расходятся с реальностью на 30-40%.
2. Инвентаризация без owner'а. У актива должен быть ответственный — не «отдел IT», а конкретный человек. Иначе через год никто не помнит, кому какая лицензия назначена, и при аудите Касперского начинается паника.
3. Не обновляют после движения. Сотрудник уволился, ноут вернулся в IT, но в CMDB он всё ещё за ним. Через полгода ноут уходит новому сотруднику без обновления записи. После третьей такой итерации CMDB перестаёт отражать реальность. Лечится процессом offboarding с обязательным шагом «сдать оборудование» в helpdesk.

Полезное правило: лучше CMDB с 10 категориями и 100% актуальностью, чем с 50 категориями и 60% актуальностью. Урезайте scope, но требуйте дисциплины обновления.