Что могут описывать атрибуты конфигурационных единиц в cmdb
Планирование Внедрения. Управление изменениями, активами и конфигурациями в рамках Внедрения
8.3. Управление активами и конфигурациями
Для того чтобы управлять конфигурационными единицами, их нужно определить и классифицировать. ITIL рекомендует следующие категории:
Для управления совокупностью активов Управление активами и конфигурациями ведет Систему управления конфигурациями.
Деятельности в рамках Управления активами и конфигурациями показаны на рис. 8.4.
Рассмотрим подробнее деятельности, представленные на рис. 8.4.
Управление и планирование
Не существует единого шаблона для осуществления SACM. Менеджеры каждой организации устанавливают уровень Управления конфигурациями, приемлемый для конкретного случая и то, как его можно достичь. Это отображается в Плане управления конфигурациями.
Пример содержания Плана управления активами и конфигурациями.
Применяемые политики и стандарты:
Организация Управлением конфигурациями:
Система и инструменты Управления активами и конфигурациями.
Процессы и процедуры в рамках Управления активами и конфигурациями, например:
Ссылка на План реализации
Управление и контроль необходимых связей и интерфейсов, в частности, с финансовым управлением активами и поставщиками[16].
Для идентификации конфигураций важно:
Деятельность в рамках идентификации конфигураций включает в себя:
Всем конфигурационным единицам необходимо назначить имена, состоящие из идентификатора и версии. Имена должны быть уникальными. Помимо этого все физическое оборудование должно иметь бирки, по которым их можно будет легко идентифицировать.
Атрибуты конфигурационных единиц описывают характеристики, значимые в рамках SACM. В базе данных должны содержаться атрибуты каждой конфигурационной единицы. ITIL выделяет следующие стандартные атрибуты:
Основные связи между CI:
CI может иметь множество связей. Например, быть частью другой CI и одновременно использоваться другими CI.
Контроль конфигураций предоставляет механизмы контроля для конфигураций. CI не может быть перемещена, изменена, удалена без соответствующего контроля. Процедуры и политики контроля включают в себя:
Механизмы контроля должны быть спроектированы и встроены в новую или измененную услугу на ранних этапах ее развертывания.
Выделяют следующие статусы:
Необходимо четко определить, как CI будет переходить из одного статуса в другой. Пример жизненного цикла приложения на рис. 8.5.
Учет статусов обеспечивает корректность и актуальность записей о конфигурационных единицах, активах и их состояниях. Стандартные деятельности в рамках Учета состояний:
Запись о конфигурации создается в процессе идентификации и контроля CI, рассмотренных нами выше. Она обеспечивает прозрачность и трассируемость CI для всех процессов. Стандартная запись содержит следующее:
Включает в себя набор следующих проверок:
Только авторизованные и корректные CI должны использоваться для поддержки услуг. Если в рамках проверок выявлены нарушения, они должны быть немедленно устранены, а результаты проверок отображены в соответствующих отчетах.
Как и любой другой процесс, SACM имеет свои ключевые показатели производительности. Применяются следующие метрики:
Информацию, формируемую в рамках SACM, используют все процессы в рамках жизненного цикла услуг.
CMDB в системе управления ИТ-услугами
Несмотря на интерес к ITSM и понимание преимуществ централизованного хранилища данных о конфигурации ИТ-инфраструктуры, практическая реализация данных подходов зачастую сталкивается с рядом трудностей. Стоит ли сейчас заниматься внедрением систем управления конфигурациями? А если стоит, то как?
В условиях экономической нестабильности ИТ-руководитель вынужден «балансировать» между растущими требованиями бизнеса к уровню ИТ-услуг и жесткими ограничениями финансирования. Могут ли помочь рекомендации ITIL в создавшихся условиях и надо ли сейчас думать о системах управления конфигурациями? Чтобы помочь в поиске ответов, рассмотрим рекомендации второй и третьей версий библиотеки ITIL и приведем некоторые практические советы по подходам к реализации базы данных управления конфигурациями (Configuration Management Data Base, CMDB) и связанных с ней процессов.
Управление конфигурациями
В России сегодня очень популярны рекомендации библиотеки ITIL v2, в которой CMDB занимает важное место для процессов, связанных с поддержкой ИТ-услуг (на рис. 1 выделены синим). К основным функциям CMDB в соответствии с ITIL v2 относятся: хранение информации по объектам ИТ-инфраструктуры в форме конфигурационных единиц (КЕ); поддержка связей между КЕ, связей КЕ с инцидентами, проблемами, изменениями и релизами; контроль версий КЕ; поддержка «базовых линий» КЕ и «снимков состояния» CMDB. Все это позволяет получить ряд преимуществ, ключевыми из которых являются: улучшение отчетности по ИТ-инфраструктуре, сокращение сроков устранения инцидентов и сокращение количества сбоев ИТ (таблица 1).
Версия ITIL v2 была не лишена недостатков, в частности, каталог услуг вынесен за пределы CMDB, что сказывается на качестве расчета их стоимости. Кроме того, недостаточно внимания уделено управлению жизненным циклом ИТ-активов (движение активов между материальноответственными лицами и т.д.).
ITIL на российских предприятиях
Реализация рекомендаций ITIL у нас в стране зачастую наталкивается на специфику отечественных предприятий.
Процессы не определены на стороне бизнеса. Это характерно для крупных промышленных предприятий, унаследовавших функциональную модель управления еще со времен плановой экономики. Сложно формализовать ИТ-услуги и оценить степень их влияния на бизнес.
Нехватка кадров. Процессные методы управления требуют наличия выделенных ответственных лиц, курирующих функционирование процессов. В случае отсутствия таких лиц регламенты процессов будут существовать только на бумаге.
Нехватка средств. Бизнес в ряде случаев не заинтересован в управлении ИТ-услугами (исключение – компании, предоставляющие ИТ-услуги внешним заказчикам), поэтому каталоги услуг, и особенно соглашения об уровне сервисов, приобретают формальный характер. Внедрение средств управления конфигурациями и изменениями считается «внутренним делом ИТ» и не находит поддержки со стороны бизнеса.
ИТ-специалисты не заинтересованы в управлении конфигурациями/изменениями. Данные процессы (в отличие, например, от процесса «Управление инцидентами») требуют от ИТ-специалистов соблюдения определенных бюрократических процедур, снижают их статус «незаменимых», а преимущества от внедрения этих процессов, особенно на ранней стадии, не очевидны.
ИТ-руководитель не заинтересован в реализации процессов ITIL. В ряде случаев политика «затыкания дыр» отнимает все время ИТ-руководителя, и на внедрение передовых практик не хватает времени и ресурсов.
В результате многие проекты в области ITSM ограничиваются реализацией службы Service Desk, процесса «Управление инцидентами» и части процесса «Управление уровнем услуг» (Каталог услуг без стоимости и без привязки услуг к инфраструктуре) (рис. 1). Реже внедряется процесс «Управление конфигурациями», который зачастую вырождается в «Управление активами» и занимается исключительно задачами учета техники. При этом вследствие низкого уровня зрелости процесса «Управление изменениями» актуальность данных по ИТ-активам, как правило, остается низкой, что требует значительных трудозатрат на инвентаризацию и подготовку отчетов по ИТ-инфраструктуре. В данном случае достигаются (в той или иной степени) цели, связанные с улучшением качества учета в сфере ИТ (таблица 1, строка 1), но не достигаются цели, связанные с повышением качества ИТ-услуг (таблица 1, строки 2, 3).
ITIL v3
В новой версии ITIL процессы управления ИТ сгруппированы в соответствии с жизненным циклом услуг, предоставляемых бизнесу. При этом обеспечивается непрерывный цикл улучшения ИТ-услуг, от их замысла и планирования до проектирования, преобразования и эксплуатации (рис. 2).
В соответствии с ITIL v3, процессы управления ИТ на каждой стадии жизненного цикла услуги взаимодействуют с центральным хранилищем данных, называемым «Система управления знаниями по услугам» (Service Knowledge Management System, SKMS) (рис. 3).
SKMS представляет собой комплексную систему, включающую в себя как записи, связанные с различными процессами: заявки на предоставление доступа к услугам, инциденты, проблемы, ошибки, изменения, релизы и т.д., так и сведения о различных типах каталогов услуг, соглашения: SLA, OLA (Operational Level Agreement – «соглашение операционного уровня»), UC (Underpinning Contracts – «внешние договоры») и сведения о поставщиках внешних услуг. В состав SKMS может входить одна или несколько CMDB, каждая из которых наследует все свойства и функциональные возможности, регламентированные для CMDB ITIL v2. Совокупность технических средств (инструментов, баз данных), обеспечивающих хранение и обработку информации в составе SKMS, называется системой управления конфигурациями (Configuration Management System, CMS). Источники информации, используемой в рамках SKMS, могут относиться к различным системам и приложениям, включая CRM, ERP и SCM. Консолидацию данных различных систем в рамках SKMS обеспечивает «интеграционный уровень» (рис. 3). При этом основным принципом интеграции является минимизация дублирования информации при сохранении ее полноты и обеспечении «прозрачности» и оперативности доступа. Уровень обработки данных предоставляет средства моделирования, анализа, мониторинга и отчетности. На этом уровне обеспечиваются логические связи между данными из различных источников. На уровне представления знаний с системой взаимодействуют конечные пользователи, осуществляющие выполнение поиска, обновление и публикацию информации.
За счет более комплексной интеграции данных в рамках SKMS и выделения нескольких новых процессов, более точно и полно отражающих реалии работы ИТ-подразделений (в частности, добавлены процесс, регламентирующий доступ пользователей к ИТ-услуге, процесс обработки событий, которые не относятся к инцидентам, и т.д.), библиотека ITIL v3 позволяет устранить часть недостатков второй версии и получить дополнительные преимущества (таблица 1): обеспечить «прозрачную» структуру стоимости ИТ-услуги; обеспечить «прозрачную» структуру связей между заявками, услугами и другими КЕ в сочетании с более гибкой системой анализа информации в рамках SKMS. Это позволяет в большей степени сократить сроки устранения инцидентов и сроки обработки заявок других типов, а также в большей степени сократить количество сбоев в работе ИТ-инфраструктуры.
К недостаткам ITIL v3 можно отнести слабое отражение вопросов, связанных с управлением жизненным циклом ИТ-активов (таблица 1). Несмотря на то что процесс «Управление конфигурациями» (ITIL v2) в ITIL v3 переименован в процесс «Управление активами и конфигурациями», практические рекомендации затронули главным образом жизненный цикл ИТ-услуги. Жизненные циклы других ИТ-активов, практическое значение которых как минимум не ниже ИТ-услуг, отражены слабо.
Библиотека лучших практик
Реализацией более комплексной по сравнению с ITIL методологии по управлению ИТ-активами занимается Международная ассоциация по управлению жизненным циклом ИТ-активов (International Association of Information Technology Asset Management, IAITAM). Силами ассоциации, объединяющей несколько десятков компаний, разработана библиотека лучших практик IBPL, состоящая из 12 книг, которые регламентируют все основные процессы, связанные с управлением ИТ-активами: управление активами, программами, проектами, документацией, политиками, коммуникациями, финансами и т.д. Часть процессов, регламентированных в IBPL, «пересекается» с процессной моделью ITIL, уточняя и дополняя последнюю.
Жизненный цикл ИТ-актива состоит из статусов и переходов. Статус отображает фиксированное состояние актива на схеме жизненного цикла, например «Запланировано», «Заказано», «Получено», «Утилизировано». Переходы между статусами представляют собой цепочки действий (которые могут быть автоматическими) или работ (выполняемых вручную), обеспечивающие соответствующее изменение статуса. Например, оплата счета поставщику, приемка техники на склад, инсталляция операционной системы и т.д. Вся информация об активе, о схеме его жизненного цикла, связанных с ним активах, поставщиках, история всех действий и работ хранится в CMDB, которая может быть включена в состав SKMS в рамках комплексной системы управления ИТ-услугами.
Разработка требований к CMDB и CMS
Сформулируем рекомендации ИТ-менеджерам, планирующим внедрение или оптимизацию сервис-ориентированных подходов к управлению ИТ, а также предложим упрощенную методологию, направленную на снижение затрат на всех стадиях эксплуатации CMDB и CMS.
Общий принцип методики звучит так: «Движемся от требований бизнеса к выбору системы, а не наоборот», а сама методика состоит из пяти шагов.
Шаг 1. Определение основных услуг, предоставляемых бизнесу. На данном шаге перечисляются ИТ-системы, наиболее критичные для бизнеса (см. пример в графе 2 таблицы 2), и для каждой из них формулируется ответ на вопрос: «Что будет, если система прекратит работать на некоторое время?» Интервал времени можно задать исходя из статистики подобных сбоев (если она есть) или исходя из экспертной оценки максимального срока восстановления системы от ИТ-специалистов. Результат заносится в графу 3 таблицы 2 в виде названия процесса или услуги в терминологии, понятной бизнесу. Затем по каждой услуге определяется наиболее полный список ИТ-систем, которые также могут привести к сбою. Далее заполняется графа 4 таблицы 2, куда вносится стоимость остановки предоставления соответствующей услуги на максимальный из возможных интервалов времени. Такую оценку можно получить у бизнес-пользователей соответствующей услуги, например, это могут быть штрафные санкции за задержку отчета в налоговую инспекцию. В результате в графе 2 формируется заготовка каталога технических услуг, а в графе 3 – заготовка каталога бизнес-услуг, предоставляемых ИТ-службой (рис. 4). Кроме того, получается стоимостное выражение рисков, связанных с работой ИТ-систем, а на основании полученной стоимости рисков можно принять решение о целесообразности дальнейших работ.
Шаг 2. Определение процессов, подлежащих оптимизации средствами CMS. На данном шаге перечисляются процессы, которые планируется оптимизировать за счет применения CMS, и цели, которых надо достичь по каждому процессу (таблица 3). Кроме того, по каждому процессу необходимо зафиксировать куратора – человека, обладающего достаточными полномочиями, авторитетом и временем для контроля выполнения процедур процесса на стадии его эксплуатации. Если мы затрудняемся указать куратора по процессу или не можем четко сформулировать цели реализации процесса, то с большой вероятностью он не будет работать на практике.
Шаг 3. Определение требований к CMDB. На данном шаге определяется «охват» CMDB: классы объектов, которые будут учитываться в рамках автоматизируемых процессов, и зона учета (площадки, ЦОД, подразделения и т.д., по которым будет производиться учет) (рис. 4). Охват CMDB может изменяться с течением времени, поэтому рекомендуется определить этапы расширения охвата. На первом этапе целесообразно включать в CMDB только те КЕ, информация по которым необходима для повышения качества (скорости обработки заявок, снижения количества сбоев после изменений) по наиболее критичным услугам, перечисленным в таблице 2.
Результаты работы сводятся в «Классификатор конфигурационных единиц» (таблица 4) при дополнении каждого класса КЕ описанием принципа присвоения ему уникального имени. Это имя впоследствии будет использоваться для идентификации КЕ в CMDB и для маркировки физического объекта, связанного с КЕ (например, идентификатор ПК, проставляемый на его корпусе). Сведения о зоне охвата и этапе реализации заносятся в графу «Примечания» таблицы 4.
Сформируем теперь требуемый набор связей между КЕ в виде логической модели данных CMDB, пример которой приведен на рис. 5. Модель должна содержать все классы CMDB, перечисленные в классификаторе (таблица 1), и все связи между КЕ. При формировании связей необходимо руководствоваться принципом «Замкнутая цепочка влияния»: двигаясь по цепочке связей, всегда нужно иметь возможность получить полный перечень КЕ, на которые повлияет изменение (остановка) текущего КЕ. В результате работы над логической моделью данных может быть изменен состав классов КЕ в таблице 4. Связи между КЕ могут иметь различные типы (например: «Содержит в составе», «Материально ответственный» и т.д.). Связи могут отражать влияние одной КЕ на работу другой КЕ, в этом случае их можно будет учитывать при анализе последствий изменений. Перечень полученных связей сводится в классификатор.
Сформируем перечень атрибутов для каждого класса конфигурационных единиц в форме, приведенной в таблице 5. Для каждого атрибута определим источник (источники) актуальных данных (например, LANDesk Inventory manager – для ПК и серверов, Cisco Works – для сетевого оборудования, MS Active Directory + Кадры – для пользователей и т.д.). Не следует дублировать всю информацию внешнего источника в CMDB. Набор атрибутов должен быть минимально необходимым для обеспечения оперативной обработки инцидентов и анализа изменений. Кроме того, обязательно должны быть атрибуты, однозначно идентифицирующие каждый КЕ во всех внешних источниках информации по нему и атрибуты-связи в соответствии с рис. 5. Если автоматизированных средств заполнения информации по атрибуту или связи нет, то необходимо указать процедуру процесса, в рамках которой актуальность значения данного атрибута будет поддерживаться вручную. Следует учитывать, что чем больше атрибутов, поддерживаемых вручную, тем выше трудоемкость (и стоимость) эксплуатации системы, тем ниже актуальность данных в CMDB и тем меньше эффект от реализации CMS. В случае если нельзя определиться с источником данных по какому-либо атрибуту (или по целому классу КЕ), его следует исключить из CMDB, так как неактуальная информация дискредитирует систему в глазах пользователей на стадии эксплуатации.
Шаг 4. Составление перечня требований к системе. На этом шаге формулируются требования к системе, посредством которой планируется автоматизировать процессы управления ИТ в форме таблицы. Требования целесообразно группировать по автоматизируемым процессам. Следует учитывать требования по интеграции с имеющимися системами, требования к отчетности, к пользовательским интерфейсам и т.д. Таблицу описания можно дополнить столбцами для указания источника требования (для какой группы специалистов или менеджеров требование актуально) и его весового коэффициента (обязательное/желательное). Требования к системе должны быть направлены на повышение качества услуг, которые мы сформировали на первом шаге.
Шаг 5. Формулировка критериев выбора системы. На предыдущих шагах мы получили подробный перечень требований к СMS и описание CMDB. Процесс сравнения большого количества систем по полному перечню требований может занять много времени, поэтому целесообразно сформировать набор наиболее общих и важных критериев для получения «короткого списка» систем на основании полученной на предыдущем шаге таблицы и провести первоначальный выбор по этим критериям. В качестве дополнительных критериев отбора могут быть использованы: гибкость (возможность изменения глубины и охвата CMDB на стадии эксплуатации, гибкость настройки пользовательских интерфейсов и т.д.), цена (включая лицензии, внедрение, поддержку, обновление версий, обучение), надежность регионального поставщика и разработчика системы. На российском рынке представлены как комплексные системы (Service Desk + CMDB) наподобие Axious Systems assyst, BMC Remedy, LANDesk Service Desk, Naumen Service Desk, OmniNet Omnitracker, так и специализированные решения: HP Universal CMDB (CMS c гибкими интеграционными возможностями) и LANDesk Asset Lifecycle Manager (CMDB и средства реализации методологии IBPL).
Любая методология, будь то ITIL или IBPL – это лишь набор общих рекомендаций, основанных на передовых практиках, и от того, насколько грамотно данные рекомендации применены в условиях конкретной компании, во многом зависит эффективность и жизнеспособность полученных процессов управления ИТ. В статье был рассмотрен один, хотя и немаловажный, элемент системы автоматизации данных процессов – CMDB. Следует понимать, что CMDB, как бы грамотно она ни была спроектирована и какие бы комплексные системы ни лежали в основе ее функционирования, не даст положительного эффекта без реализации гибких и адаптируемых к условиям компании процессов управления ИТ. С другой стороны, грамотно выстроенные процессы управления ИТ в сочетании с комплексной системой управления конфигурациями позволяют получить значительное снижение трудозатрат на поддержку ИТ и повысить надежность и качество ИТ-услуг.
Управление конфигурациями
Создание конфигурационной базы данных
Как правильно подойти к вопросу построения корпоративной CMDB
В статье приведено описание различных типов данных, обычно хранящихся в CMDB от конфигурационных элементов (CI) и их взаимосвязей до смежных данных, такие как запросы на изменения и модель влияния на услуги.
Почему CMDB
В ходе предоставления надежных услуг, обслуживающих коммерческие цели компании, ИТ-подразделения сталкиваются с большим количеством сложных вопросов. Для решения большинства из них необходима хорошая стратегия управления конфигурациями: не обладая знаниями о собственной среде, невозможно управлять, обслуживать и модернизировать ее.
Согласно руководству по поддержке услуг, основанных на ITIL, управление конфигурациями должно преследовать следующие цели:
Достижение этих целей позволяет организации эффективно осуществлять управление, интеграцию и поддержку принятия решений. В частности:
Данные это ключевой фактор
Начать управление конфигурациями можно с любого из уже упомянутых процессов или нескольких других. Независимо от того, какие процессы управления конфигурациями внедряются, эффективными их делают используемые ими данные.
Конфигурационные данные должны быть точными, что означает необходимость их постоянного обновления. Конфигурации постоянно изменяются. Данные, которые были верными на прошлой неделе, могут устареть на этой, что может привести к покупке 10 серверов при необходимости покупки 5 или, что еще хуже, к установке файла исправлений, который вызовет сбой в системе.
Конфигурационные данные должны быть доступны для всех ИТ-процессов. Даже самые точные данные бесполезны, если нельзя получить доступ к ним. Например, если данные о топологии сети, предоставленные поисковым приложением, недоступны для приложения управления изменениями, невозможно грамотно спланировать перекомпоновку сети.
С годами концепция CMDB эволюционировала от набора обособленных хранилищ данных и интегрированных хранилищ данных в единую, централизованную базу данных, с каждым этапом приближаясь к базе данных, которая может являться источником записей для конфигурационных данных без ущерба для инфраструктуры.
Первоначально CMDB состояла из нескольких приложений, в которых хранились собственные данные и зачастую данные других баз с конфигурационными данными, как показано на рисунке.
Другим недостатком было отсутствие единой точки входа. Поэтому для того, чтобы получить какие-либо данные, нужно было знать, где они находятся, и как получить к ним доступ. Наконец, такой подход не позволял хранить информацию о взаимосвязях конфигурационных элементов.
Затем ИТ-организации стали создавать CMDB путем прямой интеграции различных источников данных и приложений, связывая каждое приложение-поставщика данных с приложением-потребителем, которому необходимы его данные, как показано на рисунке ниже.
Такой подход позволил одновременно использовать данные в различных процессах управления конфигурациями, что значительно повысило полезность CMDB. Но такой подход требовал больших ресурсов для создания и обслуживания интегрированного хранилища данных. Кроме того, как и при работе с обособленными хранилищами данных, некоторые пользователи, незнакомые с системой, могли не знать, где искать необходимые данные.
Не так давно поставщики предлагали единую, всеобъемлющую CMDB для хранения конфигурационных данных, доступную для всех приложений, которым необходимы эти данные.
При таком подходе любое приложение-потребитель и приложение-поставщик данных, интегрированное в CMDB, имеет доступ ко всем данным, относящимся к конфигурации, что обеспечивает более высокий уровень совместного использования данных, чем в подходе, предусматривающем интеграцию хранилищ данных. CMDB предоставляет единую точку входа. Т.е. CMDB становится источником записей, которому пользователи направляют все запросы.
Но и всеобъемлющая база данных не лишена недостатков. Необходима большая работа по сведению всех данных в единую базу для создания сложной модели данных, которая должна изменяться при изменении любого интегрированного в CMDB приложения. При этом, если приложения приобретаются не у того же поставщика, что и CMDB, их интеграция становится чрезвычайно сложной задачей.
Рекомендованный подход к созданию и применению CMDB
Содержимое CMDB согласно ITIL
Взаимосвязи между конфигурационными элементами
Данные о взаимосвязях делают CMDB мощным средством поддержки принятия решений. Понимание зависимостей и прочих взаимосвязей между конфигурационными элементами помогает оценить, например, как модернизация процессора А повысит производительность сервера Б или какие серверы выпадут из работы при сбое маршрутизатора С. Большинство простоев вызвано проблемами, возникающими в результате изменения конфигурации, а такая информация позволяет их избежать.
Смежные данные
К конфигурационным элементам имеет отношение большое количество информации, такой как обращения в службу технической поддержки, события изменений, договоры, соглашения об уровне обслуживания (SLA), библиотека эталонного ПО (DSL) и многое другое. Хотя эти единицы сами по себе не являются конфигурационными элементами, они содержат информацию о конфигурационных элементах и формируют важную часть ИТ-инфраструктуры.
Структура идеальной среды CMDB
CMDB и ее инфраструктура должна быть разделена на 3 уровня.
Уровни «CMDB» и «Расширенные данные CMDB» образуют то, что понимается в ITIL как CMDB. Выделение этих двух уровней отличает интегрированный подход от предложенного подхода.
Уровень «CMDB» содержит только конфигурационные элементы и их взаимосвязи, но некоторые их атрибуты могут быть привязаны через ссылки к расширенным данным CMDB. Не все имеющиеся атрибуты конфигурационных элементов должны храниться в CMDB: Желательно хранить в CMDB только основные атрибуты, а для менее важных использовать расширенные данные CMDB.
Даже если в CMDB не хранятся все данные атрибутов или смежные данные, CMDB продолжает служить источником записей для конфигурационных данных благодаря ссылкам на расширенные данные CMDB. Можно все запросы адресовать CMDB и, в случае, если необходимые данные хранятся не в CMDB, пользователь может найти ссылки, указывающие на место хранения данных или на способ получения доступа к ним.
В расширенных данных CMDB содержатся данные, перечисленные в пункте «Смежные данные» данной статьи, а также другие атрибуты конфигурационных элементов, которые нецелесообразно хранить в CMDB.
Данные уровня «Расширенные данные CMDB» связаны ссылками с данными конфигурационных элементов в CMDB. По определению, к интегрированным атрибутам конфигурационных элементов ведут ссылки от их экземпляров в CMDB, позволяя запросам к CMDB получать доступ к этим атрибутам. Но для других типов расширенных данных эта ссылка может быть как одно-, так и двусторонней.
Например, запись запроса на изменение может иметь ссылку, посредством которой пользователь может получить доступ к экземплярам конфигурационных элементов, подлежащих изменению, а каждый экземпляр конфигурационного элемента может иметь ссылку, через которую пользователь может получить доступ к запросам на его изменение.
Это дает ряд преимуществ:
Возможности CMDB
Но даже при правильной структуре для эффективного управления конфигурационными элементами CMDB необходимо следующее:
1. Интеграция данных
Под термином «интеграция» подразумеваем хранение некоторых данных непосредственно в центральном репозитории с доступом к данным из других источников по ссылкам.
Некоторые атрибуты можно интегрировать для их отслеживания, но не настолько частого или внимательного, как и ключевые атрибуты конфигурационных элементов. Эти вторичные атрибуты относятся к первому из двух типов данных, которые можно интегрировать. Это означает, например, что запись CMDB о сотруднике может содержать атрибут «Навыки» со списком навыков сотрудника, а также атрибут «Отдел» с названием отдела, в котором работает сотрудник. Эта запись также может быть связана с хранилищем данных о персонале, где хранятся дополнительные атрибуты, не представляющих важности для конфигурации, например, «Заработная плата».
К другому типу относятся данные, относящиеся к конфигурационным элементам, но фактически не являющиеся атрибутами конфигурационных элементов. Т.е. данные, ссылающиеся на конфигурационные элементы, или данные, на которые конфигурационные элементы ссылаются, для обеспечения дополнительного наполнения расширенной функциональности конфигурационных элементов, но сами не являющиеся частью конфигурационных элементов.Например, конфигурационные записи о копиях программного обеспечения могут иметь ссылку на лицензию, содержащую URL-адрес внутрикорпоративной сети, по которому находится лицензия, или каждая конфигурационная запись может иметь ссылку на проблему, в которой содержится информация, необходимая для поиска в базе данных проблем всех событий, касающихся данного конфигурационного элемента.
2.Гибкая модель данных
В объектно-ориентированной модели данные иерархически выстроены по классам, и каждый класс наследует атрибуты своего суперкласса (т.е. класса более высокого уровня в иерархии) и добавляет собственные атрибуты для создания более специфичного типа объекта, т.е. подкласса. Подклассы могут иметь собственные подклассы, продолжая иерархию до любого уровня детализации, которую необходимо отследить.Например, класс «Компьютерная система» может содержать атрибуты «Домен», «Тип процессора» и «Производитель». Класс «Компьютерная система» может содержать подклассы «Ноутбук», «Настольный компьютер» и «Центральная ЭВМ». Каждый из этих подклассов имеет три атрибута своего суперкласса плюс атрибуты, присущие только им. На рис. 6 показана часть объектно-ориентированной модели данных CMDB, включающая суперкласс и подклассы двух уровней.
К преимуществам объектно-ориентированной модели данных относятся применение общих для конфигурационных элементов одного типа атрибутов, а также возможность поиска за пределами определенного класса конфигурационных элементов в любой ветви иерархии. Если модель данных имеет один базовый класс, по отношению к которому все другие являются подклассами, пользователь может найти все конфигурационные элементы и их взаимосвязи.
3.Расширяемая модель данных
Ваша инфраструктура и технология, на которой она построена, постоянно изменяются. Это означает, что типы конфигурационных элементов и взаимосвязи в CMDB должны также изменяться, поэтому возникает необходимость в расширяемой модели данных. Необходимо иметь возможность добавлять и удалять атрибуты из классов и даже добавлять и удалять классы.
Несмотря на важность данной функции, не следует ею злоупотреблять. CMDB должна содержать только общие конфигурационные элементы и их взаимосвязи. Добавление классов и атрибутов незначительных конфигурационных элементов без необходимости нагружает CMDB. Создание слишком глубокой структуры подклассов может привести к образованию настолько узко определенных классов, что к ним будут относиться всего лишь несколько членов. Соблюдайте баланс между необходимостью классификации и совместного хранения схожих конфигурационных элементов.
4.Декомпозиция конфигураций
Декомпозиция дает возможность разделения конфигурационных данных на наборы данных, каждый из которых представляет собой набор данных в определенный момент времени. Это позволяет одним и тем же экземплярам конфигурационных элементов и взаимосвязей существовать более чем в одном наборе данных.
Данная функция важна для проверки и приведения конфигурационных записей в соответствие с инфраструктурой. Можно создать один набор данных, представляющий намеченную конфигурацию, затем при помощи поискового приложения создать другой набор данных, представляющий собой фактическую конфигурацию, и сравнить одну конфигурацию с другой.
5.Синхронизация конфигураций
При наличии более чем одного набора данных, содержащих одинаковые экземпляры, синхронизация является процессом идентификации совпадающих экземпляров во всех наборах данных и их последующего сравнения с другими версиями каждого экземпляра и создания отчета о различиях, либо объединения наборов данных в новый набор. Это позволяет проследить изменения во времени или определить необходимую конфигурацию при наличии данных из нескольких поисковых источников.
6.Открытый доступ к данным
Как было упомянуто выше, даже самые точные данные бесполезны, если невозможно получить доступ к ним. Важно помнить, что пользователям и приложениям необходимо разрешить чтение и запись в CMDB. Приложения-потребители просматривают и изменяют существующие данные, а приложения-поставщики создают и изменяют эти данные.
Для этого требуются, по меньшей мере, перечисленные ниже функции:
Заключение
В заключении перейдем от теории к практике. На нашем сайте представлены два вендора, комбинация которых прекрасно иллюстрирует вышеприведенный материал. BMC Atrium CMDB является одной из лучших моделей CMDB, которая прекрасно интегрирована с продуктами BMC ITSM Suite. ПО FNT Software предоставляет мощные средства для управления активами и инфраструктурой компании. В зависимости от задачи, комбинация этих продуктов для уровней CMDB и расширенного уровня CMDB позволяет создавать решения, сочетающие в себе все вышеперечисленные свойства идеальной CMDB предприятия.
Дополнительная информация по BMC Software представлена на сайте в разделе Партнеры / BMC Software
Дополнительная информация по FNT Software представлена на сайте в разделе Партнеры / FNT Software