+421233221282
Связаться с нами

Лучшие практики построения CMDB

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

Таким образом, CMDB обеспечивает структурированное представление ИТ инфраструктуры и широкий диапазон возможностей по управлению услугами.
ЕДИНЫЙ ИСТОЧНИК ПРАВДЫ
ЕДИНЫЙ ИСТОЧНИК ПРАВДЫ
CMDB обеспечивает прозрачность зависимостей между пользователями, процессами и технологиями. Являясь единым источником правды, CMDB позволяет принимать максимально эффективные управленческие решения.

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

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

Ниже приведены вопросы, на которые необходимо получить ответ перед построением CMDB:

  • Кому необходимо предоставлять информацию?
  • Какую информацию необходимо хранить в CMDB?
  • Каковы буду правила учета Конфигурационных единиц?
  • Каким образом будет обеспечиваться управление данными по объектам, не входящим в ИТ, например Персонал, Организации, Бизнес Подразделения, Сегменты рынка и т. п.
  • Соответствует ли текущим требованиям выбранный инструмент автоматизации, а так же учитывает ли он будущий рост?
  • Каким способом обеспечивается добавление Конфигурационной единицы и данных о ней в ручном режиме, так, чтобы не возникало конфликтов со средствами автоматического наполнения CMDB?
  • Каким образом будет осуществляться интеграция между источниками информации, CMDB и потребителями этой информации?
  • Каким образом будет осуществляться управление информацией о конфигурационных единицах, которые не находятся в продуктивной зоне, например, в зоне ответственности Разработчиков?
ПРОЕКТИРОВАНИЕ CMDB
ПРОЕКТИРОВАНИЕ CMDB
ОПРЕДЕЛЕНИЕ МАСШТАБА И ФОРМИРОВАНИЕ КОМАНДЫ ПРОЕКТА
ОПРЕДЕЛЕНИЕ МАСШТАБА И ФОРМИРОВАНИЕ КОМАНДЫ ПРОЕКТА
Первый этап проекта по построению CMDB заключается в формировании проектной команды, обозначения масштаба проекта, сбора входной информации от ключевых источников и потребителей, а так же в получении необходимого финансирования и утверждений по выделению и назначению ресурсов, необходимых в рамках проекта.

В таком проекте заинтересованы представители многих подразделений организации. Высшему руководству необходимо наличие хорошей системы внутреннего контроля соответствия стандартам и положениям, финансовая служба заинтересована в четкой фиксации активов, точном контроле операционных затрат, службе поддержки пользователей необходима полная информация по системам, приложениям и их взаимозависимостям. Информация будет полезна при осуществлении деятельности в рамках многих процессов управления, включая, но не ограничиваясь, управление изменениями, релизами, инцидентами, проблемами, конфигурациями, финансами, доступностью, мощностью, непрерывностью и уровнем услуг.
КОНТРОЛЬ ОБЪЕМА ИНФОРМАЦИИ CMDB
КОНТРОЛЬ ОБЪЕМА ИНФОРМАЦИИ CMDB
Уже на основе количества перечисленных выше заинтересованных сторон, можно сделать вывод об объеме информации, которую необходимо хранить в CMDB. Контролировать масштабы базы данных конфигурационных единиц необходимо на ранних стадиях проекта.

Нет необходимости хранить все обнаруживаемые системные параметры каждой конфигурационной единицы.
УСТАНОВКА И СОГЛАСОВАНИЕ ЦЕЛЕЙ И ЗАДАЧ CMDB
УСТАНОВКА И СОГЛАСОВАНИЕ ЦЕЛЕЙ И ЗАДАЧ CMDB
Для начала необходимо целостно описать задачи проекта по построению CMDB, включая обзор текущего состояния и проблем, которые должны быть решены при помощи проекта. Важно понимать, что на выходе будет получен эффективный процесс управления конфигурациями, взаимосвязями и активами, а не только база данных с информацией о конфигурациях ИТ элементов сама по себе. Цели проекта необходимо увязать с общей стратегией бизнеса и ИТ, определить какие критичные для бизнеса услуги будут включены в CMDB, какие необходимо иметь инструменты управления. Внедрение CMDB оказывает существенное влияние на организацию процессов предоставления и поддержки услуг. Затем необходимо определить критические факторы успеха и составить список ключевых показателей эффективности и измеряемых метрик.

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

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

