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

Автодискаверинг отлично справляется с обнаружением того, что уже подключено к инфраструктуре. Но он ничего не знает о том, что происходило с активом до этого момента: кто его заказал, на каком основании он закупался, кто несёт за него ответственность, и должен ли он вообще быть в продуктиве. Без чёткого процесса ввода в эксплуатацию инструмент обнаружения превращается в подсветку проблемы, а не в её решение, компания просто быстрее узнаёт о том, что в инфраструктуре накопились «ничьи» серверы и забытые тестовые стенды.

Именно поэтому при внедрении автодискаверинга мы всегда начинаем не с настройки сканирования, а с регламента: кто инициирует ввод конфигурационной единицы (КЕ), кто её закупает, принимает, настраивает и кто отвечает за то, чтобы запись в CMDB появилась вовремя и с корректными атрибутами. Делимся регламентом, который мы разработали в рамках одного из таких проектов - он прошёл обкатку на реальном внедрении и готов для использования в качестве шаблона.

Зачем нужен формальный процесс, если есть инструмент обнаружения

Распространённая ошибка - рассматривать CMDB и инструмент дискавери как взаимозаменяемые вещи. На деле они закрывают разные задачи.

CMDB - это база данных об активах с атрибутами, связями и зонами ответственности, которая используется в операционных и управленческих процессах: инцидент-менеджменте, планировании изменений, аудите, бюджетировании, контроле безопасности. Чтобы этим данным можно было доверять, ввод каждой записи должен проходить через контролируемый процесс. От инициации потребности до подтверждения, что актив действительно работает так, как заявлено.

Инструмент автодискаверинга, в нашем случае - Device42, закрывает другую часть задачи: он находит активы в инфраструктуре и предоставляет фактические данные о них - конфигурацию, сетевые связи, зависимости между сервисами. Ценность дискавери раскрывается в полной мере именно тогда, когда есть с чем его данные сверять, то есть когда в CMDB уже существует предварительная запись, созданная в рамках регламентированного процесса. Тогда обнаружение превращается из источника хаоса в инструмент валидации: «мы ожидали увидеть в инфраструктуре именно это - и дискавери подтверждает, что так оно и есть».

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

Где в этом процессе работает инструмент дискаверинга - Device42 или BMC Discovery

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

Device42 и BMC Discovery bзакрываю.т именно эту точку - этап 5.5, ввод в эксплуатацию. После того как КЕ физически подключена к инфраструктуре, Device42 обнаруживает её автоматически: собирает атрибуты, сетевые связи, зависимости с другими сервисами. Это обнаруженное состояние сопоставляется с записью, которая уже была создана в CMDB на более раннем этапе процесса (5.4, регистрация на складе).

Именно из этого сопоставления складывается ценность связки «регламент + дискавери»:

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

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

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

‍