CMDB в OTRS: импорт 400 единиц оборудования из OCS Inventory и связи между CI

ITIL v3 2011 Edition вышел буквально на прошлой неделе - обновлённая редакция со структурированными уточнениями по Service Asset and Configuration Management. Для нас это совпало с тем, что мы как раз заканчиваем первый реальный проект по CMDB для одного из клиентов на сопровождении. Повод зафиксировать, что вышло, а что нет.

Зачем вообще CMDB при уже работающем OTRS

У клиента - производственная компания, около 400 единиц оборудования в учёте - OTRS уже стоял и работал как helpdesk. Тикеты, очереди, SLA-таймеры. Всё это живёт и справляется. Проблема вылезла в change management: заявка на изменение приходит, инженер смотрит на неё и не видит контекста - к чему подключён этот сервер, что от него зависит, когда последний раз меняли конфиг. Всё это было в головах и в Excel-файлах разной степени актуальности.

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

OTRS начиная с версии 2.4 включает модуль CMDB - не отдельный продукт, а часть ядра. CI (Configuration Items), классы, атрибуты, связи между объектами и привязка CI к тикетам. Лицензия AGPL, без доплат.

Импорт из OCS Inventory

Вручную заносить 400 единиц - очевидно нет. OCS Inventory у клиента уже работал для инвентаризации парка: агенты на Windows и Linux, регулярный сбор данных по железу и ПО. База данных MySQL, структура более-менее предсказуемая.

Написали скрипт импорта - Perl, потому что OTRS сам написан на Perl и API там Perl-ориентированное. Логика простая: берём из OCS таблицу hardware, networks, bios, формируем объекты CI нужного класса и через OTRS API (Kernel::System::ITSMConfigItem) создаём записи. Атрибуты маппим один к одному где совпадают (имя хоста, IP, MAC, серийный номер), остальное - вручную.

Классы настроили под реальный парк:

• «Сервер» - с атрибутами: имя, IP-адреса (несколько), ОС, версия ОС, серийный номер, стойка, производитель.
• «Рабочая станция» - проще, основное что нужно: имя, пользователь, отдел, ОС.
• «Сетевое оборудование» - свитчи, маршрутизаторы, с атрибутами вплоть до версии прошивки.
• «Сервис» - виртуальная сущность: имя сервиса, ответственный, SLA-тир.

Импорт прошёл в два захода. Первый - автоматически из OCS, около 320 объектов. Второй - ручное добавление сетевого оборудования, которое OCS не видит (там нет агента), около 80 единиц. Суммарно вышло за 400.

Грабля на которую наступили: OCS хранит историю инвентаризаций, и если брать просто последнюю запись, часть данных устаревшая. У нескольких серверов в OCS висел старый IP после переезда в другую VLAN. Поэтому перед импортом прогнали сверку с DNS и таблицами DHCP - несоответствия нашли и поправили руками.

Связи между CI

Это самое ценное и самое трудоёмкое. OTRS позволяет определять типы связей между CI: «зависит от», «подключён к», «является частью» и т.д. Настроили несколько типов под нашу задачу.

Связи прописывали руками - скриптом это не автоматизируешь разумным образом, нужно понимание топологии. Заняло примерно три дня работы инженера клиента, который знает инфраструктуру изнутри. Результат - граф зависимостей, в котором видно: вот сервис 1С-бухгалтерия, он зависит от сервера приложений, тот зависит от SQL-кластера, оба кластерных узла подключены к свитчу такому-то в стойке такой-то.

Когда приходит тикет на изменение - инженер открывает нужный CI и видит граф в одном экране. Это уже не Excel.

История изменений

OTRS ведёт историю по каждому CI автоматически: кто изменил, что изменил, когда. Плюс связь CI с тикетами - если изменение проводилось по RFC-тикету, оно привязано к конкретному объекту. Через полтора месяца работы у критичных серверов уже появилась читаемая история - кто когда менял конфиг, какой тикет инициировал.

Для change management это меняет разговор: теперь при анализе инцидента можно открыть историю CI и увидеть, что три дня назад к этому серверу было изменение - и вот тикет, вот инженер, вот что именно делали.

Что работает хуже, чем хотелось бы

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

Веб-интерфейс связей CI в OTRS 2.x не самый наглядный - список, не граф. Для понимания зависимостей с большим количеством связей хотелось бы визуальную карту, но её нет. Смотрим в сторону плагинов, пока ничего подходящего не нашли.

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

В целом - работает. Change management с реальным контекстом вместо звонков «а ты знаешь, к чему это подключено?» - уже ощутимый результат.