CMDB автоматически распространяет значения полей из записей о проблеме, а так же предоставляет информацию о владельце КЕ.
Прямые преимущества
Ускорение анализа корневой причины и, как следствие, решения проблемы, избегание проблемы посредством получения информации о тенденциях и анализе классов КЕ, уменьшение частоты повторяемости инцидентов, возможность получить большие скидки от вендора, имея на руках агрегированные данные по отказам оборудования.
Потенциальные преимущества
Повышенная удовлетворенность клиентов посредством проактивного управления проблемами.
В рамках процесса управления изменениями, CMDB усовершенствует оценку рисков проведения изменений: основываясь на информации об успешности похожих изменений, проведенных в прошлом, и понимании зависимостей между компонентами инфраструктуры, обеспечивает возможность планирования внедрения пакета изменений, связывает информацию о пользователе с КЕ, поддерживая план коммуникаций с пользователями по вопросам ожидаемых изменений.
Прямые преимущества
Повышение процента успешных изменений, снижение накладных расходов по каждому изменению, снижение рисков выхода из строя системы из-за изменения, лучшая координация при планировании изменения во время окон технического обслуживания.
Потенциальные преимущества
Снижение времени проведения изменений путем обеспечения четкого механизма управления процессом, повышение удовлетворенности пользователя благодаря правильно выстроенным коммуникациям, быстрый отклик на изменения в бизнесе.
В рамках процесса управления конфигурациями, CMDB, являясь неотъемлемой частью данного процесса, обеспечивает целостные, точные и эффективные по затратам идентификацию, управление, контроль состояния и верификацию всех КЕ. Детальный и эффективный контроль версий конфигурации обеспечивает повышение эффективности стратегии отката или перестроения услуг, которые практически не возможны без внедрения CMDB. Без непрерывного обновления данных по атрибутам КЕ посредством средств обнаружения и других источников согласования CMDB, весьма сложно поддерживать точную информацию по широкому кругу КЕ продуктивной среды. Информация о текущей конфигурации значительно упрощает выполнение действий по откату назад, обновлению патчей безопасности и изменению приложений. CMDB существенно упрощает контроль совместимости версий и планирование обновлений.
Прямые преимущества
Уменьшение рисков при обновлении и изменении инфраструктуры, повышение безопасности, снижение времени простоя и недоступности услуг.
Потенциальные преимущества
Снижение срывов в работе из-за неудачной установки патча безопасности или обновления приложения.
В рамках процесса управления релизами, CMDB помогает выполнить автоматизированное развертывание на распределенных площадках, посредством обеспечения точной, детализированной информации об аппаратном и программном обеспечении, а так же о текущих конфигурациях и их совместимости с изменениями, объединенными в единый релиз. Информация CMDB будет полезна при выполнении процедур отката. CMDB позволяет отслеживать детальную информацию по версиям программного обеспечения, сверять протестированные конфигурации, облегчает планирование проекта. Информация по взаимосвязям из CMDB будет полезной при выполнении оценки потенциального системного и финансового влияния планируемого релиза, позволяет связать изменения КЕ вместе как единый релиз, и дает понимание текущей стадии развертывания.
Прямые преимущества
Снижение стоимости релиза посредством повышения степени автоматизации, снижение влияния на предоставляемую услугу, снижение рисков бизнеса.
Потенциальные преимущества
Снижение нагрузки на персонал поддержки путем устранения ручного труда по установке пачтей и программного обеспечения.
В рамках работы службы поддержки пользователей, CMDB обеспечивает значительные усовершенствования в широком круге выполняемых функций, посредством предоставления детализированной информации по КЕ, связанным с запросами на обслуживание. Информация по статусу КЕ, текущей конфигурации, базовой конфигурации, о зависимостях от других КЕ и бизнес услуг, а так же запланированных изменений, все это может способствовать сотрудникам службы поддержки в рамках обработки запросов на обслуживание. Помимо этого, CMDB обеспечивает данные, необходимые персоналу службы поддержки для уведомления пользователей о плановой недоступности услуг и статусу решения проблем.
Прямые преимущества
Снижение стоимости предоставления услуг: повышение уровня обслуживания посредством снижения ошибок, снижение объема данных, собираемых вручную, а так же снижение риска ошибки при проведении изменений, касающихся критичных бизнес функций.
Потенциальные преимущества
Повышение удовлетворенности пользователя, повышение морального духа персонала службы поддержки.
В рамках процесса управления уровнем услуг, CMDB обеспечивает сквозное управление уровнем услуг, предоставляя детальную информацию по КЕ, их связям друг с другом и поддерживающей инфраструктурой. CMDB предоставляет данные по взаимосвязям КЕ, с привязкой соглашений об уровне обслуживания (SLA) к клиентам и ко всем связанным КЕ, поддерживающим услугу, обеспечивает динамическое соотнесение компонентов SLA. Так же, CMDB предоставляет информацию по соглашениям операционного уровня (с внутренними ИТ группами и внешними провайдерами услуг) и внешним договорам (с внешними провайдерами услуг).
Прямые преимущества
Обеспечение данными, которые позволяют ИТ подразделениям заключать и соответствовать всесторонним SLA.
Потенциальные преимущества
Повышенная удовлетворенность пользователя, достигнутая за счет усовершенствования отчетности и уверенности в четком соответствии согласованному уровню обслуживания.
В рамках процесса управления финансами, CMDB обеспечивает критически важную информацию. CMDB содержит полный список КЕ, из которого можно вычислить ожидаемые расходы на техническое обслуживание и стоимость лицензий, контрактов на техническое обслуживание, даты обновления лицензий, а так же стоимость замены КЕ. Помимо этого упрощается поиск и удаление нелицензионных копий программного обеспечения. Детализированная информация по зависимостям повышает точность при составлении программ взимания оплаты, при проведении инвентаризации и аудита активов, и служит важным инструментом планирования бюджета и прогнозирования. CMDB привязывается к системе планирования ресурсов на предприятии (ERP) и обеспечивает фиксированный реестр активов.
Прямые преимущества
Снижение стоимости контрактов технической поддержки, снижение расходов на лицензии, более точное определение стоимости услуг.
Потенциальные преимущества
Понимание истинной стоимости предоставления услуг.
В рамках процесса управления непрерывностью, CMDB хранит полезную информацию о компонентах ИТ инфраструктуры, их конфигурациях, их зависимостях между собой и ключевыми бизнес процессами. Помимо этого, при помощи CMDB возможно вычислить приоритет и согласованный минимальный уровень операционной деятельности бизнеса, обеспечиваемый после значительного прерывания предоставления услуги. CMDB содержит данные, важные для восстановления, и показывает, как изменение КЕ могут привести к изменению требований к непрерывности, например, система имеющая низкий приоритет может стать более критичной в следствии изменения ее функциональности. Информация по базовому состоянию конфигурации и текущему статусу КЕ, хранимая в CMDB, предотвращает устаревание планов реакции, обеспечивая непрерывное обновление детальной информации об инфраструктуре, включая зависимости КЕ и бизнес услуг. CMDB так же является источником обратной связи с пользователями во время простоев в работе, отображая изменения статуса КЕ при восстановлении активности.
Прямые преимущества
Значительно меньшее время восстановления в аварийных ситуациях.
Потенциальные преимущества
Более высокая уверенность бизнеса в планах восстановления ИТ в аварийных ситуациях.
В рамках процесса управления доступностью, CMDB является центральным хранилищем данных, связывающим доступность, надежность и ремонтопригодность услуг с поддерживающими ИТ компонентами. В таком хранилище содержатся данные о влиянии на бизнес процессы, о взаимозависимостях компонентов, данные, необходимые для проведения оценки рисков. Понимание взаимозависимостей значительно упрощает связывание КЕ с бизнес процессом или услугой, облегчает изоляцию КЕ, являющихся корневой причиной недоступности услуги. Такие знания обеспечивают большое преимущество, при управлении и приоритезации работ с учетом влияния на бизнес. Помимо этого, CMDB связывает ИТ компоненты с Соглашениями об уровне обслуживания, соглашениями операционного уровня и внешними договорами.
Прямые преимущества
Уменьшенное время простоя услуги.
Потенциальные преимущества
Усовершенствованная приоритизация ИТ ресурсов с учетом требований бизнеса, повешенная удовлетворенность пользователя и уверенность в надежности ИТ.
В рамках процесса управления мощностью, CMDB является предметом первой необходимости для обеспечения непрерывности бизнеса, управления мощностью услуги, компонента и моделирования ситуаций. Информация о КЕ, их взаимозависимостях и связях с бизнес функциями важна для автоматизированного управления мощностью и вычислениям в режиме реального времени. CMDB отображает связанные КЕ, группируя их по мощности, предоставляет жизненно важные данные для проведения анализа рисков, снижает время, необходимое для решения инцидентов и проблем, связанных с мощностью. Данные по зависимостям так же помогают выставить приоритеты по мощностям, учитывая требования бизнеса.
Прямые преимущества
Сниженная стоимость дублирующих систем, посредством планирования мощности по группам или уровням, вместо планирования избыточности индивидуально для каждого системного уровня, сниженное время решения инцидентов и проблем, связанных с мощностью.
Потенциальные преимущества
Повышенная уверенность в высокой доступности.
В рамках процесса управления активами, CMDB обеспечивает непрерывно обновляемый реляционный репозиторий данных по КЕ, которые рассматриваются как ИТ активы. Персонал, ответственный за ИТ активы, может использовать CMDB для понимания связи активов с организационными подразделениями, сотрудниками, центрами затрат, используемыми решениями и т. п. CMDB также позволяет понять, кто использует ИТ активы, где они расположены, кто оплачивает активы.
Прямые преимущества
Сниженная общая стоимость владения активами и уменьшенные расходы на их закупку, устранение дублированных закупок активов, повышенная эффективность распределения, более точное планирование и бюджетирование.
Потенциальные преимущества
Усовершенствованный контроль и повышенная прозрачность ИТ активов на всех стадиях жизненного цикла.
В рамках процесса управления проектами, CMDB, наряду с процессами управления изменениями и релизами, обеспечивает механизм для выявления, планирования, отслеживания, обновления и мониторинга проектов, касающихся создания новых КЕ, модификации КЕ или развертывания экземпляров КЕ. Интеграция процессов управления изменениями и конфигурациями с процессом управления проектами обеспечивает плавный переход из проектов в продуктивную среду, сохраняя точный статус КЕ.
Прямые преимущества
Повышение доли успешных проектов и снижение расходов на проекты.
Потенциальные преимущества
Повышенная удовлетворенность пользователей и персонала за счет обеспечения плавного внедрения проектов.
Помимо процессов управления услугами, рекомендуемых в ITIL, организации выполняют множество других бизнес и ИТ процессов, которые опираются на точные данные об ИТ услугах и компонентах. Необходимо понять, как такие процессы могут использовать данные по ИТ услугам и компонентам, хранимые в CMDB, а также знать какие процессы являются наиболее критичными и таким образом, стоящими усилий по сбору и поддержке данных по КЕ, включая корректные ссылки и взаимосвязи.
ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОТОТИПУ РЕСУРСНО-СЕРВИСНОЙ МОДЕЛИ
ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОТОТИПУ РЕСУРСНО-СЕРВИСНОЙ МОДЕЛИ
На данном этапе проводится сбор и анализ различных требований, которые будут использоваться при построении ресурсно-сервисной модели и при выборе и внедрении средства автоматизации. Необходимо, во взаимодействии с установленными на предыдущем этапе заинтересованными лицами, определить полный и достаточный набор требований для построения CMDB. Определить уровень категоризации КЕ, типы связей между ними и на основе этих данных установить набор атрибутов КЕ, которые будут храниться в CMDB. Итогом консолидации требований должен стать спроектированный прототип ресурсно-сервисной модели.
При согласовании требований необходимо выполнить следующие шаги:
Установить и проанализировать требования государственных регулирующих документов, с целью расширения степени соответствия им со стороны ИТ и повышения эффективности отчетной деятельности.
Установить и проанализировать требования к CMDB со стороны процессов управления ИТ, с целью повышения их эффективности посредством интеграции с CMDB.
Установить требования к инвентаризационному учету, управлению активами и конфигурациями, с целью обеспечения необходимого и полного набора данных для этих процессов.
Установить требования каталога услуг, с целью построения модели зависимости между услугой и поддерживающими КЕ. Понимание, какие конкретные КЕ поддерживают услугу, позволяет в значительной степени повысить соответствие заявленному в SLA уровню предоставления услуги, эффективность проведения анализа рисков и провести расчет себестоимости услуги.
Определить уровень категоризации КЕ и модели ИТ услуги, с целью выявления оптимального объема информации, хранимого в CMDB для каждой КЕ, понимания глубины и ширины модели данных CMDB.
Определить взаимозависимости между КЕ, с целью определения модели зависимости услуг от состояния КЕ, которая будет поддерживаться в CMDB.
Определить перечень атрибутов КЕ, с целью разграничения, какие атрибуты необходимо хранить непосредственно в CMDB, а какие в федеративных хранилищах данных.
Разработать макет ресурсно-сервисной модели.
Стоит учитывать, что для функций управления активами, конфигурациями и инвентарного учета требуется один и тот же набор атрибутов, но при этом, каждая функция предъявляет свои дополнительные требования.

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

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

