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