В статье приведено описание различных типов данных, обычно хранящихся в CMDB от конфигурационных элементов (CI) и их взаимосвязей до смежных данных, такие как запросы на изменения и модель влияния на услуги.
В ходе предоставления надежных услуг, обслуживающих коммерческие цели компании, ИТ-подразделения сталкиваются с большим количеством сложных вопросов. Для решения большинства из них необходима хорошая стратегия управления конфигурациями: не обладая знаниями о собственной среде, невозможно управлять, обслуживать и модернизировать ее.
Согласно руководству по поддержке услуг, основанных на ITIL, управление конфигурациями должно преследовать следующие цели:
Достижение этих целей позволяет организации эффективно осуществлять управление, интеграцию и поддержку принятия решений. В частности:
Начать управление конфигурациями можно с любого из уже упомянутых процессов или нескольких других. Независимо от того, какие процессы управления конфигурациями внедряются, эффективными их делают используемые ими данные.
Конфигурационные данные должны быть точными, что означает необходимость их постоянного обновления. Конфигурации постоянно изменяются. Данные, которые были верными на прошлой неделе, могут устареть на этой, что может привести к покупке 10 серверов при необходимости покупки 5 или, что еще хуже, к установке файла исправлений, который вызовет сбой в системе.
Конфигурационные данные должны быть доступны для всех ИТ-процессов. Даже самые точные данные бесполезны, если нельзя получить доступ к ним. Например, если данные о топологии сети, предоставленные поисковым приложением, недоступны для приложения управления изменениями, невозможно грамотно спланировать перекомпоновку сети.
С годами концепция CMDB эволюционировала от набора обособленных хранилищ данных и интегрированных хранилищ данных в единую, централизованную базу данных, с каждым этапом приближаясь к базе данных, которая может являться источником записей для конфигурационных данных без ущерба для инфраструктуры.
Первоначально CMDB состояла из нескольких приложений, в которых хранились собственные данные и зачастую данные других баз с конфигурационными данными, как показано на рисунке.
Такой подход соответствовал первой цели ITIL - учету ИТ-активов и услуг - но вследствие отсутствия интеграции данных не обеспечивал достижения остальных целей. Например, данные поискового приложения не отображались в приложении управления активами, а управление влиянием на услуги никак не отражалось на соглашениях об уровне обслуживания (SLA).
Другим недостатком было отсутствие единой точки входа. Поэтому для того, чтобы получить какие-либо данные, нужно было знать, где они находятся, и как получить к ним доступ. Наконец, такой подход не позволял хранить информацию о взаимосвязях конфигурационных элементов.
Затем ИТ-организации стали создавать CMDB путем прямой интеграции различных источников данных и приложений, связывая каждое приложение-поставщика данных с приложением-потребителем, которому необходимы его данные, как показано на рисунке ниже.
Такой подход позволил одновременно использовать данные в различных процессах управления конфигурациями, что значительно повысило полезность CMDB. Но такой подход требовал больших ресурсов для создания и обслуживания интегрированного хранилища данных. Кроме того, как и при работе с обособленными хранилищами данных, некоторые пользователи, незнакомые с системой, могли не знать, где искать необходимые данные.
Не так давно поставщики предлагали единую, всеобъемлющую CMDB для хранения конфигурационных данных, доступную для всех приложений, которым необходимы эти данные.
При таком подходе любое приложение-потребитель и приложение-поставщик данных, интегрированное в CMDB, имеет доступ ко всем данным, относящимся к конфигурации, что обеспечивает более высокий уровень совместного использования данных, чем в подходе, предусматривающем интеграцию хранилищ данных. CMDB предоставляет единую точку входа. Т.е. CMDB становится источником записей, которому пользователи направляют все запросы.
Но и всеобъемлющая база данных не лишена недостатков. Необходима большая работа по сведению всех данных в единую базу для создания сложной модели данных, которая должна изменяться при изменении любого интегрированного в CMDB приложения. При этом, если приложения приобретаются не у того же поставщика, что и CMDB, их интеграция становится чрезвычайно сложной задачей.
По нашему мнению и опыту, CMDB с интегрированной моделью данных, предусматривающей наличие централизованной базы данных, связанной с другими хранилищами данных, - это лучший способ коллективного использования конфигурационных данных, не требующий высоких расходов на установку и обслуживание, характерных для исключительно централизованного подхода. В данном разделе представлено описание типов используемых данных и подробное объяснение принципов разделения данных в интегрированной модели.
Основное назначение CMDB - хранение конфигурационных элементов и связей между ними, совместно формирующих конфигурацию в определенное время или в определенном состоянии.
В то же время, ITIL также допускает хранение в CMDB данных, относящихся к конфигурационным элементам, таких как обращения в службу технической поддержки или определения SLA. Понятие "Конфигурационные элементы" - это ключевое звено CMDB. Без четкого определения того, что может являться конфигурационным элементом, а что нет, решение необходимости переноса данных различных типов в CMDB станет постоянной проблемой.
Попросту говоря, конфигурационный элемент - это отдельный экземпляр объекта, являющийся частью среды и обладающий характерными изменяемыми атрибутами. Эти объекты могут быть физическими (например, компьютерная система), логическими (например, установленная копия программного обеспечения) или концептуальными (например, бизнес-услуги). Но они должны быть непосредственной частью среды, а не информацией об этой части. Такое разграничение продемонстрировано на следующих примерах.
Конфигурационные элементы существуют не в вакууме, они влияют друг на друга. Например, один конфигурационный элемент может использовать другой элемент, зависеть от него, быть его компонентом, запускать его, быть его членом или может быть расположен в нем - это всего лишь несколько примеров. Наличие данных о таких взаимосвязях в CMDB позволяет наблюдать за взаимодействием и влиянием конфигурационных элементов друг на друга.
Взаимосвязи могут быть простыми, например, дисковод является компонентом компьютерной системы, или более сложными. Взаимосвязи существуют не только между физическими конфигурационными элементами, но и между логическими и концептуальными (например, программное обеспечение - услуга).
Данные о взаимосвязях делают CMDB мощным средством поддержки принятия решений. Понимание зависимостей и прочих взаимосвязей между конфигурационными элементами помогает оценить, например, как модернизация процессора А повысит производительность сервера Б или какие серверы выпадут из работы при сбое маршрутизатора С. Большинство простоев вызвано проблемами, возникающими в результате изменения конфигурации, а такая информация позволяет их избежать.
К конфигурационным элементам имеет отношение большое количество информации, такой как обращения в службу технической поддержки, события изменений, договоры, соглашения об уровне обслуживания (SLA), библиотека эталонного ПО (DSL) и многое другое. Хотя эти единицы сами по себе не являются конфигурационными элементами, они содержат информацию о конфигурационных элементах и формируют важную часть ИТ-инфраструктуры.
CMDB и ее инфраструктура должна быть разделена на 3 уровня.
Уровни «CMDB» и «Расширенные данные CMDB» образуют то, что понимается в ITIL как CMDB. Выделение этих двух уровней отличает интегрированный подход от предложенного подхода.
Уровень "CMDB" содержит только конфигурационные элементы и их взаимосвязи, но некоторые их атрибуты могут быть привязаны через ссылки к расширенным данным CMDB. Не все имеющиеся атрибуты конфигурационных элементов должны храниться в CMDB: Желательно хранить в CMDB только основные атрибуты, а для менее важных использовать расширенные данные CMDB.
Даже если в CMDB не хранятся все данные атрибутов или смежные данные, CMDB продолжает служить источником записей для конфигурационных данных благодаря ссылкам на расширенные данные CMDB. Можно все запросы адресовать CMDB и, в случае, если необходимые данные хранятся не в CMDB, пользователь может найти ссылки, указывающие на место хранения данных или на способ получения доступа к ним.
В расширенных данных CMDB содержатся данные, перечисленные в пункте «Смежные данные» данной статьи, а также другие атрибуты конфигурационных элементов, которые нецелесообразно хранить в CMDB.
Данные уровня «Расширенные данные CMDB» связаны ссылками с данными конфигурационных элементов в CMDB. По определению, к интегрированным атрибутам конфигурационных элементов ведут ссылки от их экземпляров в CMDB, позволяя запросам к CMDB получать доступ к этим атрибутам. Но для других типов расширенных данных эта ссылка может быть как одно-, так и двусторонней.
Например, запись запроса на изменение может иметь ссылку, посредством которой пользователь может получить доступ к экземплярам конфигурационных элементов, подлежащих изменению, а каждый экземпляр конфигурационного элемента может иметь ссылку, через которую пользователь может получить доступ к запросам на его изменение.
Это дает ряд преимуществ:
Но даже при правильной структуре для эффективного управления конфигурационными элементами CMDB необходимо следующее:
Под термином «интеграция» подразумеваем хранение некоторых данных непосредственно в центральном репозитории с доступом к данным из других источников по ссылкам.
Некоторые атрибуты можно интегрировать для их отслеживания, но не настолько частого или внимательного, как и ключевые атрибуты конфигурационных элементов. Эти вторичные атрибуты относятся к первому из двух типов данных, которые можно интегрировать. Это означает, например, что запись CMDB о сотруднике может содержать атрибут «Навыки» со списком навыков сотрудника, а также атрибут «Отдел» с названием отдела, в котором работает сотрудник. Эта запись также может быть связана с хранилищем данных о персонале, где хранятся дополнительные атрибуты, не представляющих важности для конфигурации, например, «Заработная плата».
К другому типу относятся данные, относящиеся к конфигурационным элементам, но фактически не являющиеся атрибутами конфигурационных элементов. Т.е. данные, ссылающиеся на конфигурационные элементы, или данные, на которые конфигурационные элементы ссылаются, для обеспечения дополнительного наполнения расширенной функциональности конфигурационных элементов, но сами не являющиеся частью конфигурационных элементов.Например, конфигурационные записи о копиях программного обеспечения могут иметь ссылку на лицензию, содержащую URL-адрес внутрикорпоративной сети, по которому находится лицензия, или каждая конфигурационная запись может иметь ссылку на проблему, в которой содержится информация, необходимая для поиска в базе данных проблем всех событий, касающихся данного конфигурационного элемента.
Существует множество различных типов конфигурационных элементов - от компьютерных систем до сетевого оборудования и серверного ПО. Без модели данных, точно отражающей эти типы и типы возможных взаимосвязей между ними, существует вероятность того, что в CMDB будут храниться атрибуты, не относящиеся к конфигурационным элементам, а необходимые атрибуты будут отсутствовать, что усложнит поиск групп конфигурационных элементов. Такая модель данных должна быть как объектно-ориентированной, так и расширяемой.
В объектно-ориентированной модели данные иерархически выстроены по классам, и каждый класс наследует атрибуты своего суперкласса (т.е. класса более высокого уровня в иерархии) и добавляет собственные атрибуты для создания более специфичного типа объекта, т.е. подкласса. Подклассы могут иметь собственные подклассы, продолжая иерархию до любого уровня детализации, которую необходимо отследить.Например, класс «Компьютерная система» может содержать атрибуты «Домен», «Тип процессора» и «Производитель». Класс «Компьютерная система» может содержать подклассы «Ноутбук», «Настольный компьютер» и «Центральная ЭВМ». Каждый из этих подклассов имеет три атрибута своего суперкласса плюс атрибуты, присущие только им. На рис. 6 показана часть объектно-ориентированной модели данных CMDB, включающая суперкласс и подклассы двух уровней.
К преимуществам объектно-ориентированной модели данных относятся применение общих для конфигурационных элементов одного типа атрибутов, а также возможность поиска за пределами определенного класса конфигурационных элементов в любой ветви иерархии. Если модель данных имеет один базовый класс, по отношению к которому все другие являются подклассами, пользователь может найти все конфигурационные элементы и их взаимосвязи.
Ваша инфраструктура и технология, на которой она построена, постоянно изменяются. Это означает, что типы конфигурационных элементов и взаимосвязи в CMDB должны также изменяться, поэтому возникает необходимость в расширяемой модели данных. Необходимо иметь возможность добавлять и удалять атрибуты из классов и даже добавлять и удалять классы.
Несмотря на важность данной функции, не следует ею злоупотреблять. CMDB должна содержать только общие конфигурационные элементы и их взаимосвязи. Добавление классов и атрибутов незначительных конфигурационных элементов без необходимости нагружает CMDB. Создание слишком глубокой структуры подклассов может привести к образованию настолько узко определенных классов, что к ним будут относиться всего лишь несколько членов. Соблюдайте баланс между необходимостью классификации и совместного хранения схожих конфигурационных элементов.
Декомпозиция дает возможность разделения конфигурационных данных на наборы данных, каждый из которых представляет собой набор данных в определенный момент времени. Это позволяет одним и тем же экземплярам конфигурационных элементов и взаимосвязей существовать более чем в одном наборе данных.
Данная функция важна для проверки и приведения конфигурационных записей в соответствие с инфраструктурой. Можно создать один набор данных, представляющий намеченную конфигурацию, затем при помощи поискового приложения создать другой набор данных, представляющий собой фактическую конфигурацию, и сравнить одну конфигурацию с другой.
Декомпозиция - это мощный многоцелевой инструмент. Наборы данных могут представлять:
При наличии более чем одного набора данных, содержащих одинаковые экземпляры, синхронизация является процессом идентификации совпадающих экземпляров во всех наборах данных и их последующего сравнения с другими версиями каждого экземпляра и создания отчета о различиях, либо объединения наборов данных в новый набор. Это позволяет проследить изменения во времени или определить необходимую конфигурацию при наличии данных из нескольких поисковых источников.
Как было упомянуто выше, даже самые точные данные бесполезны, если невозможно получить доступ к ним. Важно помнить, что пользователям и приложениям необходимо разрешить чтение и запись в CMDB. Приложения-потребители просматривают и изменяют существующие данные, а приложения-поставщики создают и изменяют эти данные.
Для этого требуются, по меньшей мере, перечисленные ниже функции:
В заключении перейдем от теории к практике. На нашем сайте представлены два вендора, комбинация которых прекрасно иллюстрирует вышеприведенный материал. BMC Atrium CMDB является одной из лучших моделей CMDB, которая прекрасно интегрирована с продуктами BMC ITSM Suite. ПО FNT Software предоставляет мощные средства для управления активами и инфраструктурой компании. В зависимости от задачи, комбинация этих продуктов для уровней CMDB и расширенного уровня CMDB позволяет создавать решения, сочетающие в себе все вышеперечисленные свойства идеальной CMDB предприятия.
Дополнительная информация по BMC Software представлена на сайте в разделе Партнеры / BMC Software
Дополнительная информация по FNT Software представлена на сайте в разделе Партнеры / FNT Software
Чтобы связаться с нами Вы можете воспользоваться формой для отправки сообщений, расположенной ниже.