ITSM4U Диагностика 7 мин

Главная·База знаний·Глоссарий·База данных управления конфигурациями (CMDB)

Термин глоссария

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

Хранилище сведений о составных частях услуг и о связях между ними: что из чего состоит и что развалится, если тронуть вот это.

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

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

Зачем нужна CMDB

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

Сведения о составе нужны для пяти вещей:

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

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

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

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

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

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

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

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

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

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

Отсюда порядок наполнения: сначала связи между услугой и тем, что её держит, потом подробности по каждому элементу.

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

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

Логика простая. Сплошная инвентаризация даёт снимок, который начинает устаревать в день окончания. Учёт, растущий от изменений, описывает ровно то, что живёт и меняется, и обновляется тем же действием, которым меняется среда.

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

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

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

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

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

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

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

Что стоит считать вместо полноты:

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

Самый частый исход внедрения — база, наполненная всем, чем удалось наполнить, и не отвечающая ни на один настоящий вопрос.

УслугаПриложениеБаза данныхСервер
По этой цепочке и считается влияние сбоя

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

База отвечает на вопрос

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

База не отвечает на вопрос

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

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

База конфигураций работает

  • По ней можно оценить влияние сбоя, не звоня людям
  • У каждой записи есть владелец
  • Обновляется тем же действием, которым меняется среда
  • Границу учёта могут объяснить: что внутри и почему

База конфигураций мертва

  • Заполнялась один раз при внедрении
  • Связей нет — только перечень устройств
  • Расхождение с действительностью никто не считает
  • Ни одно решение за год по ней не принималось

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

Практики справочника, в разборах которых этот термин работает:

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

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

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

ITIL 4, практическое руководство Service Configuration Management; ГОСТ Р ИСО/МЭК 20000-1-2021. Формулировка на этой странице своя.

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