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

Опубликовано 31 октября 2013

Рубрики: CMDB, конфигурации и активы, Обо всём на свете

Комментарии

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

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

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

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

Удобство использования. Открыл CMDB – увидел данные, без перехода в другую систему.
Поиск по атрибутам. Если нужен поиск или группировка КЕ в CMDB по атрибуту, то он должен быть в CMDB).
Построение отчетов по КЕ. Если нужны отчеты по КЕ с атрибутами, которые находятся во внешней системе, то потребуется либо построение консолидированных источников данных, либо перенос данных для отчета в CMDB.

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

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

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

Георгий
31.10.2013

"Однако стоит помнить, что соглашаясь на получение данных в автоматическом режиме вы теряете контроль за историей и причинами происходящих с КЕ изменений". Это не так. Любая промышленная федеративная CMDB имеет гибкие внутренние механизмы сверки и возможность вести несколько версий одной КЕ и нигде автоматом не перезаписывается оригинальная КЕ. Т.е. если автоматически обнаруженные обновленные данные передаются в CMDB, они не пишутся автоматом в оргинальную КЕ, а записываются в отдельные объекты (это может быть просто "песочница непроверенных обновлений" или новая версия КЕ отличающаяся от выверенного оригинала). Далее можно строить отчеты о нессответствиях, можно автоматически создавать RFC или инциденты по несоответствию, что душа пожелает
- Ответить
- Дмитрий Исайченко
  31.10.2013
  
  Любая промышленная федеративная CMDB имеет гибкие внутренние механизмы сверки и возможность вести несколько версий одной КЕ
  
  Не любая. Но многие 🙂
  
  А вот используется этот механизм, судя по всему, не очень часто. Насколько я могу судить, зачастую интеграторы даже не поднимают этот вопрос, работая с заказчиком. Заказчик хочет импорт – пожалуйста, вот вам импорт. Вопрос "А насколько это правильно?" при этом не поднимается. Во всяком случае, я неоднократно видел именно такой вариант реализации. Не везло?
  Ответить
  - Константин Нарыжный
    31.10.2013
    
    Мне однажды любимый системный интегратор сделал такую штуку. Подробностей не упомню, но менеджер конфигураций перестал радоваться на третий день, после примерно 50го обновления (в основном вывод из эксплуатации) и забил ;). КЕ было примерно 10К+.
    
    Ответить
    
    Евгений Шилов
    31.10.2013
    
    Это видимо вопрос проработки "песочницы". Что-то можно пропускать и без проверок. Вопрос в том, какую цель преследовали делая такую интеграцию.
    
    Ответить
  - Андрей
    01.11.2013
    
    Имею ровно обратный опыт. Если уж зашел разговор про автоматическую загрузку данных, то явно разделяются Авторизованное состояние и Актуальное. Именно как и написал Георгий. Иначе имеем то, о чем написано в заметке. А дальше решаем по необходмости. Особо желающим делаем третье состояние – Текущее. Это позволяет нам определить источник и причину неавторизованного изменения: реальное изменение или изменение CMDB.
    
    Ответить
- Евгений Шилов
  31.10.2013
  
  Я даже больше не про историю изменения отдельных атрибутов КЕ, а про историю работ с КЕ. Чтобы можно было получить ответ на вопрос "почему КЕ имеет такую конфигурацию как сейчас, кто ее менял, на основании чего, кто разрешил, в рамках какого изменения это произошло и т.д.".
  
  Если "песочницу" потом можно привязать к работам, то это то что надо, но на практике пока не видел.
  Ответить
  - Андрей
    01.11.2013
    
    В одном большом банке с зеленым логотипом еще несколько лет назад в SD КЕ в Изменении было обязательно к заполнению. Даже атрибуты планировались. Как следствие, в самом КЕ можно было отследить полную историю работы с ним. И сейчас можно. Правда были некоторые сложности, связанные с тем, что дискаверинга нет. Приходится регистритору верить.
    
    Ответить
  - Alexey Yusov
    03.11.2013
    
    Мы, например, делаем, чтобы нельзя было закрыть инцидент(проблему, rfc, изменение – на выбор по требованию) без связи с КЕ определенного типа. Я видел реализацию у одного клиента, сделали такой же фукнционал.
    
    Что касается версий КЕ, то нормальная CMDB, соглашусь тут с Георгием, должна уметь это делать.
    
    И наш опыт тоже подсказывает, что Заказчик сначала очень хочет иметь CMDB, а потом очень не хочет ее актуализировать. Все хотят, чтоб всё само собой в штабеля укладывалось. А как спросишь – "А как у вас актуализирутеся данные?" – в ответ "Ну … это ….эммм … вот!"
    
    Ответить
    
    Дмитрий Исайченко
    03.11.2013
    
    Что касается версий КЕ, то нормальная CMDB, соглашусь тут с Георгием, должна уметь это делать.
    
    Вот тут надо аккуратнее 🙂 В том, что "нормальная CMDB … должна уметь это делать" я с Георгием и не спорил, я полностью с этим согласен. Причем не только в теории (об этом прямо говорится в книге ST при обсуждении разницы терминов baseline и snapshot), но и на практике и года так наверно с 2004 (именно тогда мы с Евгением Шиловым на субподряде у Microsoft Russia разрабатывали, а потом и внедряли коннектор между HPOVSD 4.5 и MOM+SMS, который как раз это и умел делать в отсутствие штатных средств в HPOVSD). Я только уточнял, что-таки не любая CMDB это умеет, из чего вполне можно сделать вывод, что "не все йогурты одинаково полезны". И я готов прямо-таки диктовать список продуктов, которые это не умеют. Не верите?
    
    Ответить
    
    Alexey Yusov
    03.11.2013
    
    Дмитрий, я и Вами согласен тоже! Мы внедряем продукт (название упоминать не буду, чтобы не быть уличенным в рекламе), который это умеет. И который часто пренебрежительно оценивают в плане возможностей. Даже один из Ваших уважаемых тренеров высказался скептически однажды :-).
    
    Мне кажется, что любой продукт, который заявляется, как ITIL-veryfied, просто обязан уметь хранить версии CI. А по сему, c одной стороны, верю Вашему опыту, но уж если Вы готовы диктовать список – "огласите весь список, пожалуйста!"
    
    Ответить
ZW
02.11.2013

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

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

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

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

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