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

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

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

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

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

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

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

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

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

 

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Георгий

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

    1. Дмитрий Исайченко

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

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

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

      1. Константин Нарыжный

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

      2. Андрей

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

    2. Евгений Шилов Автор

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

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

       

      1. Андрей

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

      2. Alexey Yusov

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

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

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

        1. Дмитрий Исайченко

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

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

          1. Alexey Yusov

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

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

             

  2. ZW

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

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

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

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

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

     

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
19
Учебный курс:
Основы ITIL (очно)