CMDB: что это такое и зачем нужна база конфигураций

Что это значит на практике

CMDB — сокращение от английского configuration management database, по-русски «база данных управления конфигурациями»; в разговоре — просто база конфигураций. ИТ-услуга — это, например, корпоративная почта или система расчёта зарплаты. В CMDB записано, из чего каждая такая услуга состоит и от чего зависит — серверы, программы, сети, лицензии, договоры, люди — и как эти части связаны между собой. Список серверов есть и в инвентарной описи; CMDB отличается тем, что хранит связи. На этом сервере работает система расчёта зарплаты, бухгалтерии она нужна в понедельник — значит, выключать сервер в воскресенье нельзя. CMDB не выключает сервер и не защищает его сама: она даёт сведения, по которым люди принимают решение — при разборе сбоя, оценке последствий планируемого изменения, расчёте стоимости услуги.

Как расшифровывается CMDB

Configuration management database — три слова, и каждое отвечает на свой вопрос.

Configuration — конфигурация: из каких частей состоит услуга и как они соединены. Это состав целиком: сервер, база данных на нём, приложение, сеть, договор с поставщиком и сведения о том, кто за что отвечает, а не одни «настройки сервера», как часто думают. Management — управление: эти сведения постоянно ведут и проверяют, а не записали однажды при внедрении CMDB. Database — база данных: сведения собраны так, что их можно найти и получить, а не держать в головах и переписке.

ITIL 4, свод практик управления ИТ-услугами, определяет CMDB как базу записей об элементах конфигурации на протяжении всего их жизненного цикла — от закупки до списания, — включая связи между этими записями. Элемент конфигурации (иногда говорят «конфигурационная единица») — это то, сведения о чём ведут в CMDB: сервер, программа, договор или услуга. По-английски — configuration item, сокращённо CI. FitSM, лёгкий стандарт управления ИТ-услугами, определяет короче: хранилище данных об элементах конфигурации. При этом стандарт оговаривает, что это не обязательно одно хранилище: их может быть несколько.

Единого русского имени у термина нет. В русском издании книги itSMF «Введение в ИТ Сервис-менеджмент» 2003 года это «Конфигурационная База Данных», у Брукса в «Метриках для управления ИТ-услугами» — «база управления конфигурациями». В русском переводе MOF 4.0 — «база данных конфигураций», в переводе DAMA-DMBOK — «база данных управления конфигурациями». Сокращение при этом не переводят: в изданиях itSMF, Брукса и DMBOK рядом с русским названием стоит латинское CMDB. Мы пишем «база конфигураций» и CMDB.

CMDB и CMS: база и система

В тех же источниках встречается и CMS — configuration management system, система управления конфигурациями. Их путают, и путаницу признаёт сам ITIL: в практическом руководстве ITIL 4 Service Configuration Management сказано, что эти термины нередко употребляют как взаимозаменяемые.

Разница такая. CMDB — хранилище записей об элементах и сведений об их связях. CMS — набор средств и данных, с помощью которых эти сведения ведут и используют: одна или несколько баз, средства сбора данных из разных источников, средства, которые связывают и показывают эти данные. ITIL 4 определяет CMS как набор инструментов и информации в поддержку практики управления конфигурацией услуг. Обычно, добавляет ITIL, это сложная система из нескольких решений и интеграций с источниками данных о конфигурации, а записи в ней хранятся в одной или нескольких CMDB. Книга ITIL 4 Foundation отдельно отмечает: вести все сведения в одной CMDB на всю организацию можно, но чаще они распределены между несколькими источниками — например, реестром активов, каталогом услуг и моделями услуг. Тогда главное — поддерживать связи между записями, чтобы человек видел полную картину, а не только её часть.

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

Зачем нужна CMDB

Что такое CMDB, лучше всего видно по тому, кто ею пользуется. Сама CMDB ничего не делает: пользу от неё получают другие практики — там, где на основе её сведений принимают решения. ITIL 4 называет пять применений модели конфигурации услуги — описания её частей и связей между ними:

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

