Портал №1 по управлению цифровыми
и информационными технологиями

CMDB, которая обновляется сама

7 февраля мы провели очередную конференцию CleverDAY. Два из пяти докладов затрагивали тему управления конфигурациями. Один – доклад про сервисную экономику, где решение задачи распределения ИТ-затрат и расчета себестоимости ИТ-услуг опирается на данные CMDB. Второй – про встроенный инструментарий по управлению ресурсами в новой версии CleverENGINE, очень тесно переплетающийся с функциональностью CMDB. А поскольку собралось больше 200 человек, и вопросов было много, конечно, заговорили о том, насколько это экономически целесообразно – поддерживать актуальность данных CMDB, если это требует ручных операций? И конечно сразу появилась потребность в уточнении: а собственно сколько требуется ручных операций для актуализации данных CMDB? Вот с этим давайте и разберемся.

На курсе по управлению конфигурациями мы проводим такое упражнение: проектируем правила учета для фрагмента CMDB, который нужен для обеспечения потребностей какого-то конкретного менеджера. Например, менеджера одной из базовых ИТ-услуг – услуги печати, базового рабочего места или ВКС. Потребности эти самые разные – менеджерам услуг нужны данные для эффективной поддержки пользователей, финансовой отчетности, оперативного управления ресурсами, планирования закупок и так далее. Спроектированную таким образом CMDB мы оцениваем на предмет возможности автоматического обновления из существующих источников данных, причем с учетом возможных доработок. И результат обычно не превышает 50%. То есть даже если доработать имеющиеся discovery-решения и скрипты, около половины данных CMDB можно собрать только вручную.

