Создание и использование СMDB объектов виртуальной инфраструктуры в процессах сопровождения информационных систем

Мир стремится к упорядоченности. Нам хочется, чтобы все лежало по полочкам, все процессы были систематизированы, а нужную вещь можно было быстро найти даже с закрытыми глазами. Если для порядка в домах придумали контейнеры, органайзеры и системы хранения, то в ИТ-сфере эту задачу выполняет CMDB [1].

Всем привет, меня зовут Марианна, я менеджер по развитию бизнес-процессов отдела сервисного сопровождения СИГМЫ. В этой статье расскажу про наш опыт внедрения CMDB, чтобы и другие специалисты смогли использовать эту простую, казалось бы, базу данных в процессах обслуживания по ITIL [2]. Прежде, чем погружаться в процессы внедрения, давайте выясним, какие задачи решает CMDB, что это за зверь такой и как его «готовить».

Самое первое и главное, что надо знать, услышав от руководства клич «Нам нужна CMDB!»: сама по себе CMDB ценности не имеет, но она повышает эффективность определенных бизнес-процессов. Поэтому, прежде чем начать работу, необходимо ответить на вопросы: что за проблемы мы должны решить, чьи это проблемы и какие бизнес-процессы надо улучшать.

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

Сравнение: CMDB в обслуживании vs в управлении активами

Вывод 1:

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

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

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

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

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

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

Внедрение CMDB в СИГМА. 2:1

В СИГМЕ было три попытки внедрения CMDB.

Первая попытка! В 2019 году мы попытались управлять активами с помощью CMDB в Naumen Service Desk, но потерпели неудачу. Теперь, набравшись опыта и оглядываясь назад, мы уже можем выделить наиболее типовые причины таких неудач. Первая — неготовность внутренних процессов: например, данные загрузили, но не смогли наладить их актуализацию. Во-вторых, попытка охватить все сразу, создав универсальную конфигурацию CMDB. Практика показала, что более эффективно «есть слона по частям».

Вторая попытка! Спустя два года мы попробовали снова. В этот раз внимание было направлено на управление активами заказчика. Нам требовалось знать, сколько и какой инфраструктуры взято на сопровождение, сколько и каких запросов на обслуживание, изменений, трудозатрат на выполнение работ и т. п. Эта попытка была успешно реализована для КЕ физической инфраструктуры и для лицензий ПО. А вот для домена виртуальных КЕ подход, аналогичный физическим объектам, оказался неэффективным. Дело в том, что виртуальные объекты не являются объектами «учета» с точки зрения управления активами, а технические специалисты, такие как DevOps-инженеры и инженеры инфраструктуры, в своей работе с виртуальными объектами пользуются специализированными программными средствами.

Вывод 2:

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

В 2023 году с этим пониманием мы вышли на попытку №3.

Попытки №3. Пример внедрения CMDB с КЕ виртуальной инфраструктуры

Для попытки №3 внедрения CMDB мы поставили перед собой следующие требования:

1. Решаемая проблема

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

2. Ограничения и допущения

• Допускаем, что верхнеуровневой объект, с которого начинается (а может, и заканчивается) работа с техническими КЕ в CMDB, — это КЕ типа «Стенд». Все остальные технические КЕ вычислительной инфраструктуры должны рассматриваться в рамках определенных стендов.

• КЕ инфраструктуры рабочих мест, периферии и сетевой инфраструктуры не рассматриваются.

• Все действия — создание/изменение/удаление объекта, по которым контролируются КЕ, осуществляются при наличии ЗНИ в Service Desk, создание ЗНИ включается в US [4].

• Типы КЕ: КЕ виртуальной инфраструктуры (виртуальные машины, гипервизоры, ОС и прочее middleware), без технических подробностей, а только необходимые и достаточные для принятия управленческих решений.

 3. Сценарий использования

• Ретроспектива. РП и СМ могут легко находить, что происходило со стендом, по КЕ стенда.

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