За каждым пунктом стоит чужая работа — управление инцидентами, проблемами, изменениями, доступностью, финансами ИТ. Сама по себе CMDB заметного результата не даёт, и поэтому её первой сокращают, когда экономят: в отчётах не видно, сколько решений с её помощью приняли быстрее и сколько ошибок предотвратили. Книга ITIL 4 Foundation так и пишет: ценность управления конфигурацией косвенная, зато благодаря ей многие другие практики работают быстрее и точнее.

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

Что попадает в базу, а что нет

Единица хранения в CMDB — элемент конфигурации (CI). ITIL 4 определяет его как любой компонент, которым нужно управлять, чтобы предоставлять ИТ-услугу. ГОСТ Р ИСО/МЭК 20000-1-2021, национальный стандарт по управлению ИТ-услугами, в пункте 3.2.2 формулирует близко: «элемент, который необходимо контролировать для предоставления сервиса или сервисов» — сервисом ГОСТ называет услугу. Книга ITIL 4 Foundation перечисляет, что обычно попадает под это определение: техника, программное обеспечение, сети, здания, люди, поставщики, документация. Услуги тоже элементы: ГОСТ прямо требует классифицировать сервисы как элементы конфигурации.

Что не попадает, ITIL 4 объясняет одним правилом: границу учёта определяет соотношение пользы и затрат. Сведения об элементе ведут, пока польза от них оправдывает стоимость их получения и поддержания. Ресурсы, которыми нельзя управлять по отдельности, элементами конфигурации обычно не делают — в руководстве приведён пример: знания аналитика, разбирающего инциденты, важны, но отдельным элементом в CMDB их не заводят.

ГОСТ Р ИСО/МЭК 20000-1-2021 в пункте 8.2.6 требует записывать по каждому элементу пять сведений: уникальный идентификатор, тип, описание, связи с другими элементами и статус. Подробность — по критичности услуги (насколько тяжёлыми будут последствия её остановки) и её типу, а не по возможностям программы. Само слово CMDB в тексте ГОСТа не встречается. Стандарт требует, чтобы сведения о конфигурации были записаны и доступны, обновлялись после изменений и регулярно проверялись, — но не оговаривает, в каком именно хранилище их держать. FitSM-1 в требовании PR11.3 называет CMDB по имени: сведения об элементах и их связях ведутся в CMDB.

Связи важнее самих записей

CMDB, где перечислены тысячи устройств без связей, отвечает на вопросы про технику: какая она и сколько её. На вопрос «что сломается, если выключить вот этот сервер» она не отвечает — а ради него CMDB и заводили.

Пользователь пишет: «не открывается отчёт по продажам». Пока в CMDB только список серверов, путь от отчёта к серверу живёт в голове у администратора, который его когда-то настраивал. Когда в CMDB есть связи — отчёт формирует приложение, приложение читает базу данных, та работает на таком-то сервере, — дежурный прослеживает эту цепочку за минуту, не зная системы лично. Именно это ITIL 4 называет ключевой функцией системы управления конфигурациями: хранить записи об элементах и связи между ними.

Книга ITIL 4 Foundation предупреждает о ловушке, в которую попадают при автоматизации. Средства обнаружения умеют сами собрать подробные сведения об ИТ-инфраструктуре и приложениях и заполнить ими CMDB. Автоматическое заполнение работает, но одновременно подталкивает собрать слишком много данных без сведений о связях и о том, как части складываются в услугу. Отсюда порядок наполнения, который мы советуем: сначала связи между услугой и тем, на чём она держится, потом подробности по каждому элементу.

Как начать, если описать всё сразу невозможно

MOF 4.0 признаёт прямо: определить конфигурацию всей рабочей среды — задача сложная. И предлагает выход: снимать базовые показатели конфигурации при каждом изменении, а не описывать всё разом. Базовыми показателями MOF называет снимок ИТ-среды с её структурой и зависимостями, который делают перед внесением изменения; в конечном итоге, пишет MOF, из таких снимков складывается полная рабочая конфигурация. У ITIL 4 похожее понятие называется базовой конфигурацией — формально проверенное и согласованное состояние, с которым потом сверяют фактическое.

Логика простая. Сплошная инвентаризация даёт снимок, который начинает устаревать в день её завершения. Учёт, который пополняется по мере изменений, описывает ровно то, что живёт и меняется, и обновляется тем же действием, которым меняется среда. Этого же требует ГОСТ Р ИСО/МЭК 20000-1-2021: сведения о конфигурации актуализируются после внедрения изменений.

Второй путь, который мы видели в работе, — начинать с инцидентов: элементы, с которыми чаще всего связаны сбои, попадают в CMDB первыми и быстрее всего оправдывают затраты на учёт.

Как проверяют, что CMDB не врёт

CMDB говорит, что должно быть. Инвентаризация — обход или автоматическое обнаружение — показывает, что найдено на самом деле. Верификация — работа по поиску и закрытию расхождений между первым и вторым. Так ITIL 4 разводит три слова, которые обычно смешивают. Мысль старше ITIL 4. В книге itSMF «Введение в ИТ Сервис-менеджмент» (русское издание 2003 года) сказано то же: CMDB показывает, какой должна быть инфраструктура, если всё идёт по плану. А список расхождений между ней и бухгалтерским учётом книга называет источником ценных сведений.

При сверке ищут расхождения трёх родов: элементы, которых в CMDB нет; разрешённые изменения, которые в неё не попали, — признак того, что учёт элементов отстаёт от изменений; и несогласованные изменения — их сделали без положенного разрешения. ГОСТ Р ИСО/МЭК 20000-1-2021 требует проверять точность сведений через запланированные интервалы времени и что-то делать с найденными неточностями; FitSM-1 в требовании PR11.5 — проверять сведения в CMDB с запланированной периодичностью. Что делать с расхождением, ITIL 4 не предписывает и называет три пути:

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

Пути можно сочетать.

Автоматизировать сверку ITIL 4 советует везде, где возможно: автоматизация делает данные надёжнее и уменьшает потребность в проверке, но не отменяет её.

→ Управление конфигурациями. Инвентаризация, верификация и аудит как процесс практики: кто сверяет, как часто и что делать с расхождением.

Чем CMDB отличается от учёта активов

Управление ИТ-активами (по-английски IT asset management, ITAM) отвечает на вопросы владения и денег: чьё это, сколько стоило, когда списывать, хватает ли лицензий. CMDB отвечает на вопросы работы: из чего состоит услуга, что с чем связано, что пострадает следом. Один и тот же сервер часто попадает в оба учёта, но с разными сведениями: в активах — цена, поставщик и срок гарантии, в конфигурациях — роль, услуги, которые он поддерживает, и связи с другими элементами. Разница не новая: русское издание книги itSMF 2003 года предупреждало не путать CMDB со складскими и инвентаризационными базами данных — те знают, что куплено, но не знают, что от чего зависит.

ГОСТ Р ИСО/МЭК 20000-1-2021 держит два понятия рядом и разводит их примечанием к определению актива: актив может быть элементом конфигурации, а некоторые элементы конфигурации — не активы. Роль дежурного администратора — элемент конфигурации, но не актив; репутация компании, которую ГОСТ приводит в примерах нематериальных активов, — актив, но не элемент конфигурации.

Вести ли всё в одной системе — вопрос устройства, а не принципа. Книга ITIL 4 Foundation пишет, что реестр активов часто объединяют с системой управления конфигурациями или связывают их между собой. Если учёты раздельные, запись одного должна сопоставляться с записью другого — обычно по общим правилам именования. Смешение начинается не с общего хранилища. Оно начинается там, где учёт активов заползает в учёт конфигураций: в CMDB заводят мониторы и мыши только потому, что они стоят денег, а не потому, что от них зависит услуга. CMDB тонет в мелочах, про которые никто не спросит «что сломается, если это выключить».

→ Управление ИТ-активами. Что считается активом, жизненный цикл актива и реестр — соседний учёт, про деньги и владение.

Как понять, что база жива

Полнота базы — плохой показатель: она растёт и тогда, когда в CMDB свалили всё подряд. ITIL 4 строит показатели практики вокруг двух условий успеха: сведения полезны тем, кто ими пользуется, а затраты на их сбор, ведение и проверку соразмерны пользе. Отсюда и мера: не сколько записей в CMDB, а сколько решений приняли на основе её данных и сколько изменений не пришлось откатывать из-за ошибок в них.

