Портал №1 по управлению цифровыми
и информационными технологиями

CMDB: как совместить детальность и наглядность?

Василий занят построением CMDB. И вот какой у него возник вопрос:

У нас в компании со временем устоялась трехуровневая модель предоставления ИТ-сервисов бизнесу.

1. Уровень бизнес-сервисов (бизнес-направления или бизнес-процессы).

2. Уровень ИТ-сервисов прикладного уровня (ИТ-сервисы, связанные с прикладным ПО и автоматизированными банковскими системами).

3. Уровень ИТ-сервисов системного уровня (ИТ-сервисы, связанные с системным ПО (например, СУБД, прокси) и сетью).

Получается, что, с одной стороны, у нас есть связь сервисов между собой, т.е. бизнес-сервисы зависят от ИТ-сервисов прикладного уровня, а ИТ-сервисы прикладного уровня зависят от ИТ-сервисов системного уровня. Есть заключенные SLA с бизнесом и OLA внутри ДИТ.

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

Так вот, мне не совсем понятно как должна выглядеть модель CMDB в нашем случае.

Предположим, что мы заведем в CMDB CI типа Software, Hardware (ресурсы) и т.д., затем CI типа IT-service Application Level и  IT-service System Level.

Затем выстроим связи между CI типа IT-service и CI типа Software, Hardware. Также связал CI типа IT-service Application Level и и  IT-service System Level через CI типа Software, т.к. сервисы прикладного уровня у нас зависят от сервисов системного уровня.

Тут, на мой взгляд, получится путаница. Например, мы открываем какую-либо CI типа IT-service Application Level и видим кучу связей данной CI с CI типа Software, Hardware и IT-service System Level. При этом CI типа IT-service System Level влияет на множество других CI типа IT-service Application Level.

Вот что у меня получается в Service Manager. Поясню немного. SERVICE-APP-DebtManager состоит из программной CI SW-DebtManager-RFB-PROD. SERVICE-APP-EPIS состоит из программной CI SW-EPIS-PROD. В свою очередь CI SW-DebtManager-RFB-PROD зависит от ИТ-сервисов системного уровня. Аналогично и с  CI SW-EPIS-PROD. Сервисы системного уровня в свою очередь тоже состоят из соответствующих программных и аппаратных CI.

Эта схема лишь только для двух ИТ-сервисов SERVICE-APP-DebtManager и SERVICE-APP-EPIS. При этом уже достаточно сложно разобраться. При добавлении в БД других сервисов, схема связей будет усложняться в геометрической прогрессии.

 Посоветуйте, как правильнее было бы построить модель, чтобы она оставалась наглядной и информативной, но включала в себя все подлежащие учету CI?

Коллеги-менеджеры конфигураций, поделитесь опытом?

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 7

  • Кротов Алексей

    А есть ли значительный смысл разделять ИТ-сервисы прикладного уровня и ИТ-сервисы системного уровня на уровне схемы CMDB? С моей точки зрения, отличия у них только одно – один представлен в бизнес-каталоге, другой – нет. Т.е. файловый сервис может быть, как прикладным уровнем (пользователи работают с шарами; немного передернул, но, надеюсь, некритично, т.к. работают с сетевыми ресурсами), так и системного уровня (шара нужен для функционирования бизнес-приложения).

  • Андрей

    Добрый день!

    На мой взгляд, наглядность отображения информации, хранящейся в CMDB, достигается настройкой для каждого отдельного потребителя информации своего вида/представления/отчетов. Построить модель, которая будет наглядно отображать все связи и КЕ для всех потребителей, как мне кажется, невыполнимая довольно сложная задача. 

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

  • Василий

    Спасибо, уважаемые за ваши комментарии. Идея настроить фильтрацию объектов при выводе на диаграмму связей мне нравится. Возможно, кто-то из вас имел опыт настройки подобных вещей в HP Service Manager 7.11?

     

    • Pavel Solopov

      В SM не пробовал, а вот в UCMDB, который теоретически идёт в комплекте с SM пробовал что-то подобное делать, хотя не скажу, что это задача из самых тревиальных, но если понять принцип, то и не самая сложная.

  • Pavel Solopov

    Ещё вот что хотелось бы сказать. У меня есть ощущение, что вы стали заложниками вами же придуманных условностей.

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

    Хотя, возможно, я не знаю какую-то специфицескую особенность вашей ситуации или у вас есть иные, кроме выше названной цели.

  • Андрей

    Коллеги,

    кто нибудь может внятно объяснить, зачем стоит заводить в CMDB CI типа "Услуга" ?  

    Рассмотрим случай, когда в информационной системе есть сущности типа "услуга" за рамками CMDB (например отдельная папка SLM и отдельная папка CMDB в OMNITRACKER). Понятно, что каждая CI должна быть связана с услугой, но для этого не обязательно связывать СI типа "сервер" с CI типа "услуга". Проставили в карточке CI в поле услуга нужную услугу и все. На деле же часто вижу примеры CMDB как дерево CI-ев, где есть CI в традиционном понимании (ПО, Железо, конфигурации серверов и тд) и CI типа "услуга". Есть ли ответ на мой вопрос, отличный от "а зависит от важего желания, инструментария etc"? 🙂


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM