Почему ваша база данных серверов устарела ещe до того, как вы еe открыли

Представьте: в CMDB числится сервер. Выделенные ресурсы, привязка к сервису, ответственный — все по регламенту. Только этот сервер вы выключили восемь месяцев назад во время миграции. Запись никто не обновил. Строку никто не удалил. А неработающий сервер тем временем сидит в отчетах, участвует в расчете лицензий, съедает бюджет на поддержку и искажает Capacity Planning. И таких серверов в вашей инфраструктуре могут быть десятки. Разбираемся, почему уже через полгода после «успешного» внедрения ITSM до 30% записей в базе — это мертвые души.

Содержание

Почему «просто завести CMDB» не работает

Вы внедрили ITSM-систему, настроили формы, назначили ответственных — кажется, что порядок наведен. На практике уже через три месяца база расходится с инфраструктурой. И дело не в инструменте. Дело в том, что перед стартом никто не ответил на вопрос «что у нас есть». Не «что должно быть по регламенту» и не «что записано в акте приемки». А что реально отвечает в сети и потребляет ресурсы.

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

Зомби: записи без объектов

Сервер выведен из эксплуатации. Виртуалка удалена. Коммутатор утилизирован. А строка в CMDB живет. Обновляется по инерции, попадает в отчеты, фигурирует в аудитах. Это и есть зомби — запись, за которой нет реального объекта.

Зомби не просто занимают место в таблице. Они завышают стоимость владения инфраструктурой, искажают данные для лицензирования и продления контрактов, создают ложное ощущение резерва при планировании мощностей и тратят время инженеров на «обслуживание» того, чего не существует.

Чем дольше зомби не обнаружен, тем дороже обходится его существование.

Тени: объекты без записей

Тестовый стенд подняли «на пару дней» и забыли. Подрядчик развернул временный сервер и ушел, не сдав доступы. В облаке появился инстанс, который никто не внес в реестр.

Это тени — объекты, которые работают, но не отражены ни в одном учете. Они потребляют вычислительные ресурсы и лицензионные слоты, открывают незакрытые уязвимости, о которых не знает служба безопасности, ломают расчеты нагрузки и планирование отказоустойчивости. И самое неприятное: вы не узнаете о существовании тени, пока она не станет участником инцидента.

Почему расхождение неизбежно — и что с этим делать

Инфраструктура живая. Виртуалки создаются и удаляются ежедневно. Подрядчики приходят и уходят. Облачные инстансы множатся. Без регулярной автоматической сверки расхождение накапливается незаметно.

Хорошая новость: чтобы увидеть реальную картину, достаточно одного цикла сетевого опроса. На вебинаре 19 августа Андрей Рассамакин, генеральный директор компании «ИнфраМенеджер», покажет, как за 4 недели превратить CMDB из кладбища данных в реально работающий инструмент.

Мы загрузим перечень серверов в «ИнфраМенеджер», запустим опрос по сети и сравним результаты. Вы увидите, какие серверы мертвы, какие актуальны, и какие «теневые» устройства работают в сети, но отсутствуют в CMDB.

Ждем всех, кто устал от неактуальных данных, потери контроля над инфраструктурой и споров по цифрам на каждом совещании.

19 августа в 11:00 (мск)

Регистрация доступна по ссылке

29

Время прочтения:

4 минуты