Как стать автором
Обновить

CMDB в ИТ-мониторинге или как устранять инциденты в 3 раза быстрей

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров1.8K
Всего голосов 12: ↑12 и ↓0+18
Комментарии4

Комментарии 4

Как все это не работало у Mercury в 2006м, так и сейчас не работает кмк.

В 2006м поэтому что все время внедренцев тратилось на глюки софта, дискаверинга и правила, мать их, реконсиляции КЕ.

Сейчас - потому что кубер и попробуй его отдискаверить, когда за час тыща контейнеров поднимется и помрёт.

Cmdb всегда отстаёт от реальной жизни, а потому почти бесполезна, а содержать дорого.

Это называется «посмертная» cmdb, конечно такая не нужна. Нужен процесс непрерывного дискаверинга и автоматизация в правде. А тот же кубер со всеми сущностями и поды держать в cmdb весь не надо, нужен разумный уровень этой правды.

"посмертная" cmdb это прям в яблочко

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

CMDB без процессов - это лопата без землекопа.

Таким макаром можно мониторить что-то исключительно однотипное и локально расположенное - ЦОД, например. В случаях "мониторинг инфраструктуры компаний холдинга с общим числом работников более 100к в более чем 11 часовых поясах" этой CMDB можно подтереться, сама по себе она - ноль без палочки

Зарегистрируйтесь на Хабре, чтобы оставить комментарий