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

Федеративные источники данных

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

  • Переносить данные из внешних источников в CMDB
  • Обеспечить доступ к данным внешних источников из интерфейса CMDB

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

Соответственно нужны критерии  "что переносим, а что получаем через связь с внешним источником данных". Как мне кажется, критерии просты:

  • Удобство использования. Открыл CMDB – увидел данные, без перехода в другую систему.

  • Поиск по атрибутам. Если нужен поиск или группировка КЕ в CMDB по атрибуту, то он должен быть в CMDB).

  • Построение отчетов по КЕ. Если нужны отчеты по КЕ с атрибутами, которые находятся во внешней системе, то потребуется либо построение консолидированных источников данных, либо перенос данных для отчета в CMDB.

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

 

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

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

  • Георгий

    "Однако стоит помнить, что соглашаясь на получение данных в автоматическом режиме вы теряете контроль за историей и причинами происходящих с КЕ изменений". Это не так. Любая промышленная федеративная CMDB имеет гибкие внутренние механизмы сверки и возможность вести несколько версий одной КЕ и нигде автоматом не перезаписывается оригинальная КЕ. Т.е. если автоматически обнаруженные обновленные данные передаются в CMDB, они не пишутся автоматом в оргинальную КЕ, а записываются в отдельные объекты (это может быть просто "песочница непроверенных обновлений" или новая версия КЕ отличающаяся от выверенного оригинала). Далее можно строить отчеты о нессответствиях, можно автоматически создавать RFC или инциденты по несоответствию, что душа пожелает

    • Любая промышленная федеративная CMDB имеет гибкие внутренние механизмы сверки и возможность вести несколько версий одной КЕ

      Не любая. Но многие 🙂

      А вот используется этот механизм, судя по всему, не очень часто. Насколько я могу судить, зачастую интеграторы даже не поднимают этот вопрос, работая с заказчиком. Заказчик хочет импорт – пожалуйста, вот вам импорт. Вопрос "А насколько это правильно?" при этом не поднимается. Во всяком случае, я неоднократно видел именно такой вариант реализации. Не везло?

      • Мне однажды любимый системный интегратор сделал такую штуку. Подробностей не упомню, но менеджер конфигураций перестал радоваться на третий день, после примерно 50го обновления (в основном вывод из эксплуатации) и забил ;). КЕ было примерно 10К+.

        • Это видимо вопрос проработки "песочницы". Что-то можно пропускать и без проверок. Вопрос в том, какую цель преследовали делая такую интеграцию.

      • Андрей

        Имею ровно обратный опыт. Если уж зашел разговор про автоматическую загрузку данных, то явно разделяются Авторизованное состояние и Актуальное. Именно как и написал Георгий. Иначе имеем то, о чем написано в заметке. А дальше решаем по необходмости. Особо желающим делаем третье состояние – Текущее. Это позволяет нам определить источник и причину неавторизованного изменения: реальное изменение или изменение CMDB.

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

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

       

      • Андрей

        В одном большом банке с зеленым логотипом еще несколько лет назад в SD КЕ в Изменении было обязательно к заполнению. Даже атрибуты планировались. Как следствие, в самом КЕ можно было отследить полную историю работы с ним. И сейчас можно. Правда были некоторые сложности, связанные с тем, что дискаверинга нет. Приходится регистритору верить.

      • Alexey Yusov

        Мы, например, делаем, чтобы нельзя было закрыть инцидент(проблему, rfc, изменение – на выбор по требованию) без связи с КЕ определенного типа. Я видел реализацию у одного клиента, сделали такой же фукнционал.

        Что касается версий КЕ, то нормальная CMDB, соглашусь тут с Георгием, должна уметь это делать.

        И наш опыт тоже подсказывает, что Заказчик сначала очень хочет иметь CMDB, а потом очень не хочет ее актуализировать. Все хотят, чтоб всё само собой в штабеля укладывалось. А как спросишь – "А как у вас актуализирутеся данные?" – в ответ "Ну … это ….эммм … вот!"

        • Что касается версий КЕ, то нормальная CMDB, соглашусь тут с Георгием, должна уметь это делать.

          Вот тут надо аккуратнее 🙂 В том, что "нормальная CMDB … должна уметь это делать" я с Георгием и не спорил, я полностью с этим согласен. Причем не только в теории (об этом прямо говорится в книге ST при обсуждении разницы терминов baseline и snapshot), но и на практике и года так наверно с 2004 (именно тогда мы с Евгением Шиловым на субподряде у Microsoft Russia разрабатывали, а потом и внедряли коннектор между HPOVSD 4.5 и MOM+SMS, который как раз это и умел делать в отсутствие штатных средств в HPOVSD). Я только уточнял, что-таки не любая CMDB это умеет, из чего вполне можно сделать вывод, что "не все йогурты одинаково полезны". И я готов прямо-таки диктовать список продуктов, которые это не умеют. Не верите?

          • Alexey Yusov

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

            Мне кажется, что любой продукт, который заявляется, как ITIL-veryfied, просто обязан уметь хранить версии CI. А по сему, c одной стороны, верю Вашему опыту, но уж если Вы готовы диктовать список – "огласите весь список, пожалуйста!"

             

  • ZW

    > желанием Заказчика наполнить ее максимально возможным количеством информации и нежеланием потом эту информацию собирать и поддерживать в актуальном состоянии.

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

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

    Забавно, но Заказчик часто не вполне отдаёт себе отчёт в том, что база, в которой неактуальность данных начинает достигать ~5-10% – не имеет смысла.

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

     


Добавить комментарий для Евгений ШиловОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM