Строим CMDB: баланс

желаний и возможностей
Антон Лыков, консультант

10 ноября 2016 года

Содержание

– Разберёмся с терминами
– Как обычно строят CMDB
– Какие проблемы возникают при этом
– Рациональный подход к построению CMDB

2
CMS и CMDB

ITIL Service Transition, 2011 Edition

3
РСМ, СРМ, ФРМ и т. д.

Модель услуги обеспечивает прозрачность ИТ-услуги

Концептуальная Логическая Физическая

модель услуги модель услуги модель услуги

– Потребность – ИТ-проект – Событие

– Политика – Требование – Инцидент
– Портфель – Релиз – Изменение

От стратегии От требований От запроса От обнаружения

к портфелю к развёртыванию к выполнению к исправлению

Бизнес Архитектор Офис Разработчики Тестировщики ИТ-инженеры ИТ-эксплуатация Пользователи

управления
По мотивам IT4IT Reference Architecture
проектами

– Услугу нужно моделировать

– На разных этапах жизненного цикла и разным людям важны разные срезы
этой модели (на самом деле, разные КЕ, их атрибуты и связи)

4
Как обычно строят CMDB

– «КЕ – это то, что может сломаться независимо. Давайте учитывать каждый
порт в коммутаторе как КЕ, ведь он может сломаться»
– «Переходник может быть очень дорогой, поэтому давайте его учитывать»
– «Нужно, чтобы CMS на основании имеющихся там данных считала
себестоимость услуг»
– «Я ставлю задачу по наполнению CMDB – а кто её будет выполнять, это
не мой вопрос»
– «Мы забьём всё руками, это дешевле»

– Данные в CMDB неактуальны или отсутствуют вовсе

– А если данные и есть, то непонятно, приносят ли они пользу
– Зато совершенно точно вся эта ситуация приносит разочарование

5
Рациональный подход

– Исходим только из реальных потребностей

– У каждой категории КЕ, атрибута, связи должен быть потребитель («заказчик»)
– Если данные никому не нужны, им не место в CMDB
– Если данные (категория КЕ, атрибут, связь) нужны только одному потребителю (роли,
подразделению), который может получить их из системы-источника, и не находятся
под контролем процесса Управления изменениями, им не место в CMDB
– Максимально персонализированная ответственность за наполнение
CMDB
– Для каждого атрибута и связи должен быть определён источник информации (смежная
система, либо ручное обновление)
– Для каждого атрибута и связи должен быть составлен план наполнения данными,
определены исполнители этого плана, и этот план должен выполняться
– Данные в CMDB должны быть актуальны
– Если вы не можете быть уверены в актуальности данных, им не место в CMDB
– Сразу думаем о представлении информации
– Поскольку разным потребителям нужны разные срезы CMDB, сразу понимаем, как и
кому что показывать

6
Рациональный подход

– Все эти возможности должны поддерживаться как процессом,

так и средствами автоматизации
– Изменение структуры CMDB должно быть частью процесса,
а не требовать корректировки процесса

7
Руководящие принципы ITIL Practitioner

8
Спасибо