Close

Загляните в будущее управления услугами на мероприятии High Velocity: ITSM World Tour. Регистрация

Готовы к работе с ITSM на высокой скорости?

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

Согласно ITIL 4, база данных управления конфигурацией (CMDB) «используется для хранения записей конфигурации на протяжении всего их жизненного цикла и... поддержания отношений между [ними]».

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

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

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

Управление ИТ-ресурсами (ITAM) и управление конфигурацией

Когда мы говорим о ресурсах и CI, управлении ИТ-ресурсами (ITAM) и управлении конфигурацией, легко запутаться. Кажется, что эти термины взаимозаменяемы. На самом деле они могут относиться к одним и тем же компонентам, но при этом быть связаны с разными аспектами этих компонентов.

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

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

Вопросы, связанные с управлением ресурсами

Вопросы, связанные с управлением конфигурацией

  • Когда вы купили машину?
  • У какого дилера?
  • За сколько вы купили автомобиль?
  • Какая марка, модель и комплектация?
  • Какова амортизация?
  • Что входит в гарантию?
  • Какой тип масла используется?
  • Как часто нужно проверять уровень масла?
  • Через сколько километров пробега нужно менять масло?
  • Какова конфигурация двигателя?
    • Была ли она модифицирована?

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

Однако опору ЛЭП нет смысла отслеживать в качестве элемента конфигурации. Нет сети взаимозависимостей для отслеживания. Нет конфигурации, когда мы говорим о куске дерева. И попытка ввести опору ЛЭП как элемент конфигурации в базу CMDB не привносит такой ценности, чтобы тратить на это время и силы.

Характеристики CMDB

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

Вот основные функциональные возможности CMDB.

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

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

Возможность создавать элементы конфигурации и заполнять их данными тремя разными методами: вручную, посредством интеграции (на основе API, SCCM) и с помощью средств обнаружения, которые автоматически сканируют все IP-адреса в сети организации и помогают собирать сведения о программном и аппаратном обеспечении. Все эти методы позволяют проводить инвентаризацию каждого физического и виртуального устройства в компании.

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

Сопоставление ИТ-услуг (как правило, это графическое отображение связей и зависимостей).

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

Преимущества CMDB

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

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

Предположим, что данные элемента конфигурации (CI) А находятся в одном отделе компании, а данные CI Б — в другом. CI Б не может функционировать надлежащим образом без CI А. Когда отдел CI A решает перевести этот элемент конфигурации в автономный режим для технического обслуживания, сотрудники этого отдела не понимают, как это действие может повлиять на элемент CI Б.

В лучшем случае возникнет путаница между командами. А в худшем — произойдет крупный инцидент. И все что нужно, чтобы избежать такого сценария, — это качественная база данных CMDB.

Аналитическое агентство Forrester определяет три сценария, в которых база данных CMDB жизненно необходима.

Планирование

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

Бухгалтерский учет

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

Операционная деятельность

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

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

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

В плане управления проблемами CMDB помогает быстро находить первопричины. Кроме того, CMDB поддерживает упреждающее управление проблемами, помогая командам выявлять ресурсы, которые нуждаются в обновлении. Это позволяет снизить затраты и избежать внеплановых простоев.

Таким образом, CMDB позволяет уменьшить сложность, предотвращать ошибки, укрепить безопасность и обеспечить эффективное применение методик ITSM, таких как управление изменениями и инцидентами.

Проблемы CMDB

Согласно отраслевой статистике, только 25 % организаций получают значимую пользу от инвестиций в CMDB. Из-за высокой частоты неудач технология имеет не очень хорошую репутацию.

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

Культура

Корпоративная культура и командный дух являются важными факторами успешности новых технологий и процессов. В недавнем исследовании Harvard Business Review 93 % руководителей заявили, что самая большая проблема цифровой трансформации на основе данных — это люди и процессы. Это справедливо для проектов CMDB.

Релевантность

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

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

Централизация

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

Например, часто имеет смысл хранить финансовые данные в инструменте управления ИТ-финансами (ITFM), а информацию о лицензиях на программное обеспечение — в инструменте управления программными ресурсами (SAM). Данные можно импортировать и зеркалировать в CMDB, даже если эта база данных не является основным местом хранения.

Точность

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

Для тех, кто не знаком с этими терминами, обнаружение «снизу вверх» — это когда ресурсы сопоставляются начиная с инфраструктуры и разветвляются в элементы конфигурации, ориентированные на клиента. Обнаружение на основе событий — это когда что-то происходит (событие внутри системы, проблема и т. д.), что заставляет системы взаимодействовать друг с другом. Основываясь на событии, система сопоставляет элементы конфигурации и их связи.

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

Чтобы добиться точности, следует использовать возможности как обнаружения снизу вверх, так и обнаружения на основе событий. Это даст максимально четкое представление о ваших ресурсах и их связях.

Процесс

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

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

Инструменты

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

Выбор объекта управления в CMDB

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

Элементы конфигурации можно сгруппировать как технические или нетехнические объекты.

Технические объекты — это бизнес-услуги, технические услуги, программное обеспечение, базы данных, контейнеры, виртуальные машины, операционные системы, аппаратное обеспечение, сети, порты и т. д.

Нетехнические объекты также могут быть смоделированы в базе данных CMDB, если нужно представить их как зависимые или затронутые другими ресурсами при сопоставлении ИТ-услуг. Нетехнические объекты — это пользователи, клиенты, организации, места, соглашения об обслуживании, документы и т. д.

Наконец, при создании модели CMDB следует учитывать облачные сервисы. Предложения SaaS (например, приложения Google, Dropbox, Salesforce и т. д.) и предложения IaaS (например, DigitalOcean, Linode, Rackspace, Amazon Web Services и т. д.) можно при необходимости представить как элементы конфигурации.

В отличие от устаревших баз данных CMDB, Insight for Jira Service Management предлагает гибкую и открытую структуру данных. Так вы сможете управлять всеми имеющимися ресурсами.

продолжение темы
Incident Management