На уровне управления конфигурациями требуется наличие дополнительного набора данных о КЕ, включая информацию по установленным патчам и особым функциональным настройкам, а так же информацию по взаимосвязям КЕ. Такая информация будет отражать общую модель взаимоотношения между услугой и инфраструктурой, образующую структуру конфигурации.
Можно назвать элемент ИТ инфраструктуры конфигурационной единицей, поняв, необходимо ли им управлять, чтобы предоставлять ИТ услугу. Если требуется управление, то это конфигурационная единица. Чтобы точно определить является ли элемент ИТ инфраструктуры конфигурационной единицей, необходимо ответить на следующие вопросы:
  • Он уникален?
  • Он необходим для предоставления услуги?
  • Им можно управлять?
  • Имеет ли он хотя бы одну характеристику, которую можно изменить?

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

  • Он подвергается амортизации как капитальный актив?
  • Имеются ли какие-либо соглашения по ежегодному обслуживанию?
  • Необходимо ли отслеживать затраты на него на протяжении полного жизненного цикла?
  • Попадает ли он под лицензионное соглашение и необходимо ли отслеживать его на предмет соответствия?
  • Возможно ли добиться более низкой закупочной цены на него, если известно планируемое количество закупок элементов данного типа на будущий год?

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

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

Общим подходом является регистрация услуг в качестве КЕ, связывание их с инфраструктурными КЕ и создание модели предоставления услуги, что в конечном итоге обеспечивает сквозной мониторинг и управление всеми типами услуг.

Результатом выполнения вышеперечисленных работ будет являться согласованный задокументированный полный и достаточный набор требований к прототипу ресурсно-сервисной модели.
ОПРЕДЕЛЕНИЕ УРОВНЯ СТРУКТУРИЗАЦИИ КЕ
ОПРЕДЕЛЕНИЕ УРОВНЯ СТРУКТУРИЗАЦИИ КЕ
На данном этапе определяется и документируется уровень структуризации. Определяются классы КЕ, атрибуты КЕ и типы связей КЕ. В финансовой сфере слишком большое количество классов, подклассов (и под-подклассов) категорий затрат может создать слишком сложный бюджет, а некоторые подклассы могут никогда не использоваться. Такая же логика применима и для информационных моделей в рамках управления конфигурациями. Желание охватить все может привести к хранению больших объемов данных, которые создают немного или вообще не создают ценности, но влекут финансовые затраты.
Классификация КЕ должна охватывать как физические, так и логические элементы ИТ инфраструктуры. Посредством классов КЕ устанавливается масштаб (ширина) охвата CMDB. К физическим элементам можно отнести, например, аппаратное обеспечение, сетевое оборудование, инженерное обеспечение. К логическим элементам — программные/бизнес приложения, поддерживающее программное обеспечение, данные, процессы, стандарты и документы.
Необходимо установить критерии попадания КЕ в тот или иной класс, например:
  • Прикладное/Бизнес ПО
    Элемент ИТ инфраструктуры, который является программным обеспечением, поддерживающим функциональность бизнеса, услуги или системы. Например, закупленный у вендора программный продукт.
  • Поддерживающее ПО
    Элемент ИТ инфраструктуры, который является составной частью программного обеспечения, который косвенно поддерживает функционал системы, но при этом не обеспечивает ключевое функционирование. Например, операционная система, система резервного копирования, антивирус.
  • Аппаратное обеспечение
    Элемент ИТ инфраструктуры, который является физическим технологическим устройством, которое поддерживает одну или несколько функций в рамках системы. Например, сервер, рабочая станция, маршрутизатор.
  • Данные
    Элемент ИТ инфраструктуры, который является данными о типе системы, пользователя, размещения или организационной структуры, организован в структурированном формате, представляет различные типы информации, используемой системами.
  • Сеть
    Элемент ИТ инфраструктуры, который является логическим представлением компонента сети. Сетевые устройства относятся к классу Аппаратное обеспечение, а к классу Сеть следует отнести интерфейсы сетевых устройств, порты, сегменты, виртуальные сети. Например, Порт 21, порт коммутатора 9/24, критически важная зона DMZ, интранет, интерфейс маршрутизатора T1.
  • Процесс
    Элемент ИТ инфраструктуры, который представляет собой последовательность шагов, процедур или инструкций. Например, процедуры исполнения запросов пользователей, такие как создание почтового адреса, изменение доменного пароля, создание резервной копии.
  • Стандарт
    Элемент ИТ инфраструктуры, который является набором руководств, политик и/или ограничений для конкретной области ИТ. Например, политика хранения электронной почты, протокол защиты доступа через сеть.
  • Документ
    Элемент ИТ инфраструктуры, который является физическим документом, разработанным и находящимся в собственности, относящимся к особой системе. Например, комплект технорабочей документации, соглашение об уровне обслуживания, руководство по процессу управления изменениями.
  • Сооружение
    Элемент ИТ инфраструктуры, который является физическим размещением, поддерживающим некоторые формы эксплуатации ИТ или размещает в себе другие ИТ компоненты. Например, удаленный офис, центр обработки данных, call-центр.