Тут я вижу, как на задних рядах заволновались представители вендоров ПО. Мол, товарищи. Мол, 21-й век. Мол, современное auto discovery – это совершенно могучая вещь. И все само. И тут много правды – вещь могучая, но все же само не все. Да и не будет все. Например:

  • очевидно, некоторая часть атрибутов конфигурационных единиц типа расположения или ответственного пользователя может вестись только вручную или, по крайней мере, частично вручную;
  • некоторые виды категорий конфигурационных единиц, таких как неуправляемые серверные шкафы или несетевое офисное оборудование – вручную;
  • учет комплектующих и расходных материалов – по большей части вручную;
  • учет серверов, дисковых массивов, активного сетевого оборудования до включения в сеть и попадания в лапы inventory и мониторинга – вручную;
  • кластерные конфигурации, особенно NLB и проприетарные средства обеспечения отказоустойчивости приложений – по большей части вручную;
  • некоторые виды лицензий и фактов их использования, таких как лицензии на подключение клиентов (CAL) – вручную;
  • отражение в CMDB прикладных архитектур, особенно в части «некоробочных» приложений – по большей части вручную.

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

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

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 12

  • Андрей другой

    Интересно, а почему вопрос себестоимости сервиса сводится только к стоимости ресурсов(CI и Assets, я не буду тут углубляться в то, что CI и Assets – это один и тот же объект.)? А как же работы по инцидентам и заявкам в контексте тех же сервисов? Из своего опыта могу сказать, что это достаточно существенная часть затрат на сервис и её не стоит недооценивать.
    Ну и с точки возможностей автоматизации перечисленных процессов лично у меня взгляд более оптимистичный. Другое дело, на сколько достаточно дорогие инструменты снижают риски, связанные с тем, что некие атрибуты не будут учитываться. Тут я согласен – стоимость борьбы с рисками не должна превышать стоимость возможных потерь.

    • > Интересно, а почему вопрос себестоимости сервиса сводится только к стоимости ресурсов(CI и Assets, я не буду тут углубляться в то, что CI и Assets — это один и тот же объект.)?

      Автор нигде этого не утверждал. И вместе с Вами гневно не согласен с таким предположением (если оно у кого-то есть).

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

      Поделитесь?

      • андрей другой

        -кластерные конфигурации, особенно NLB и проприетарные средства обеспечения отказоустойчивости приложений – по большей части вручную;
        -некоторые виды лицензий и фактов их использования, таких как лицензии на подключение клиентов (CAL) – вручную;
        Для автоматизации этих пунктов уже есть средства автоматизации. Так называемые программные роботы.
        – учет серверов, дисковых массивов, активного сетевого оборудования до включения в сеть и попадания в лапы inventory и мониторинга – вручную;
        В наших проектах эта информация попадала автоматически из учетных систем, а потом, после Inventory (автоматического) автоматически выполняясь процедура reconciliation – привязки купленного к обнаруженному.

        • > В наших проектах эта информация попадала автоматически из учетных систем, а потом, после Inventory (автоматического) автоматически выполнялась процедура reconciliation — привязки купленного к обнаруженному.

          Это типовое решение – так поступают очень часто. Но ручные операции по первичному вводу оно может исключить только когда такое оборудование практически сразу вводится в эксплуатацию (и то не всегда). Если же Вы решаете вопрос учета оборудования на складе, Вам, как минимум, потребуется описать его в правильной классификации, с указанием модели / комплектации, местоположения и гарантийных обязательств. Если решается задача управления потребностями, может быть важно связать это оборудование с плановыми потребностями, на основании которых оно было приобретено. И всех этих данных из контура бухгалтерского учета не получить. Частично их можно было бы получить из управления закупками, но только если правильно решена задача единых справочников номенклатуры, что по факту довольно редкое явление.

          Более того, между ТМЦ в бухгалтерии и КЕ в CMDB связь обычно не один-к-одному. Поэтому в наших проектах мы чаще импортируем из систем бухгалтерского учета не саму КЕ, а связанную с ней запись об основном средстве.

        • А даже если сразу вводится в эксплуатацию, опять же возникает классификация, гарантия, место установки (шкаф, юнит, blade-корзина, …), ответственные лица (иногда несколько разных), среда (dev, test, prod, …), уровень обслуживания / критичность, операционный календарь, … И это все вручную (ну, может быть, среду удастся определить по ip-адресу…).

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

  • Павел С.

    В части автоматического дискавери очень большая проблема часто лежит в области прав доступа. Часто для того, чтобы собрать необходимую информацию требуются права root, суппер админ и пр. Не всегда это возможно по различным причинам субъективным или объективным. И проще вести ручной учёт, нежели пробивать стены лбом.
    А что касается вендоров, то они часто лукавят, как правило дискаверить “из коробки” умеют только очень распространнённые системы, чуть в сторону и надо брать в руки напильник. Ну и отдельная история это качество дискавери, к сожалению, часто за вендорами надо очень тчательно проверять, а то ли они вообще дискаверят.

  • Павел С.

    “я не буду тут углубляться в то, что CI и Assets — это один и тот же объект.”
    Ну как сказать, как сказать.
    Вот, например, есть у нас сервер железный. Его привезли на склад и положили, активом он является, а вот является ли он CI? Я бы сказал, что нет, если только мы не ставим равенства между управлением конфигурациями и управлением активами, а если знак равенства ставим, то что-то в наших “скрижалях” нехорошо, зачем мы одно и тоже называем разными именами?

    • > Ну как сказать, как сказать

      Это вообще вечная тема. Боюсь, что из разряда “чем отличается инцидент от сервисного запроса”. И объекты управления могут быть разные (и даже связи между ними не один-к-одному), и практики управления и следовательно ответственность весьма отличаются. И, наконец, отдельная тема – как эти объекты управления хранятся в информационных системах.

      Тут я боюсь, разумный диалог без предварительного выравнивания терминов / картинок просто невозможен.

    • андрей другой

      Есть объект – сервер. У него есть набор атрибутов, важных для финансового учета, и этот набор характеризует его как Asset. У этого же объекта сервер есть набор атрибутов, важных для его эксплуатации, и это набор характеризует его как CI. Идеальная CMDB содержит для каждого объекта и набор атрибутов Asset и набор атрибутов CI. У продвинутых CMBD есть даже специальная функция – reconciliation.

      • > Идеальная CMDB содержит…

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

  • Сергей

    CMDB можно и НУЖНО автоматизировать. Для этого её надо рассматривать как платформу для аккумулирования информации, а не как первоисточник.

    • Тогда точка первичного ввода просто переезжает в другую систему, т/з это не уменьшает, вопрос принципиально не меняется. Вопрос же не “где вести учет”, а “какова цена учета”.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM