NexTool Solutions

Инвентаризация отвечает на вопрос «что у меня есть». CMDB отвечает на вопрос «что упадёт вместе, если это откажет». Мостом между ними в GLPI служит не вкладка «Соединения», как многие полагают, а анализ влияния — и именно здесь застревает большинство проектов CMDB. В этом руководстве показаны четыре механизма связей, которые предлагает GLPI, какой из них использовать в каждом случае, и запросы, которые мы выполняем при сопровождении, чтобы найти «слепой» CMDB.

Инвентаризация и CMDB: разница, которая меняет реагирование на инциденты

Инвентаризация — это учёт: марка, модель, серийный номер, гарантия, ответственный. Это имущественный контроль, и с него начинают все: с автоматической инвентаризацией через GLPI Agent вы заполняете сотни активов за несколько дней. CMDB — то, что идёт дальше: слой связей, отвечающий на вопрос, который важен посреди инцидента: если этот коммутатор упадёт, какие серверы, сервисы и пользователи остановятся вместе с ним?

Типичная стратегическая ошибка — относиться к CMDB как к «более подробной инвентаризации» и пытаться заполнить связи для всего. Это не масштабируется, и никто это не поддерживает. Хороший CMDB компактен: только критичные CI и зависимости, которые вы действительно использовали бы при анализе влияния.

Четыре механизма связей в GLPI

В GLPI нет единого «поля связи» — есть четыре разных механизма, каждый в своей таблице, и неправильный выбор — корень большинства неработающих CMDB. При сопровождении ошибка номер 1 — строить всё на вкладке «Соединения», считая её CMDB, а потом обнаружить, что анализ влияния пуст.

Соединения и сетевые порты моделируют физическое подключение. «Приложения» группируют инфраструктуру сервиса. А анализ влияния — единственный направленный механизм — это граф зависимостей, который действительно отвечает на вопрос «что упадёт вместе». Все четыре сосуществуют; путаница возникает, когда от одного ждут работы другого.

Смоделируйте сервис как CI: «Приложения» (Appliances)

Шаг, которого не хватает большинству инвентаризаций, — дать сервису существование. «Почта», «ERP», «Клиентский портал» — это не оборудование, а сервисы, работающие поверх оборудования. В GLPI правильный объект для этого — «Приложение» (Appliances, меню «Активы»), доступное начиная с GLPI 9.5. Приложение — это логический CI, к которому вы привязываете поддерживающие его объекты:

1. Создайте приложение (например, «Email Service»).
2. На вкладке связанных элементов привяжите поддерживающие CI: сервер, коммутатор ядра, хранилище, интернет-канал. Это записывается в glpi_appliances_items.
3. Укажите технического ответственного, договор поддержки и поставщика прямо в приложении.

С этого момента сервис существует как объект, доступный для запросов: вы открываете «Email Service» и видите список поддерживающей его инфраструктуры, не полагаясь на чью-то память.

Настоящий CMDB: анализ влияния

Группировка инфраструктуры в приложении говорит, кто что поддерживает, но не рассчитывает радиус влияния сбоя. Это работа вкладки «Анализ влияния» (есть начиная с GLPI 9.4), которая строит направленный граф зависимостей и записывается в glpi_impactrelations. У каждого ребра есть источник и цель: itemtype_source, items_id_source влияет на itemtype_impacted, items_id_impacted.

Направление — та деталь, которая отличает понимающих от тех, кто просто перетаскивал квадратики. Ребро от коммутатора к серверу означает «коммутатор влияет на сервер». Когда коммутатор падает, вы идёте по стрелкам вперёд и видите всё, что останавливается вместе с ним. Типичная ошибка — нарисовать стрелку наоборот, указав, что сервер влияет на коммутатор, и тогда анализ влияния упавшего коммутатора окажется пустым — именно тогда, когда он нужнее всего. Всегда моделируйте по направлению потока зависимостей: от базовой инфраструктуры к сервису наверху.

Практическое предостережение: граф отрисовывается в браузере и замедляется при сотнях узлов. Не пытайтесь нарисовать весь парк. Используйте бизнес-критичность (выпадающий список «Критичность» в разделе Настройки > Выпадающие списки), чтобы отметить критичные CI, и помещайте в граф только их. Перегруженный CMDB — заброшенный CMDB.

Диагностический SQL: поиск «слепого» CMDB

В начале договора на сопровождение, ещё до обсуждения процессов, мы проводим аудит покрытия: какие критичные CI есть в инвентаризации, но не входят ни в одну связь влияния. Это точки, где анализ влияния будет лгать, сообщая «ничего не затронуто», хотя на самом деле этого просто никто не смоделировал. Запрос выводит компьютеры без единого ребра — ни как источник, ни как цель:

-- Computers with NO impact relation at all:
-- they exist in the inventory but are invisible to impact analysis.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
       ON (r.itemtype_source   = 'Computer' AND r.items_id_source   = c.id)
       OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
  AND r.id IS NULL
ORDER BY c.name;

И обратная сторона: для сервиса, смоделированного как приложение, — какие CI он объединяет. Полезно, чтобы убедиться, что «Email Service» действительно указывает на правильные сервер и коммутатор, прежде чем полагаться на него ночью во время инцидента:

-- Items supporting a specific Appliance (service):
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Email Service';

Мы выполняем эти два запроса прямо в базе данных (через SQL-клиент только для чтения), а не через LIKE в интерфейсе, потому что нам нужно точное число «сирот», чтобы оценить объём работ по моделированию.

Автоматическое обнаружение не построит CMDB за вас

Стоит развеять ожидание, которое возникает в каждом проекте: сетевая инвентаризация через SNMP обнаруживает физические соединения — если GLPI Agent сканирует коммутаторы по SNMP и включён LLDP/CDP, сетевые порты между коммутатором и хостом заполняются сами в glpi_networkports_networkports. Это отлично, и делать это вручную не нужно. Но логическую зависимость сервиса — «почта зависит от этого сервера» — не обнаруживает ни один протокол. Агент не знает, что этот процесс Exchange — ваш критичный почтовый сервис. Этот слой всегда остаётся решением человека, и именно он превращает инвентаризацию в CMDB.

Поддерживайте граф актуальным, иначе он лжёт

Устаревший CMDB хуже отсутствующего: он даёт ложную уверенность. Вы меняете коммутатор, забываете обновить связь, и при следующем сбое анализ влияния указывает на оборудование, которого уже нет. Привяжите поддержку графа к процессу управления изменениями — каждое изменение критичного CI должно пересматривать его связи влияния до закрытия. Без этой дисциплины граф устаревает за недели. Это тот же принцип, что и в базе знаний: связь, которую никто не поддерживает, превращается в шум.

Нужен CMDB в GLPI, который действительно поддерживает анализ влияния, с графом, смоделированным на правильных CI и обновляемым вместе с изменениями? Узнайте о сопровождении GLPI от NexTool.

Проверено командой NexTool Solutions.