При построении корпоративной CMDB часто сталкиваются с проблемой большого количества источников информации, баз данных, из которых необходимо создать корпоративное конфигурационное хранилище. Часто при построении CMDB наиболее сложными становятся вопросы в каких БД что вести, насколько подробно и как сделать удобным сопровождение данных. Попытаемся разобраться с этими вопросами.
Давайте попробуем перечислить какая конфигурационная информация нужна, когда мы касаемся вопросов эксплуатации ИТ.
Следует отметить, что эта информация является наиболее важной частью CMDB или БД учета активов, поскольку с ней работают практически все сотрудники, вовлеченные в эксплуатацию ИТ.
Практика показывает, что данные по п.п.3-5 нужны только специалистам ИТ, эти данные не нужны в ERP системах предприятия, они не учитываются в качестве балансовых материальных средств и хранятся и сопровождаются только в ИТ-подразделениях. Если мы захотим учитывать данные по электрическому обеспечению и климату, от которых сильно зависит состояния ИТ элементов, то можно обнаружить еще несколько слоев учетной информации, которую желательно засунуть в конфигурационную базу данных.
Напомним, что CMDB отличается от простой учетной системы тем, что может сопровождать состояние не только материальных объектов, но и логические элементы и самое главное, связывать их различными связями - по принадлежности, по влиянию, по вхождению, по ответственным и т.д. Такая гибкость нужна в основном при анализе и поиске ошибок, а также при выполнении изменений, поскольку позволяет ничего и никого не забыть и это удобный и гибкий способ вести различные срезы конфигураций элементов для различных областей ИТ.
Понятно, что для учетных систем такая гибкость не нужна, более того состав объектов (классов) и соства атрибутов каждого класса строго определены, и то, что в CMDB строится на связях, в учетных системах может быть в составе атрибутов объекта. Отсюда возникает причины несовместимости учетных систем с CMDB и желание каждого подразделения иметь что-то свое "родное", со стойким отвращением к необходимости сопровождения информации в CMDB.
Традиционное решение этих проблем - разумная декомпозиция данных между несколькими конфигурационными база данных, с обязательной автоматизацией по синхронизации наборов данных между базами (см. статью о Типах конфигурационных данных - интегрированная БД).
Представим декомпозизицию для модели TMN, она удобна для понимания места и роли каждого элемента. Конечно, это декомпозиция является одним из вариантов, но он показывает сильные стороны каждой CMDB. CMDB на платформе FNT Command показана в качетсве основной (Core) для элементов нижнего уровня модели TMN, а для задач мониторинга, SALM, Contract Management используем возможности BMC Asset Management и BMC Atrium CMDB. БД систем ERP и дискаверинга обычно дополняют картину.
Теперь представим схему, в которой обозначим смежные процессы управления (инциденты, изменения, мониторинга).
БД FNT Command служит в качетсве корпоративной федеральной fCMDB, в которой хранится информация о состоянии ИТ ресурсов. Это оправданно, поскольку в этой же системе (FNT command) реализованы функции OSS/BSS, что позволяет осуществлять планирование изменений легко и наглядно на схемам FNT. Федеративная CMDB раздает данные смежной CMDB (показана на платформе BMC Atrium CMDB), которая используется для систем управления (процессы управления инцидентами, мониторинга). Эта же CMDB принимает результаты дискаверинга и изменения состояний КЭ, проводя очистку данных (процедуру реконсиляции).
Данный подход не является единственным, но, он хорошо сопровождаем, не содержит конфликтов зон ответсвенности, позволяет поделить использование данных между разными системами. В тоже время, такой состав CMDB работает как единая CMDB компании.
Чтобы связаться с нами Вы можете воспользоваться формой для отправки сообщений, расположенной ниже.