• Быстрый доступ к документации. К КЕ типа «Стенд» должны быть прикреплены ссылки на документацию стенда для технических специалистов (нюансы настройки стенда, информация о подключении и доступах и прочее).

• История устранения инцидентов. Техническим специалистам будет проще находить по КЕ информацию по аналогичным инцидентам и как они устранялись ранее.

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

 4. Актуализация: с автоматической синхронизацией информации об объектах Zabbix → CMDB (добавление/ удаление объектов , изменение характеристик и статусов).

Что было сделано

1. Пересмотр конфигурации CMDB, относящихся к виртуальным объектам:

   • верхнеуровневым объектом стала КЕ «стенд», владельцем такой КЕ является куратор договора обслуживания. Так мы обошли проблему отсутствия в нашей CMDB владельца ИС, которым является сотрудник заказчика;

   • в одном договоре может быть несколько стендов информационной системы (прод, тест, демо…). Единственная КЕ, которая ведется вручную, и связывается с Услугой и Договором;

   • в структуре оставлены только КЕ, которые стоят на мониторинге и могут обновляться автоматически сервисом синхронизации Zabbix → CMDB.

Модель конфигурации стала превращаться в что-то более осознанное

2. Выполнены доработки NaumenSD для взаимодействия с сервисом синхронизации: поиск по КЕ, вывод списков КЕ по стенду, представление пользователям информации по конфигурационным единицам стенда в понятном виде, отчеты по сайзингу стенда, «непривязанным» КЕ (новые объекты).

3. Объекты и обновляемые параметры, требуемые для CMDB, настроены для сбора в шаблонах Zabbix.

4. Разработан сервис синхронизации Zabbix → CMDB.

Описание сервиса синхронизации

Принцип работы сервиса:

Сервис синхронизирует данные КЕ по данным Zabbix. Он получает данные из Zabbix через Zabbix API, на основе этих данных и конфигурации самого сервиса он обновляет/создает КЕ в CMDB через NaumenSD API.

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

Сервис запускается по расписанию.

Порядок работы

1. Получение списка всех хостов из Zabbix.

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

3. По каждому хосту запрашивается дополнительная информация для атрибутов (к примеру, CPU, RAM) из Zabbix (список запрашиваемых атрибутов зависят от типа планируемой КЕ).

4. В NaumenSD, если КЕ для хоста уже существует, — она будет обновлена актуальными данными. Если КЕ нет — она будет создана.

5. Компания владелец КЕ определяется из соответствия хост-группы — компании-владельца КЕ. Если хост-группы нет в конфигурации — по умолчанию присваивается компания-владелец СИГМА.

6. Статус эксплуатации КЕ определяется по статусу хоста в Zabbix (хост включен и мониторится — в эксплуатации, хост выключен — статус неактивен для КЕ в CMDB).

Делимся подсказками

Для конфигурации сервиса необходимо настроить следующие мапинги в конфиге в формате yaml:

• ID шаблона Zabbix — тип КЕ CMDB.

• ID хост-группы Zabbix — компания-владелец КЕ.

Пример конфигурационного файла ниже.

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

Куда дальше?

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

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

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

Вывод 3.

Ставьте перед собой реальные цели, а не CMDB ради CMDB 🙂 и все у вас получится!

Надеюсь, моя статья помогла вам разобраться в лабиринтах применения CMDB. 

Поделитесь опытом реализации хранения данных в CMDB по установленному программному обеспечению. А если у вас появились вопросы, смело задавайте их в комментариях. Буду рада помочь!

---

[1] CMDB (Configuration Management Database) — база конфигурационных единиц, позволяющая эффективно управлять ИТ-инфраструктурой организации.

[2] ITIL (Information Technology Infrastructure Library) — набор методологий и лучших практик в области управления ИТ-услугами.

[3] КЕ — конфигурационная единица.

[4] US — User Story