Установив классы высокого уровня, следует установить подклассы для каждого из класса, например, для класса Аппаратное обеспечение установить подкласс Сервер (с под-подклассами Unix-сервер и Windows сервер), подклассы Рабочая станция и Сетевое оборудование (каждый со своими под-подклассами). Спускаясь до тех пор, пока ценность подкласса не станет относительно мала по сравнению с затратами на его создание и управление, подкласс необходимо оформить как один или несколько атрибутов вышестоящего
класса КЕ.

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

В верхнем уровне CMDB (Рис. 1) изображена структура конфигурации ИТ услуги, состоящая из набора сквозных услуг, которые ИТ предоставляет бизнесу. ИТ услуги комбинируются и многократно задействуются в целях формирования ценности бизнеса.

На нижнем уровне CMDB изображена структура конфигурации инфраструктуры. Наборы классов КЕ связывают конфигурационные единицы структуры конфигурации услуг с определенными группами инфраструктурных компонентов. Инфраструктурные компоненты содержатся в предопределенных Классах К Е и Подклассах К Е и представляют собой настоящие активы ИТ инфраструктуры.

Картина того, как все единицы взаимосвязаны и сконфигурированы друг для друга в целях предоставления ИТ услуг является структурой конфигурации. Посредством структуры конфигурации возможно соотносить ИТ ресурсы с бизнес услугами и управлять ими с перспективы бизнеса. Структура конфигурации позволяет ответить на такие вопросы как:

  • Какова реальная стоимость предоставления бизнес услуги — не только стоимость технологических активов, обеспечивающих услугу, но и связанные затраты на поддержку и обслуживание, которые несет ИТ подразделение?
  • Каково влияние сбоя, внедрения изменения или какого-либо еще события в ИТ на предоставление бизнес услуги?
  • Какова мощность технологических активов, требуемая для поддержки конкретной бизнес услуги на сегодняшний день и в будущем, а так же какова текущая загрузка мощности для данной бизнес услуги?
  • Каково качество предоставляемой бизнес услуги, с учетом доступности, надежности, производительности и зарегистрированных инцидентов

Получение ответов на представленные выше вопросы позволяет получить представление о том, как наилучшим способом построить ИТ инфраструктуру, соответствующую бизнес целям.
ОПРЕДЕЛЕНИЕ СВЯЗЕЙ МЕЖДУ КЕ
ОПРЕДЕЛЕНИЕ СВЯЗЕЙ МЕЖДУ КЕ
Концепция связывания КЕ друг с другом в структуры конфигурации услуг является ключевой для построения CMDB. Без связей CMDB будет являться не более чем набором идентификаторов активов и местом хранения информации о них. При агрегировании заданного множества КЕ в структуры конфигураций и описании их отношений в нескольких разрезах (техническом, экономическом, юридическом и т. п.) возникает синергия, которая не присуща каждой КЕ по отдельности и, в конечном итоге, позволяет понять цепочку формирования той самой ценности предоставляемой услуги.
Связи позволяют понять типы зависимости между КЕ. Многие зависимости имеют направленность. Наиболее обобщенным типом зависимости является зависимость «родитель — потомок». Например, если КЕ, А влияет на КЕ В, то известно, что КЕ, А требует некий выход от КЕ В, отсюда можно утверждать, что КЕ В зависит от КЕ А. При таком типе отношений потомок представляет некоторые детализированные аспекты родителя, потомок конкретизирует родителя. Сервер (родитель) имеет системные компоненты (потомки сервера), которые имеют свои подкомпоненты (потомки потомков) и так далее. Такой тип связи является ключевым для описания уровней иерархии в CMDB.
Для отражения взаимозависимостей услуг можно использовать дополнительные типы связи, например, поддерживается и поддерживает, либо обеспечивается и обеспечивает. Бизнес услуга поддерживается или обеспечивается набором ИТ услуг. Для отражения связей между ИТ услугой и набором компонентов ИТ инфраструктуры можно использовать тип включает. Для отражения обратной направленности использовать тип входит в. Тип определяется отражает набор ИТ компонентов, и, в свою очередь, ИТ компоненты определяют набор. ИТ компоненту необходимо назначить тип связи всего лишь в одну сторону, для связи с родительским объектом, так как потомков у ИТ компонента нет. Таким типом связи как раз и служит тип определяет.
ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЕ
ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЕ
Атрибутами являются элементы данных описывающие КЕ, по большому счету это прилагательные, которые описывают существительные. При помощи атрибутов производится идентификация и подробное описание важных характеристик КЕ. Например, для КЕ класса Аппаратное обеспечение атрибутами могут быть: марка, модель, серийный номер, размещение, версия, лицензионный ключ и т. п.

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

Табл. 1 Источники информации и атрибуты
Источники данных атрибутов
Примеры атрибутов
Система управления активами
Стоимость амортизации аппаратного обеспечения, детали лизинговых договоров, решения по покупке/построению/формированию.
Системы управления инцидентами/проблемами/изменениями
Экземпляры, для которых перерыв в работе КЕ выражается в инциденты с высоким влиянием/приоритетом, детальная информация для проведения анализа корневой причины, определения влияния неудачных изменений
Система мониторинга
Пороговые величины для полосы пропускания, тенденции производительности процессора, детальная информация по корреляции событий.
Финансовая система
Характеристики центра затрат, формулы выставления счета, размер прибыли, финансовые тенденции, финансовые цели, зарплаты сотрудников.
Система управления кадрами
Расписание выплат зарплат сотрудникам, детальная информация по должностям, учет опыта, сертификаты, планы обучения.
Системы каталогов (AD или LDAP)
Детальная информация о пользователях, описание размещений, привязка размещения аппаратного обеспечения к объему потребления со стороны пользователей, критерии аутентификации, пароли.
Библиотека эталонного программного обеспечения(DML)
Физическое хранилище лицензий, архив всех разработанных кодов, отчеты о соответствии лицензионным соглашениям, оригиналы коммерческих программных продуктов, пакеты программного обеспечения. Физическое хранилище аппаратного обеспечения, запасных частей, записей об инвентаризации.
Система управления документооборотом
Физическое хранилище документов, статистика по поиску документов и их использованию, различные изменения документов между версиями, способствующие авторы.
При организации федеративного хранения данных необходимо определить перечень систем-источников данных, владельцев таких данных или их представителей, правила хранения и обработки, подход к распространению, требования к организации доступа.

