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

Давайте попробуем перечислить какая конфигурационная информация нужна, когда мы касаемся вопросов эксплуатации ИТ.

  1. Учетная информация об оборудовании и ПО - нужна практически всем, кто связан с вопросами эксплуатации ИТ. При этом в сопровождении этой учетной информации могут быть разны требования:
  • Специалистам на местах нужна подробная спецификация оборудования и ПО, и желательно чтобы эта информация обновлялась автоматически, т.е. это может быть БД средств дискаверинга
  • Специалистам-руководителям нужна информация о параметрах жизненного цикла: в ремонте, срок гарантии, периоды обслуживания, история перемещении, ответственные за эксплуатацию и т.д.
  • ИТ финансистам нужны стоимостные параметры и сроки амортизации.

Следует отметить, что эта информация является наиболее важной частью CMDB или БД учета активов, поскольку с ней работают практически все сотрудники, вовлеченные в эксплуатацию ИТ.

  1. Информация о связях, например типа "ресурс-сервис". В качестве сервиса регистрируется логический элемент, который должен иметь связи с оборудованием, ПО, другими логическими элементами и эта информация используется специалистами на местах при решении задач мониторинга, формирования планов аварийного восстановления, анализа конфигураций систем и зависимостей элементов при проведении изменений.
  2. Информация о кабельных подключениях. Отдельная область в эксплуатации ИТ, которая традиционно слабо автоматизируема, плохо связана с первыми двумя пунктами
  3. Информация о планах помещений и размещении в нем оборудования.
  4. Информация о ТЛК ресурсе. Обычно, как и кабельные подключения, для ведения TCP/IP сетей, или учета полосы канала используются отдельные решения.

Практика показывает, что данные по п.п.3-5 нужны только специалистам ИТ, эти данные не нужны в ERP системах предприятия, они не учитываются в качестве балансовых материальных средств и хранятся и сопровождаются только в ИТ-подразделениях. Если мы захотим учитывать данные по электрическому обеспечению и климату, от которых сильно зависит состояния ИТ элементов, то можно обнаружить еще несколько слоев учетной информации, которую желательно засунуть в конфигурационную базу данных.

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

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

Традиционное решение этих проблем - разумная декомпозиция данных между несколькими конфигурационными база данных, с обязательной автоматизацией по синхронизации наборов данных между базами (см. статью о Типах конфигурационных данных - интегрированная БД).

Покажем такую декомпозицию на примере двух платформ FNT Software и BMC Atrium CMDB.

Представим декомпозизицию для модели TMN, она удобна для понимания места и роли каждого элемента. Конечно, это декомпозиция является одним из вариантов, но он показывает сильные стороны каждой CMDB. CMDB на платформе FNT Command показана в качетсве основной (Core) для элементов нижнего уровня модели TMN, а для задач мониторинга, SALM, Contract Management используем возможности BMC Asset Management и BMC Atrium CMDB. БД систем ERP и дискаверинга обычно дополняют картину.

PICTURE1

Теперь представим схему, в которой обозначим смежные процессы управления (инциденты, изменения, мониторинга).

PICTURE2

БД FNT Command служит в качетсве корпоративной федеральной fCMDB, в которой хранится информация о состоянии ИТ ресурсов. Это оправданно, поскольку в этой же системе (FNT command) реализованы функции OSS/BSS, что позволяет осуществлять планирование изменений легко и наглядно на схемам FNT. Федеративная CMDB раздает данные смежной CMDB (показана на платформе BMC Atrium CMDB), которая используется для систем управления (процессы управления инцидентами, мониторинга). Эта же CMDB принимает результаты дискаверинга и изменения состояний КЭ, проводя очистку данных (процедуру реконсиляции).

Данный подход не является единственным, но, он хорошо сопровождаем, не содержит конфликтов зон ответсвенности, позволяет поделить использование данных между разными системами. В тоже время, такой состав CMDB работает как единая CMDB компании.