Как правильно подойти к вопросу построения корпоративной CMDB

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

Почему CMDB

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

Цели

Согласно руководству по поддержке услуг, основанных на ITIL, управление конфигурациями должно преследовать следующие цели:

  • контроль всех ИТ-активов и конфигураций в рамках организации;
  • предоставление точной информации о конфигурациях и документации для поддержки всех прочих процессов управления услугами
  • предоставление устойчивой основы для управления инцидентами, проблемами, изменениями и релизами
  • сверка конфигурационных записей с инфраструктурой и устранение расхождений

Достижение этих целей позволяет организации эффективно осуществлять управление, интеграцию и поддержку принятия решений. В частности:

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

Данные это ключевой фактор

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

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

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

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

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

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

PICTURE1

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

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

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

PICTURE2

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

Не так давно поставщики предлагали единую, всеобъемлющую CMDB для хранения конфигурационных данных, доступную для всех приложений, которым необходимы эти данные.

PICTURE3

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

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

Рекомендованный подход к созданию и применению CMDB

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

Содержимое CMDB согласно ITIL

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

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

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

Взаимосвязи между конфигурационными элементами

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

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

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

Смежные данные

К конфигурационным элементам имеет отношение большое количество информации, такой как обращения в службу технической поддержки, события изменений, договоры, соглашения об уровне обслуживания (SLA), библиотека эталонного ПО (DSL) и многое другое. Хотя эти единицы сами по себе не являются конфигурационными элементами, они содержат информацию о конфигурационных элементах и формируют важную часть ИТ-инфраструктуры.

Структура идеальной среды CMDB

CMDB и ее инфраструктура должна быть разделена на 3 уровня.

  1. Это собственно CMDB
  2. Данные, связанные с CMDB ссылками, называемые расширенными данными CMDB
  3. Приложения, взаимодействующие с этими двумя уровнями, называемые средой CMDB
PICTURE4

Уровни «CMDB» и «Расширенные данные CMDB» образуют то, что понимается в ITIL как CMDB. Выделение этих двух уровней отличает интегрированный подход от предложенного подхода.

Уровень "CMDB" содержит только конфигурационные элементы и их взаимосвязи, но некоторые их атрибуты могут быть привязаны через ссылки к расширенным данным CMDB. Не все имеющиеся атрибуты конфигурационных элементов должны храниться в CMDB: Желательно хранить в CMDB только основные атрибуты, а для менее важных использовать расширенные данные CMDB.

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

В расширенных данных CMDB содержатся данные, перечисленные в пункте «Смежные данные» данной статьи, а также другие атрибуты конфигурационных элементов, которые нецелесообразно хранить в CMDB.

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

Например, запись запроса на изменение может иметь ссылку, посредством которой пользователь может получить доступ к экземплярам конфигурационных элементов, подлежащих изменению, а каждый экземпляр конфигурационного элемента может иметь ссылку, через которую пользователь может получить доступ к запросам на его изменение.

Это дает ряд преимуществ:

  • Функциональность CMDB может быть сосредоточена на конфигурационных элементах и их взаимосвязях. Такая функциональность включает в себя формирование разделов для нескольких промежуточных версий, синхронизацию данных из нескольких источников, а также интегрирование данных.
  • Средства, необходимые для обеспечения такой функциональности, не расходуются на ненужные данные. Например, нет необходимости в нескольких промежуточных версиях DSL, поэтому включение DSL в состав CMDB приведет к расходованию ценного пространства хранилища данных.
  • Нет необходимости изменять CMDB для хранения смежных данных. Благодаря разграничению конфигурационных элементов и их взаимосвязей вопрос о необходимости хранения данных нового типа в CMDB уже решен. Они хранятся в составе расширенных данных CMDB. Таким образом, устраняется проблема изменения модели данных в CMDB для внедрения нового типа данных. Такой подход позволяет избежать внутренних ошибок, свойственных процессу сжатия модели данных при перемещении данных из CMDB.
  • Вместо CMDB, переменные данные можно хранить в базах данных, лучше приспособленных для обработки больших объемов запросов
  • Обеспечивается более эффективный доступ к данным. Потребители данных могут получать их из индивидуальных хранилищ данных, оптимизированных для предоставления доступа к запрашиваемым данным определенного типа, вместо получения всех данных из CMDB.