Для извлечения данных, которые хранятся в соответствии с определенными стандартами конфиденциальности или защиты, необходимо привлечь сотрудников, отвечающих за соблюдение таких стандартов. Многие системы имеют протоколы обмена данными и интерфейсы прикладного программирования (API). Идеально, когда каждая система имеет интерфейс web службы, который позволяет осуществлять обмен структурированной информацией при помощи предопределенных запросов, но чаще приходится продумывать способ интеграции накопленных данных в CMDB. В свою очередь, CMDB является ключевым фактором, поддерживающим процессы управления ИТ услугами. При невозможности организации автоматического распространения данных по атрибутам, необходимо продумать механизмы ручного управления данными.

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

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

Определение состава атрибутов проще начинать с компонентов ИТ инфраструктуры, состав атрибутов для них практически прозрачен и очевиден. Используя составленные на этапе структуризации классы КЕ для структуры конфигурации инфраструктуры, можно определить
атрибуты, как показано ниже, в Табл. 2.


Табл. 2 Атрибуты инфраструктурных КЕ
Класс КЕ
Примеры атрибутов
Пример КЕ
Прикладное/Бизнес ПО
  • Версия
  • Язык
  • Сборка
  • Версия компилятора
  • ID DSL
  • Модуль представительского уровня
  • Модуль уровня бизнес логики
  • Модуль уровня доступа к данным
  • Модуль уровня данных
Поддерживающее ПО
  • Версия ОС
  • Сборка
  • Версия образа
  • Файл обнаружения вируса
  • ОС Wintel
  • ОС UNIX
  • ПО Виртуального сервера
  • Антивирусное/Антиспам/Антифишинг ПО
  • ПО резервного копирования
  • Базовый образ сервера/рабочей станции
Аппаратное обеспечение
  • Производитель
  • Марка
  • Модель
  • DHL ID
  • Серийный номер
  • MAC адрес
  • IP адрес (статический)
  • Версия прошивки
  • Wintel сервер
  • UNIX сервер
  • Рабочая станция
  • Ноутбук
  • Планшет
  • Периферийное устройство:
    • Сетевой принтер
    • Сеть с подключёнными хранилищами данных
    • Сетевое оборудование (маршрутизатор и т.п.)
Данные
  • ID клиента
  • ID размещения
  • Почтовый адрес
  • Почтовый индекс/ZIP код
  • Идентификатор организации
  • Данные по клиенту
  • Данные по размещению
  • Данные по орг-штатной структуре
Процесс
  • Имя главного процесса
  • Владелец процесса
  • Описание чрезвычайных ситуаций
  • Исполнение запросов
  • Рабочая инструкция
  • Процедура
Стандарт
  • Дата вступления в силу
  • Детали освобождения
  • Номер версии
  • Стандарт обеспечения безопасности
  • Политика
  • Стандарт на закупки
