CMDB на 400 активов: как мы строили базу CI в OCS Inventory + GLPI и что из этого вышло

В сентябре мы писали про Change Management по ITIL v3 - RFC, CAB, план отката. Там же упомянули, что строим CMDB параллельно, потому что без базы конфигурационных единиц RFC висит в воздухе. Вот что из этого получилось в полном масштабе у другого клиента - компания покрупнее, инфраструктура около четырёхсот активов, три площадки.

Клиент на сопровождении инфраструктуры поставил задачу чётко: хотим понимать, что у нас есть, как это связано, и почему упало именно то, что упало. Звучит разумно. На практике это означает, что нам нужна нормальная CMDB - не Excel с колонками «инвентарный номер» и «где стоит», а рабочая база конфигурационных единиц со связями между ними и историей изменений.

Почему OCS Inventory + GLPI

Выбирали инструмент недолго. Платные решения типа HPE Asset Manager - избыточно и дорого для клиента такого масштаба. Самописные базы в Excel или Access - это путь в никуда, уже видели. Остановились на связке OCS Inventory + GLPI: первый собирает инвентарь автоматически через агентов, второй - ITSM-надстройка с CMDB, инцидентами, RFC и привязкой всего к конкретным CI.

Оба продукта open source, оба на тот момент живые и с нормальным сообществом. GLPI умеет импортировать данные из OCS - это ключевое, потому что руками вносить четыреста позиций никто не хочет, а автоматическая инвентаризация даёт хотя бы железную основу.

Что делали месяц

Первая неделя - разворачивание и агенты. OCS Inventory Server на отдельной виртуалке, агенты раскатали через групповые политики на Windows-машины, на Linux - руками там, где не было централизованного управления. Сетевое оборудование - отдельная история: OCS его не трогает, данные по коммутаторам и маршрутизаторам вносили вручную по данным из мониторинга. У нас уже работал Zabbix - про него писали в апреле - так что базовая инвентаризация сети там уже была, осталось перенести в GLPI.

Вторая неделя - категории CI и классификация. ITIL v3 говорит, что CI - это всё, что нужно управлять для предоставления сервиса. На практике нужно решить, что именно вы тащите в базу, иначе она превращается в свалку. Определили три уровня:

• Аппаратные CI - серверы, рабочие станции, сетевое оборудование, принтеры (только сетевые, не USB-штуки на столах).
• Программные CI - ОС, бизнес-приложения, СУБД; не каждый установленный Firefox, но всё, что стоит на серверах и что поддерживаем.
• Сервисные CI - логические сущности: «1С-кластер», «корпоративная почта», «VPN-доступ»; это верхний уровень, под которым висят аппаратные и программные зависимости.

Принтеры на USB и «пользователи» как CI - решили не тащить. Для клиента с таким масштабом это мусор, а не полезная информация.

Третья-четвёртая неделя - связи и наполнение. Вот здесь и ушло большинство времени. OCS автоматически дал инвентарь железа и ПО, но связи между CI - кто от кого зависит - нужно проставлять руками или через импорт из документации. Мы шли по-другому: брали каждый сервисный CI сверху вниз и прописывали цепочку. «Корпоративная почта» - Exchange 2007 - сервер с такими-то характеристиками - СХД - сетевой коммутатор в серверной.

После двух недель такой работы большинство критичных зависимостей было в базе. Периферийные вещи - рабочие станции, принтеры - заполнились сами через OCS, но связи там минимальные.

Что получили

Когда всё встало на место, в GLPI мы увидели то, чего у клиента раньше не было: по любому инциденту можно открыть связанный CI и посмотреть, что ещё от него зависит. Это не магия, но это работает. Когда упал один из серверов хранения, дежурный инженер за две минуты понял, какие сервисы затронуты - просто открыл CI в GLPI и прошёлся по связям вверх.

История изменений тоже заработала: RFC из нашего процесса Change Management теперь привязаны к конкретным CI. Видно, что на этом сервере за последние три месяца менялось, кто менял, когда. Раньше это надо было откапывать из переписки в почте или спрашивать у инженера по памяти.

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

Что оказалось сложнее, чем думали

Поддерживать CMDB актуальной - это отдельный процесс, не разовая работа. OCS обновляет аппаратный инвентарь при каждом сканировании, но программные изменения и ручные правки - ответственность инженеров. Нам пришлось договориться: любое изменение в инфраструктуре, которое отражается в RFC, обязательно обновляет и CI в GLPI. Звучит очевидно - до первого закрытого тикета, после которого база осталась устаревшей.

Ещё момент - глубина связей. Затащить в GLPI всё до последнего кабеля теоретически можно, практически - бессмысленно. Где провести границу, каждая команда решает сама. Мы остановились на том уровне, где связи реально влияют на диагностику инцидентов.

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