Брукс в «Метриках для управления ИТ-услугами» измеряет не саму CMDB, а последствия ошибок в её данных. Среди его метрик управления конфигурациями:

• запросы на изменение, не выполненные из-за неверных данных в CMDB;
• инциденты из-за неправильно описанного элемента;
• нарушения SLA — соглашений об уровне услуг, — вызванные ошибками в CMDB;
• запросы на изменение, после которых запись об элементе так и не обновили;
• неавторизованные конфигурации, найденные при проверке;
• доля некорректных элементов;
• неиспользуемые лицензии — единственная метрика в этом ряду, которая считает не убытки от плохого учёта, а средства, которые хороший учёт помогает высвободить.

Данные почти для каждой из них берутся не из CMDB, а из управления изменениями и инцидентами — и именно поэтому такие показатели редко видны на панели показателей. Целевые и тревожные значения, приведённые у Брукса, разобраны на странице практики.

→ Управление конфигурациями. Пять показателей ITIL 4 и метрики Брукса с целевыми и тревожными значениями.

Что говорят другие своды

COBIT 5 — свод по руководству и управлению ИТ от ISACA, международной ассоциации специалистов по аудиту и управлению информационными системами, — держит управление конфигурациями отдельным процессом BAI10 и слова CMDB не использует: хранилище там называется репозиторием конфигураций. Пять управленческих практик процесса удобно читать как контур плана внедрения: построить модель, завести репозиторий и базовую конфигурацию, вести элементы, выпускать отчёты о состоянии, проверять целостность репозитория.

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

По главной мысли своды сходятся, а расходятся в глубине и в словах. Общее у всех: CMDB нужна ради связей и ради решений, которые по ним принимают. И ни ITIL, ни ГОСТ, ни FitSM не требуют включать в неё всё подряд: обязательный минимум есть, а подробность во всех трёх выбирают по пользе или критичности.

Как это выглядит в жизни

Как правильно и как не надо

Что записать о каждом элементе

Минимум задаёт ГОСТ Р ИСО/МЭК 20000-1-2021 в пункте 8.2.6, и он короткий: уникальный идентификатор, тип, описание, связи с другими элементами и статус. Всё остальное — по потребности тех, кто сведениями пользуется.

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

FitSM-2, часть стандарта с описанием действий по каждому процессу, сводит подготовку к трём вопросам. Что считать элементом конфигурации, а что нет? Какие сведения вести по каждому? Как обеспечить, чтобы сведения в CMDB были верными и свежими? Ответы на них и есть проектирование базы — до выбора программы, а не после.

Запись о сервере в CMDB выглядит примерно так: идентификатор SRV-0142, тип «физический сервер», описание «сервер расчёта зарплаты», статус «в эксплуатации». Связи: «на нём работает приложение расчёта зарплаты», «стоит в стойке 7 основной серверной», «владелец — группа инфраструктуры». Такая запись вместе со связями и отвечает на вопрос «что сломается, если его выключить».

Кто за всё это отвечает, ITIL 4 разводит по ролям: ответственный за практику, владельцы типов элементов, ведущие записи и те, кто сверяет их с действительностью. Таблица ролей есть на странице практики.

→ Управление конфигурациями. Четыре роли практики: кто отвечает за подход, за тип элементов, за записи и за сверку.

Чем отличается от элемента конфигурации

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

Разбор соседнего термина — элемент конфигурации.

Где встречается

Практики справочника, рядом с которыми живёт этот термин:

Своды знаний, в которых этот термин определён:

Что с этим делать здесь

Откуда термин

ITIL 4: практическое руководство Service Configuration Management и книга ITIL Foundation; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.1, 3.2.2 и 8.2.6; FitSM-0, FitSM-1 (PR11) и FitSM-2; MOF 4.0, SMF «Изменение и конфигурация»; COBIT 5, процесс BAI10; DAMA-DMBOK, глава 12; Брукс, «Метрики для управления ИТ-услугами»; itSMF, «Введение в ИТ Сервис-менеджмент», 2003. Формулировка на этой странице своя.

Термины рядом