Документ
  • Автор
  • Редактор
  • Процесс пересмотра
  • Поддерживающая документация:
    • Строительные планы
    • Чрезвычайный план
    • Модель услуги
    • Соглашение об уровне обслуживания
    Сооружение
    • Физическое размещение
    • Контакт на месте
    • Географический регион
    • Центр обработки данных
    • Удаленный офис
    • Консолидированный офис
    Стоит учитывать, что для некоторых КЕ необходимо предусмотреть свои, уникальные атрибуты, которые не свойственны всему классу, но важны для управления и эксплуатации. Атрибуты можно разбить на классы, например, общие, атрибуты свойственные классу КЕ и дополнительные атрибуты, свойственные некоторым специфичным КЕ.


    Табл. 3 Типы атрибутов КЕ
    Тип атрибута
    Определение
    Пример
    Общий
    Обязательные атрибуты, которые применимы ко всем КЕ в CMDB
    • Название
    • Владелец
    • Обозначение
    • Описание
    • Дата создания
    • Дата последнего изменения
    • Версия
    • Идентификатор группы жизненного цикла
    Свойственный классу
    Поддерживающие атрибуты, которые являются уникальными для какого-либо класса КЕ и распространяются на всех потомков в данном классе КЕ
    Сервер
    • Марка
    • Модель
    • Производитель
    • Серийный номер
    Документ
    • Версия
    • Автор
    • Редактор
    Специфичный
    Дополнительные атрибуты, уникальные для некоторых КЕ (экземпляров), обеспечивающие детальную информацию, которая не выражена в атрибутах общего типа или атрибутах, свойственных классу
    Сервер ABC123
    • Дата/время последнего аудита безопасности
    • Уровень допуска к секретам у оператора
    СОЗДАНИЕ ПРОТОТИПА РЕСУРСНО-СЕРВИСНОЙ МОДЕЛИ
    СОЗДАНИЕ ПРОТОТИПА РЕСУРСНО-СЕРВИСНОЙ МОДЕЛИ
    На данном шаге создается прототип ресурсно-сервисной модели с учетом требований, определенных ранее. Прототип должен отразить принятые уровни и методы структуризации КЕ, классы КЕ, связи и атрибуты, а так же принципы и механизмы управления данными. Прототип ресурсно-сервисной модели не должен содержать в себе все имеющиеся в организации экземпляры КЕ, прототип является шаблоном согласованных и стандартизированных структур, связей и атрибутов для данной организации. Пример схематичного отображения прототипа ресурсно-сервисной модели представлен ниже на Рис. 2.
    Рис. 2 Пример прототипа РСМ
    Наличие согласованного и утвержденного прототипа ресурсно-сервисной модели в совокупности с механизмом управления существенно облегчает выбор технологии, используемой для построения и поддержки актуальности CMDB, средств автоматического обнаружения и визуализации зависимостей между КЕ.
    ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЕ
    ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЕ
    На данном шаге необходимо произвести выбор инструмента автоматизации, как для самой CMDB, так и для поддерживающих решений в виде систем автоматического обнаружения и наполнения CMDB, а так же визуализации зависимостей между КЕ. Инструмент автоматизации CMDB должен иметь интуитивно понятный интерфейс, обеспечивающий выполнение функций по управлению жизненным циклом КЕ, быть защищенным как на уровне доступа к данным, так и на уровне контроля доступа пользователей, позволять отслеживать версионность КЕ, производить моделирование данных, иметь механизмы согласования и синхронизации данных, а так же механизмы интеграции с другими решениями, например, с системами обнаружения, мониторинга и внешними хранилищами. Некоторые аспекты перечисленных требований представлены ниже.

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

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

    Управление жизненным циклом КЕ. В CMDB деятельность по управлению конфигурациями включает в себя моделирование данных и контроль версий:
    • Моделирование данных
      Предопределенная на основе индустриальных стандартов объектная модель обеспечивает набор свойств и связей для КЕ по умолчанию, включая такие свойства, как иерархия и наследование.
    • Контроль версий
      Данная функция присваивает уникальные идентификаторы для связывания изменений отдельных КЕ или наборов КЕ, поддерживающих ИТ услугу, предоставляемую бизнесу. Контроль версий включает в себя компетенции по поддержке создания скриншотов в ручном или автоматическом режиме, обеспечивая, при необходимости, откат к предыдущему известному базовому состоянию конфигурации. Должны поддерживаться автоматическое обновление и запись номера версии родительской КЕ, если номер версии компонента-потомка изменяется. Версионность должна обеспечивать прозрачность истории изменения КЕ, возможность производить сравнение текущего состояния с известным предыдущим нормальным состоянием на различном уровне детализации, а так же обеспечивать средства для минимизации ручной работы по выполнению сравнения. Интеграция с программным обеспечением управления релизами и инструментами распространения должна способствовать обеспечению возможностей CMDB по контролю версионности и откату к предыдущему нормальному состоянию конфигураций.
    Управление данными. Функции управления данными в CMDB должны включать в себя, как минимум, согласование и синхронизацию:
    • Согласование

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

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

    Функции управления данными так же должны поддерживать массовое создание, модификацию и удаление КЕ.

    Интеграция с хранилищами данных. Хранилища данных объединяются при помощи адаптеров через API функции, стандартные форматы обмена данными, таких как XML, стандартные Web службы или свои методы прямой интеграции.

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

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

    • Физические и логические сети передачи данных
    • Системы и компоненты приложений
    • Детализированная информация о конфигурации каждого из устройств или компонента программного обеспечения
    • Релевантное моделирование зависимости услуг от инфраструктуры
    • Релевантное моделирование услуг в зависимости от сообщества пользователей
    • Релевантное моделирование влияния на бизнес
    • Релевантное моделирование связанных зависимостей (контрактов на услуги и целей)
    • Релевантное моделирование операционных зависимостей (кто, что и когда делает)
    • Релевантный взгляд на поведение пользователя при потреблении услуг в целях оптимизации планирования операционной деятельности и построения услуг.

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

    • База данных кадровой службы с информацией по персоналу
    • Папки LDAP с информацией по идентификаторам пользователей и паролям
    • База данных средства автоматизации процессной деятельности с информацией по запросам, инцидентам, изменениям и проблемам
    • Система автоматизации документооборота с информацией по контрактам и политикам
    • Инструменты автоматизированной разработки программного обеспечения с информацией по бизнес процессам.
    При интеграции CMDB с другими хранилищами данных, по умолчанию происходит интеграция и с другими процессами.
    CMDB И CMS
    CMDB И CMS
    В соответствии с ITILv3, CMS состоит из баз данных и инструментов, которые управляют конфигурационной информацией. Простыми словами, CMS является основой, которая обеспечивает управление полным жизненным циклом услуг в ИТ.

    Целями CMS являются:
    • Максимальное увеличение ценности для бизнеса
    • Управление услугами, критичными для бизнеса
    • Гарантия соответствия государственным и частным политикам безопасности
    • Обеспечение автоматизации в целях максимального повышения эффективности
    • Обеспечение контроля над активами
    CMS может включать в себя множество инструментов управления ИТ и баз данных, таких как, база данных активов, система управления изменениями, в том числе одну или несколько CMDB, и посредством федерации, имеет доступ ко всем основным хранилищам данных и их соответствующему содержимому. Посредством добавления ключевых функций, таких как аналитика, отчетность, системы управления, CMS увеличивает ценность CMDB для ИТ.

    Важно предусмотреть, методы интеграции между CMDB и CMS, если в планах CMDB будет встраиваться в гораздо более обширную Систему управления конфигурациями.
    ПЛАНИРОВАНИЕ НАПОЛНЕНИЯ CMDB
    ПЛАНИРОВАНИЕ НАПОЛНЕНИЯ CMDB

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

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

    Необходимо рассмотреть ряд вопросов, связанных с производительностью источников данных:

    • Какова текущая производительность и надежность источника данных?
    • Какова текущая активность на уровне системы:
      • Количество активных пользователей
      • Степень интеграции с другими инструментами автоматизации
      • Расписание резервного копирования, сканирования на вирусы, генерации отчетности или анализа данных?
    • Выдержит ли аппаратное и инженерное обеспечение дополнительную нагрузку и имеется ли достаточно места для миграции данных? Каков прогнозируемый прирост объема данных?
    • Необходимо ли согласовать дополнительные ограничения или специальные разрешения?
    • Какова приближенность к набору данных для CMDB и связанных технологий?
    • Окажут ли влияние ограничения физической топологии или сети (ширина полосы пропускания, удаленность и т. п.)?
    • Какова текущая версия источника данных? Планируется ли обновление в ближайшие полгода или год?

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

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

    • Какова частота обновления данных для каждого из наборов данных?
    • В какое время планировать обновление по каждому из наборов данных, так чтобы избежать одновременной работы большого числа потоков?
    • Имеются ли какие-либо запретные периоды (часы критичные для работы, создание резервных копий и т. п.)?
    • Будут ли предусмотрены меры по срочному согласованию, перекрывающие правила и расписания по требованию?
    Существует множество различных подходов и возможностей согласования данных, но все они опираются на три основных вида активности - определение данных, сравнение данных и слияние данных - которые выполняются совместно в целях гарантии целостности и точности всей информации о КЕ, хранимой в CMDB. Данные активности обеспечивают средства для организации данных, исходящих от множества источников, создания правил для совмещения данных и определения, как согласовать получаемые данные с данными, которые уже хранятся в CMDB.
    Определение данных о КЕ включает в себя присвоение ей уникального идентификатора. Уникальный идентификатор позволяет сравнивать несколько наборов данных и, на основе такого идентификатора, определять, относятся ли данные из набора к одной и той же КЕ. Помимо этого, уникальный идентификатор является ключом к определению сходства между обнаруженными данными и данными, которые уже хранятся в CMDB. Уникальным идентификатором является информация о КЕ, которая позволяет отличить ее от других КЕ в ИТ инфраструктуре. Уникальным идентификатором может быть имя хоста, серийный номер 1 или другие атрибуты, которые остаются постоянными, не зависимо от изменений в КЕ. Когда нет такого единого атрибута, можно использовать комбинацию из нескольких атрибутов.

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

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

    Действия по слиянию данных можно разделить на два этапа:
    1
    Слияние наборов данных, полученных от нескольких источников в единый набор данных о КЕ.
    2
    Слияние согласованного набора данных с информацией, хранящейся в CMDB (если начальное наполнение уже произведено).
    Совмещение данных, полученных от различных источников в единый, согласованный набор, позволяет значительно снизить нагрузку на производительность CMDB, так как сравнение и слияние выполняется только для двух наборов данных: набора данных из CMDB и единого, согласованного набора обнаруженных данных. Такой подход значительно упрощает управление различиями, а так же ограничивает количество выполняемых сравнений и слияний.

    Данные, получаемые из различных источников, имеют разные представления, поэтому необходимо привести представления наборов данных к единому виду перед выполнением согласования. Другими словами, данные должны быть приведены к единому формату, который адоптирован к способу хранения информации о КЕ в CMDB. Без нормализации представления практически невозможно сравнить или объединить наборы данных.
    ПОСТРОЕНИЕ ПРОЦЕССА УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ КЕ
    ПОСТРОЕНИЕ ПРОЦЕССА УПРАВЛЕНИЯ ЖИЗНЕННЫМ ЦИКЛОМ КЕ
    В целях поддержания актуальности информации в CMDB, необходимо осуществлять управление КЕ на протяжении всего ее жизненного цикла.

    На данном шаге необходимо продумать принципы добавления новых КЕ в CMDB и обновления данных о КЕ (атрибутов и связей). Определить и задокументировать процедуры контроля добавления информации для каждого класса КЕ.

    Многие КЕ имеют одинаковые этапы жизненного цикла. Например, для КЕ класса Аппаратное обеспечение (рабочие станции, ноутбуки, принтеры, сканеры, серверы и т. п.) каждый тип оборудования будет иметь свои атрибуты и обладать различным функционалом, но жизненный цикл для всего класса будет оставаться типичным. Такие конфигурационные единицы необходимо объединить в группы и для каждой такой группы КЕ необходимо определить этапы жизненного цикла. Ниже на Рис. 3 представлены этапы жизненного цикла для группы КЕ.
    После определения этапов жизненного цикла КЕ необходимо определить, какие данные по атрибутам и связям КЕ будут заноситься или изменяться на каждом из этапов.
    В данном примере показан шаг записи новой КЕ в базу при создании запроса на покупку оборудования, так как в запросе необходимо указать четкую и детальную спецификацию, какой тип оборудования необходим, какими атрибутами оно должно обладать, кому и когда оно необходимо, но, возможно, нет необходимости записывать КЕ до ее утверждения:
    • Запрос на новое оборудование
      На данном этапе жизненного цикла, атрибуты описывают, когда КЕ была открыта, кто открыл КЕ, какое оборудование требуется закупить, когда данное оборудование необходимо.
    • Утверждение запроса
      Атрибуты на данном этапе описывают, кто утвердил (или отклонил) запрос, дату и время утверждения, распределение бюджетных средств, а так же любые условия, которые необходимо соблюсти, например, установить владельца оборудования.
    • Размещение заказа
      Заказ оборудования требует четкой и детальной спецификации оборудования, это означает, что необходимо прописать множество ценных атрибутов, включая марку, модель, техническую спецификацию и свойства. Если заказ размещается и принимается в электронном виде, то существует возможность организации одновременного автоматического распространения информации о КЕ в необходимые базы данных.
    • Поставка оборудования
      Атрибуты данного этапа включают в себя базовые данные (такие как дата и время поставки) и более критичные данные (такие как серийный номер и технические спецификации), которые можно сравнить с технической информацией, указанной при размещении заказа.
    • Тестирование оборудования
      На данном этапе жизненного цикла существует возможность начать добавление данных о владении и ответственности. Перед тем как утвердить тестирование, необходимо проверить комплектность и полноту поставки КЕ.
    • Установка оборудования
      На данном этапе производится запись о дате перевода КЕ в продуктивную среду для нормальной работы.
    • Поддержка оборудования
      Записываются атрибуты, которые необходимы для управления оборудованием, в зависимости от требований к отслеживанию изменений в конфигурации: любое изменение в статусе КЕ должно проводиться через процесс управления изменениями, в рамках которого производится изменение атрибутов.
    • Списание оборудования
      На данном этапе записывается информация о дате и времени списания оборудования, указывается, кто утвердил списание.
    Следующим шагом после определения этапов жизненного цикла КЕ и этапов заполнения информации по атрибутам и связям КЕ необходимо установить источники данных по атрибутам и ответственных за каждый из них. Представители И Т службы являются первыми владельцами данных, так как служба поддержки отвечает за обработку заявок на обслуживание, которые могут включать в себя запросы на закупку нового оборудования. Необходимо определить начальный момент доступности данных для обновления. Ниже на Рис. 5 показан пример распределения ответственности за поддержку актуальности информации по атрибутам КЕ.

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

    • кто будет отвечать за обновление данных, имеющихся в CMDB
    • кто будет отвечать за точность таких данных
    • кто будет отвечать за своевременность внесения таких данных
    • кто будет отвечать за соблюдение уровня защищенности данных

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

    Далее следует установить метод контроля целостности и точности данных, а так же методы проверки их соответствия внутренним и внешним требованиям. Такая задача решается, например, при помощи установки целей по CobiT и построением процессов ITILv3 2011. Точно выстроенный и задокументированный процесс управления жизненным циклом КЕ для каждой группы КЕ предотвращает появление узких мест в управлении изменениями при выполнении действий по обновлению информации в CMDB (Рис. 6).
    Построение, документирование и внедрение поддерживающих процессов для сопровождения CMDB является очевидным и важным этапом. Без таких процессов данные о КЕ, содержащиеся в CMDB, очень скоро будут искажены, а пользователи, скорее всего, утратят уверенность в CMDB и перестанут к ней обращаться.

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

    Для защиты CMDB необходимо иметь процедуры резервного копирования, безопасное внешнее хранилище и запланированные базовые состояния, которые так же хранятся во внешнем хранилище. Базовым состоянием является слепок конфигурации, который отражает информацию о структуре и деталях CMDB в конкретный момент времени. Так же необходимо определить роль, которую будет играть CMDB во время восстановления после сбоев.
    НАПОЛНЕНИЕ CMDB
    НАПОЛНЕНИЕ CMDB
    Целью данного шага является полноценное наполнение CMDB всеми кассами КЕ и связанной информацией по атрибутам и связям. Наполнение CMDB так же включает в себя сбор и очистку данных, разработку скриптов импорта, написание правил согласования данных (реконсилиации) и проверки успешности импорта данных.

    Существует три основных метода наполнения CMDB. Первым методом является импорт данных из таких источников, как электронные таблицы или выгрузка из баз данных приложений. После начального наполнения такие источники больше не используются. Вторым методом является импорт данных из источника или хранилища, для которых впоследствии будет производиться постоянная синхронизация с CMDB. Такая однонаправленная или двунаправленная синхронизация требует применения правил согласования, которые будут применяться не только к начальному, но и постоянному процессу импорта данных. Третий метод заключается в ручном обновлении полей данных при помощи графического интерфейса пользователя непосредственно в CMDB. Зачастую применяется
    комбинация из трех представленных выше методов. Потому что связи между услугами и инфраструктурными КЕ, информацию о персонале и их профессиональных навыках можно ввести только вручную. При этом стоит уделить внимание тому, что пользователи порой не обладают всеми знаниями о КЕ, которые должны внести в поля. При отсутствии некоторых данных персонал будет вбивать все что угодно, что более-менее похоже на правду, для завершения монотонной задачи. Очевидно, что такое положение дел может причинить вред точности данных. Чтобы предотвратить возникновение такой проблемы, можно включить значение поля Неизвестно (Unknown). Это позволит персоналу, осуществляющему ручной ввод информации, завершить задачу, даже если они на данный момент не обладают точными данными, и уже в процессе проверки актуальности и точности данных CMDB выявить неизвестные поля, уведомить владельца данных о необходимости устранения пробелов.

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

    Не менее важным фактором является время перевода CMDB в продуктивную среду. Данные, полученные от источников, являются слепками состояния КЕ. Инфраструктура меняется. Длительный интервал времени между получением данных от множества источников и введением в эксплуатацию CMDB может привести к потере актуальности информации.
    ФУНКЦИИ И НЕОБХОДИМЫЕ НАВЫКИ
    ФУНКЦИИ И НЕОБХОДИМЫЕ НАВЫКИ
    Ниже представлен перечень ключевых функций и навыков, которые требуются в рамках внедрения CMDB и в дальнейшей работе:
    • Администрирование инструментов обнаружения и мониторинга
      • Настройка этапов обнаружения
      • Поддержка хранилища обнаруженных данных
    • Администрирование интеграции между хранилищем обнаруженных данных и CMDB
    • Согласование данных в CMDB
      • Выявление и управления различными контейнерами или отдельными порциями обнаруженных данных
      • Определение правил идентификации при связи экземпляров в нескольких контейнерах с одной и той же КЕ
      • Определение правил слияния экземпляров из нескольких контейнеров в основной контейнер или единый источник правды
      • Планирование расписания согласования идентификаций и слияний
      • Максимизация возможностей согласования данных, заложенных в инструменты автоматизации производителем
    • Определение связей между КЕ в CMDB и федеративных базах данных
    • Управление моделью данных
      • Добавление атрибутов или классов в объектную модель, по мере необходимости
      • Устранение аспектов объектной модели, которые не планируется использовать
    • Управление доступом к данным
      • Назначение полномочий для выполнения административных задач, таких как создание правил согласования данных, настройка объектной модели
      • Назначение полномочий для обработки данных о КЕ, хранимых в CMDB
    • Администрирование интерфейса пользователя
      • Определение запросов и построение отчетов
      • Администрирование компонента визуализации данных (если такой имеется у выбранного средства автоматизации)
      • Максимизация остальных имеющихся функций пользовательского интерфейса
    • Миграция данных, структур и конфигураций CMDB с тестового сервера в продуктивную среду
    • Понимание матрицы поддерживающих процессов, их входов и выходов
    • Понимание способов интеграции CMDB, обеспечиваемых инструментом автоматизации, с другими системами (например, API функции)

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

    Помимо этого необходимо идентифицировать и задокументировать перечень:

    • Функциональных процессов, которые будут изменены при добавлении данных CMDB;
    • Интегрированных или федеративных приложений, которые будут использовать новые данные из CMDB;
    • Рабочих процедур, которые будут изменены;
    • Новых рабочих процедуры;
    • Дополнительных навыков, требуемых виду появления новых рабочих процедур;
    • Пользователей, задействованных в рабочих процедурах.

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

    На основании выполненных действий необходимо составить план обучения, в котором предусмотреть:
    Передачу знаний от проектной команды (хорошей практикой является вовлечение эксплуатирующего персонала и группы пользователей на стадии опытной эксплуатации)
    Детали обучения администрированию и использованию программного обеспечения (с выбором учебных центров и перечнем рекомендуемых курсов)
    Детали изучения новых процедур и инструкций для всех пользователей, вовлеченных в работу с CMDB (включая перечень преимуществ, получаемых при внедрении CMDB, таких как уменьшение количества ошибок, меньшее время простоя, высокий уровень услуг)
    Вовлечение эксплуатирующего персонала и группы пользователей на стадии опытной эксплуатации дает такие преимущества, как низкий уровень стресса, меньшее количество суеты и хаоса в рабочем окружении, большее количество времени и энергии на деятельность, инновации и проактивность.
    УСТАНОВКА МЕТРИК ДЛЯ ПОСТОЯННОГО СОВЕРШЕНСТВОВАНИЯ CMDB
    УСТАНОВКА МЕТРИК ДЛЯ ПОСТОЯННОГО СОВЕРШЕНСТВОВАНИЯ CMDB
    На данном этапе необходимо установить метрики для контроля эффективности управления CMDB и поддерживающими процессами, а так же услугами и процессами, которые используют CMDB.

    Необходимо установить метрики на трех уровнях. На первом уровне необходимо выявить метрики, которые отражают цели и задачи, поставленные бизнесом (например, сниженное среднее время между сбоями, достигнутое за счет предоставления CMDB точных данных о КЕ, которое выражается в экономии суммы на Х). На втором уровне необходимо выявить метрики, которые помогут владельцам процесса управления конфигурациями и активами управлять процессом и совершенствовать его. На третьем уровне необходимо выявить метрики, требуемые всеми заинтересованными лицами, включая владельцев других процессов, которые взаимодействуют с данными CMDB. Следует сфокусировать метрики на таких аспектах, как контроль, ценность, качество и производительность.
    • Среди потенциальных метрик для CMDB могут быть:
      • Процентное отношение КЕ, информация по которым обновляется и проверяется автоматически.
      • Удовлетворенность пользователей.
      • Количество неиспользуемых лицензий.
      • Количество запросов на изменение, завершившихся неудачно из-за некорректных данных в CMDB.
      • Количество неавторизованных конфигураций.
      • Количество инцидентов произошедших вследствие изменения, которые было неудачно выполнено из-за некорректных данных в CMDB.
      • Количество нарушенных Соглашений об уровне услуги из-за ошибок в CMDB.
      • Процентное отношение КЕ с неточной информацией.
    • Информация о CMDB и процессе управления конфигурациями может быть выражена следующими показателями:
      • Количество КЕ по категории, типу, версии и статусу.
      • Прирост КЕ и производительность CMDB.
      • Частота изменения информации о КЕ.
    • Точность информации, хранящейся в CMDB, может быть проверена по:
      • Результатам аудита конфигураций, включая информацию по не зарегистрированным или неправильно зарегистрированным КЕ, обнаруженным в ходе аудита.
      • Отчетам об устаревании КЕ, содержащим информацию о КЕ, которые не были изменены или обновлены в течение некоторого периода времени.
      • Исследованным инцидентам и проблемам, указывающим на неэффективность процесса управления конфигурациями.
      • Процентному отношению изменений, которые были проведены в обход процесса управления изменениями.
      • Запросам на изменение, которые закончились неудачей из-за неточного анализа влияния, некорректных данных в CMDB или слабого контроля версий.
      • Количеству изменений/обновлений КЕ в месяц из-за ошибок в CMDB.
    На основе выявленных метрик необходимо создать программу постоянного совершенствования. Концепция программы постоянного совершенствования обманчиво проста: собрать ключевые метрики, установить цели, систематически выявлять корневые причины проблем, внедрять исправления, отслеживать и сообщать о прогрессе.

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

    Необходимо помнить, что показатели CMDB позволяют измерять и отслеживать степень зрелости остальных процессов управления.
    ВЕНДОРЫ
    О КОМПАНИИ
    office@cfi.cloud
    Согласие на обработку
    персональных данных

    © 2009-2024 "CFI"
    Подписаться на новости