Возможности CMDB

Но даже при правильной структуре для эффективного управления конфигурационными элементами CMDB необходимо следующее:

  1. интеграция данных
  2. гибкая модель данных
  3. декомпозиция конфигураций
  4. синхронизация конфигураций
  5. открытый доступ к данным.

1. Интеграция данных

Под термином «интеграция» подразумеваем хранение некоторых данных непосредственно в центральном репозитории с доступом к данным из других источников по ссылкам.

Некоторые атрибуты можно интегрировать для их отслеживания, но не настолько частого или внимательного, как и ключевые атрибуты конфигурационных элементов. Эти вторичные атрибуты относятся к первому из двух типов данных, которые можно интегрировать. Это означает, например, что запись CMDB о сотруднике может содержать атрибут «Навыки» со списком навыков сотрудника, а также атрибут «Отдел» с названием отдела, в котором работает сотрудник. Эта запись также может быть связана с хранилищем данных о персонале, где хранятся дополнительные атрибуты, не представляющих важности для конфигурации, например, «Заработная плата».

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

2.Гибкая модель данных

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

В объектно-ориентированной модели данные иерархически выстроены по классам, и каждый класс наследует атрибуты своего суперкласса (т.е. класса более высокого уровня в иерархии) и добавляет собственные атрибуты для создания более специфичного типа объекта, т.е. подкласса. Подклассы могут иметь собственные подклассы, продолжая иерархию до любого уровня детализации, которую необходимо отследить.Например, класс «Компьютерная система» может содержать атрибуты «Домен», «Тип процессора» и «Производитель». Класс «Компьютерная система» может содержать подклассы «Ноутбук», «Настольный компьютер» и «Центральная ЭВМ». Каждый из этих подклассов имеет три атрибута своего суперкласса плюс атрибуты, присущие только им. На рис. 6 показана часть объектно-ориентированной модели данных CMDB, включающая суперкласс и подклассы двух уровней.

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

PICTURE5

3.Расширяемая модель данных

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

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

4.Декомпозиция конфигураций

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

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

Декомпозиция - это мощный многоцелевой инструмент. Наборы данных могут представлять:

  • устаревшую конфигурацию
  • будущую конфигурацию
  • испытанную оптимальную конфигурацию
  • данные различных клиентских конфигураций (множественная принадлежность)

5.Синхронизация конфигураций

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

6.Открытый доступ к данным

Как было упомянуто выше, даже самые точные данные бесполезны, если невозможно получить доступ к ним. Важно помнить, что пользователям и приложениям необходимо разрешить чтение и запись в CMDB. Приложения-потребители просматривают и изменяют существующие данные, а приложения-поставщики создают и изменяют эти данные.

Для этого требуются, по меньшей мере, перечисленные ниже функции:

  • Программный доступ: CMDB должна предоставлять интерфейс прикладного программирования (API) или другой способ просмотра и изменения данных из программ. Сюда должны входить как данные экземпляров, так и классы модели данных
  • Загрузка массивов данных: CMDB должна предоставлять способ одновременного импортирования нескольких экземпляров, чтобы поисковые и другие приложения могли быстро наполнить базу данных
  • Независимость от базы данных и платформы: CMDB должна быть совместима с разными операционными системами и базами данных различных производителей в целях обеспечения гибкости среды

Заключение

В заключении перейдем от теории к практике. На нашем сайте представлены два вендора, комбинация которых прекрасно иллюстрирует вышеприведенный материал. BMC Atrium CMDB является одной из лучших моделей CMDB, которая прекрасно интегрирована с продуктами BMC ITSM Suite. ПО FNT Software предоставляет мощные средства для управления активами и инфраструктурой компании. В зависимости от задачи, комбинация этих продуктов для уровней CMDB и расширенного уровня CMDB позволяет создавать решения, сочетающие в себе все вышеперечисленные свойства идеальной CMDB предприятия.

Дополнительная информация по BMC Software представлена на сайте в разделе Компетенции\BMC Software

Дополнительная информация по FNT Software представлена на сайте в разделе Компетенции\FNT Software