Управление конфигурациями и современные требования к CMDB

Однако CMDB – это не база данных в привычном понимании. Чаще всего правильнее говорить о множестве разделенных репозиториев, объединенных в единую модель или не объединенных вовсе.

Зачастую ситуация выглядит следующим образом:

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

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

Качество процессов управления чрезвычайно зависит от актуальности информации.

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

Проблемы актуализации данных в CMDB

За последние 10 лет ИТ-индустрия довольно сильно изменилась. Благодаря гибким подходам к управлению проектами скорость доставки ценности бизнесу от IT (Time To Value) увеличилась в несколько раз. Применение DevOps практик позволяет доставлять код в продуктивные среды до 200 раз быстрее, чем раньше.

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

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

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

Эти проблемы обусловлены тем, что идея CMDB была сформирована в эпоху доминирования «железных» конфигурационных единиц. Для эффективного управления достаточно было списка элементов инфраструктуры с пояснениями, какие задачи выполняет каждый конкретный элемент.

Идея была актуальна для довольно скромных по современным меркам объемов инфраструктур.

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

Подходы к формированию и управлению CMDB

Вручную

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

Такой подход актуален для небольших организаций со статичной инфраструктурой.

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

Дискаверинг

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

Дискаверинг автоматизирует следующие задачи:

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

Полуавтоматизированный подход

ПО для CMDB с дискаверингом в автоматическом режиме собирает данные об имеющейся инфраструктуре. После этого вручную вносятся недостающие данные и взаимосвязи между элементами.

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

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

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

Таким образом мы приходим к выводу, что дискаверинг не всегда решает проблему актуальности данных в CMDB.

IaC – Инфраструктура как код

Практики DevOps подарили нам новые возможности управления инфраструктурой.

Программно-определяемая инфраструктура – будущее, которое уже наступило.

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

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

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

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

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

В сочетании автодискаверинга и управления инфраструктурой как кодом рождается идеал: непрерывное формирование CMDB.

Непрерывный подход к формированию CMDB

Continuous discovering, IaC как источник эталонных сведений и всегда актуальной конфигурации и в некоторых аспектах ручное управление (к сожалению, без него не обойтись, но важно, чтобы это был минимально необходимый объем операций).

В сочетании всех трех компонентов мы получаем CMDB с актуальными данными. А актуальная CMDB – мощный инструмент в управлении ИТ.

Как формировать и управлять CMDB?

• Все, что располагается в облаках – должно управляться в рамках подхода «инфраструктура как код».
• Конфигурационные единицы, расположенные в физических ЦОДах – управляются с помощью подхода «continuous discovering».
• Элементы офисной инфраструктуры могут управляться с помощью непрерывного дискаверинга и вручную.

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

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

SimpleOne SACM

В дорожную карту (roadmap) развития ITSM-решения на платформе SimpleOne включены все перечисленные подходы к наполнению и актуализации данных CMDB. В скором времени SimpleOne SACM (Service Asset and Configuration Management) предоставит гибкий, удобный и эффективный инструментарий для управления конфигурациями и активами.

Комплексное бизнес-решение SimpleOne SACM включит в себя модули:

• SimpleOne CMDB – модуль CMDB с инструментами непрерывного дискаверинга (continuous discovering), необходимыми компонентами для организации управления инфраструктурой как кодом (IaC) и инструментами для формирования ресурсно-сервисной модели организации и управления ею;
• SimpleOne ITAM – модуль управления ИТ-активами.