CMDB - Configuration management database - База данных управления конфигурациями.
Определение 1:
Forrester Research определяет CMDB как «фундаментальный компонент модели ITIL, который обеспечивает унифицированный репозитарий конфигурационных единиц (Configuration Item, CI) — любых системных компонентов вместе с их конфигурационными атрибутами — и описывает зависимости между ними».
Определение 2:
К основным функциям CMDB в соответствии с ITIL относятся: хранение информации по объектам ИТ-инфраструктуры в форме конфигурационных единиц (КЕ); поддержка связей между КЕ, связей КЕ с инцидентами, проблемами, изменениями и релизами; контроль версий КЕ; поддержка «базовых линий» КЕ и «снимков состояния» CMDB.
CMDB является важным инструментом для управления конфигурациями. Этот процесс преследует следующие цели:
Конфигурационный элемент - это отдельный экземпляр объекта, являющийся частью среды
и обладающий характерными изменяемыми атрибутами. Эти объекты могут быть физическими (например, компьютерная система), логическими (например, установленная копия программного обеспечения) или концептуальными (например, бизнес-услуги). Но
они должны быть непосредственной частью среды, а не информацией об этой части.
Конфигурационные элементы существуют не в вакууме, они влияют друг на друга. Например, один конфигурационный элемент может использовать другой элемент, зависеть от него, быть его компонентом, запускать его, быть его членом или может быть расположен в нем - это всего лишь несколько примеров. Наличие данных о таких взаимосвязях в CMDB позволяет наблюдать за взаимодействием и влиянием конфигурационных элементов друг на друга.
Существует множество различных типов конфигурационных элементов - от компьютерных систем до сетевого оборудования и серверного ПО. Без модели данных, точно отражающей эти типы и типы возможных взаимосвязей между ними, существует вероятность того,
что в CMDB будут храниться атрибуты, не относящиеся к конфигурационным элементам, а необходимые атрибуты будут отсутствовать, что усложнит поиск групп конфигурационных элементов. Такая модель данных должна быть как объектно-ориентированной, так и
расширяемой.
Объектно-ориентированная модель В объектно-ориентированной модели данные иерархически выстроены по классам, и каждый класс наследует атрибуты своего суперкласса (т.е. класса более высокого уровня в иерархии) и добавляет собственные атрибуты для
создания более специфичного типа объекта, т.е. подкласса. Подклассы могут иметь собственные подклассы, продолжая иерархию до любого уровня детализации, которую
необходимо отследить.
Расширяемая модель
Ваша инфраструктура и технология, на которой она построена, постоянно изменяются. Это означает, что типы конфигурационных элементов и взаимосвязи в CMDB должны также изменяться, поэтому возникает необходимость в расширяемой модели данных. Необходимо
иметь возможность добавлять и удалять атрибуты из классов и даже добавлять и удалять классы.
Составляю структуру CMDB следует понимать задачи, для которых внедряется управление конфигурациями. Возможные варианты:
Установление обоснованного уровня точности, т.е. корреляции между моделью и реальной конфигурацией.
Решить данную задачу нелегко, потому что здесь нужно верно решить уравнение с несколькими неизвестными:
При всех итерациях необходимо определять ресурсы, необходимые для поддержки данных CMDB в актуальном состоянии. Наличие (отсутствие) таких ресурсов является критически важным.
ITIL выделяет 5 уровней зрелости для существующих процессов. Первые два можно охарактеризовать, как "бардак". А вот дальше идут:
3 уровень стандартизированные и документированные процессы
4 уровень управляемые и измеряемые процессы
Как раз на 1-2 уровне зрелости CMDB ничего не даст. А вот при переходе с 3 на 4 и тем более с 4 на 5 она будет работать так, как задумывалось - для этого в компании уже будут созданы все необходимые условия.
Источники:
Определение 1:
Forrester Research определяет CMDB как «фундаментальный компонент модели ITIL, который обеспечивает унифицированный репозитарий конфигурационных единиц (Configuration Item, CI) — любых системных компонентов вместе с их конфигурационными атрибутами — и описывает зависимости между ними».
Определение 2:
К основным функциям CMDB в соответствии с ITIL относятся: хранение информации по объектам ИТ-инфраструктуры в форме конфигурационных единиц (КЕ); поддержка связей между КЕ, связей КЕ с инцидентами, проблемами, изменениями и релизами; контроль версий КЕ; поддержка «базовых линий» КЕ и «снимков состояния» CMDB.
CMDB является важным инструментом для управления конфигурациями. Этот процесс преследует следующие цели:
- учет всех ИТ-активов и конфигураций в рамках организации и её услуг;
- предоставление точной информации о конфигурациях и документации для поддержки всех прочих процессов управления услугами;
- предоставление устойчивой основы для управления инцидентами, проблемами, изменениями и релизами;
- сверка конфигурационных записей с инфраструктурой и устранение расхождений.
Конфигурационный элемент - это отдельный экземпляр объекта, являющийся частью среды
и обладающий характерными изменяемыми атрибутами. Эти объекты могут быть физическими (например, компьютерная система), логическими (например, установленная копия программного обеспечения) или концептуальными (например, бизнес-услуги). Но
они должны быть непосредственной частью среды, а не информацией об этой части.
Конфигурационные элементы существуют не в вакууме, они влияют друг на друга. Например, один конфигурационный элемент может использовать другой элемент, зависеть от него, быть его компонентом, запускать его, быть его членом или может быть расположен в нем - это всего лишь несколько примеров. Наличие данных о таких взаимосвязях в CMDB позволяет наблюдать за взаимодействием и влиянием конфигурационных элементов друг на друга.
Существует множество различных типов конфигурационных элементов - от компьютерных систем до сетевого оборудования и серверного ПО. Без модели данных, точно отражающей эти типы и типы возможных взаимосвязей между ними, существует вероятность того,
что в CMDB будут храниться атрибуты, не относящиеся к конфигурационным элементам, а необходимые атрибуты будут отсутствовать, что усложнит поиск групп конфигурационных элементов. Такая модель данных должна быть как объектно-ориентированной, так и
расширяемой.
Объектно-ориентированная модель В объектно-ориентированной модели данные иерархически выстроены по классам, и каждый класс наследует атрибуты своего суперкласса (т.е. класса более высокого уровня в иерархии) и добавляет собственные атрибуты для
создания более специфичного типа объекта, т.е. подкласса. Подклассы могут иметь собственные подклассы, продолжая иерархию до любого уровня детализации, которую
необходимо отследить.
Расширяемая модель
Ваша инфраструктура и технология, на которой она построена, постоянно изменяются. Это означает, что типы конфигурационных элементов и взаимосвязи в CMDB должны также изменяться, поэтому возникает необходимость в расширяемой модели данных. Необходимо
иметь возможность добавлять и удалять атрибуты из классов и даже добавлять и удалять классы.
Составляю структуру CMDB следует понимать задачи, для которых внедряется управление конфигурациями. Возможные варианты:
- Установление контроля над основными элементами ИТ инфраструктуры, определение связей как между частями ИТ инфраструктуры, так и между ними и основными бизнес сервисами для проведения критичных для бизнеса изменений
- Учет ценных активов, контроль сохранности, поддержка требований по безопасности, интеграция с системами мониторинга
- Оперативная и точная инвентаризация ИТ активов по запросам бухгалтерии
- Лицензионный контроль ПО
Установление обоснованного уровня точности, т.е. корреляции между моделью и реальной конфигурацией.
Решить данную задачу нелегко, потому что здесь нужно верно решить уравнение с несколькими неизвестными:
- Определить охват CMDB – например, что будет CI, какие будут категории CI?
- Определить уровень детализации - например, какие атрибуты будут у CI, что будет только атрибутом, а что – достойно быть настоящей CI?
- Определить необходимые связи как между CI, так и между CI и сущностями - например, между CI и сервисами, между CI и инцидентами, проблемами, RFC, релизами.
- Добавление в CMDB данных, которые были нужны потребителям, но которых не оказалось в CMDB
- Удаление из CMDB данных, которые не были востребованы потребителями базы
- Изменение (расширение) охвата категорий CI, например, в результате изменения политик процесса по охвату
При всех итерациях необходимо определять ресурсы, необходимые для поддержки данных CMDB в актуальном состоянии. Наличие (отсутствие) таких ресурсов является критически важным.
ITIL выделяет 5 уровней зрелости для существующих процессов. Первые два можно охарактеризовать, как "бардак". А вот дальше идут:
3 уровень стандартизированные и документированные процессы
4 уровень управляемые и измеряемые процессы
Как раз на 1-2 уровне зрелости CMDB ничего не даст. А вот при переходе с 3 на 4 и тем более с 4 на 5 она будет работать так, как задумывалось - для этого в компании уже будут созданы все необходимые условия.
Источники:
- http://documents.bmc.com/products/documents/49/77/64977/64977.pdf
- http://www.itexpert.ru/rus/ITEMS/77-31/
- http://smartsourcing.ru/blogs/upravlenie_it-aktivami/274
Комментариев нет:
Отправить комментарий