Как давно база данных управления конфигурациями (CMDB) является предметом дискуссий специалистов в области ITSM? Я помню, что это было горячей темой ещё тогда, когда я стал отраслевым аналитиком. Это было в 2008 году, когда CMDB считалась обязательной для организаций, желающих повысить зрелость в области ITSM (а вместе с ней повысить операционную эффективность и результативность). Но также был ряд ужасных историй об инвестициях, которые крупные компании сделали в инициативы, связанные с CMDB, которые потерпели неудачу.
Недавно один менеджер по продуктам сказал мне, что организации все еще пытаются достичь успеха с CMDB и что “полнота и правильность данных в рамках типичной реализации CMDB достигают согласованных уровней при внедрении, но со временем они, как правило, падают, потому что нужно многое поддерживать в актуальном состоянии.”
Эта статья предлагает три способа переосмыслить использование вашей организацией CMDB с целью помочь вам достичь успеха.
Лучшие практики CMDB под микроскопом
Если вы посмотрите свежие руководства по передовой практике ITSM, такие как ITIL 4, то увидите, что понимание практики управления сервисными конфигурациями по сути не изменилось.
У вас должна быть CMDB или система управления конфигурациями (CMS) – “Набор инструментов, данных и информации, которые используются для поддержки практики управления сервисными конфигурациями.” (Источник: AXELOS, Практическое руководство по управлению сервисными конфигурациями ITIL 4, 2020) – для хранения точной и надежной информации о конфигурации услуг и конфигурационных единицах (CI), которые их поддерживают. Эта информация в виде моделей конфигураций услуг (сервисно-ресурсных моделей, прим. перев.) затем может быть использована при выполнении задач, стоящих в рамках других практик ITSM, в частности:
“Анализ влияния
Причинно-следственный анализ
Анализ рисков
Распределение затрат
Анализ и планирование доступности.”
Источник: AXELOS, Практическое руководство по управлению сервисными конфигурациями ITIL 4, 2020
Однако ключевое изменение по сравнению с предыдущей версией ITIL – и в соответствии с Руководящим принципом ITIL 4 “Оптимизируйте и автоматизируйте” – заключается в том, что практика управления сервисными конфигурациями должна быть существенно автоматизирована. Сбор данных из нескольких источников должен выполняться с использованием технологий, а не вручную, когда это возможно. Надо использовать технологию для извлечения и помещения огромных объемов данных, связанных с инфраструктурой и услугами, в CMDB или CMS. Это звучит здорово, но есть ещё понятие “инфраструктура как код”…
Переосмысление №1 – использование подхода “инфраструктура как код”
В практическом руководстве по управлению сервисными конфигурациями ITIL 4 содержится много рекомендаций, как и в других книгах по ITIL 4. Например, в публикации High Velocity IT описано понятие “инфраструктура как код” – практики использования CMDB или CMS для управления изменениями.
“Если необходимы изменения, редактируется источник, а не цель.”
Это означает, что инфраструктура отражает CMDB (или CMS), а не наоборот (что традиционно имело место). Важно отметить, что если есть разница между системой записи и реальной инфраструктурой, преобладает CMDB/CMS.
Хотя это не содержится в PDF – файле с описанием практики управления сервисными конфигурациями, это важное изменение в мышлении и в реальной практике, которое может быть полезным для вашей организации.
Переосмысление #2 – извлечение данных о CI по мере необходимости
Вернёмся к 2008 году. В тот момент одной из ключевых проблем была точность данных в CMDB – с шуткой (которая на самом деле не была смешной), что CMDB были похожи на кладбища слонов. В том смысле, что они были местом, где данные о CI и ИТ-активах умирали. Появившиеся возможности автоматизации частично сгладили проблему. Но это все еще не означает, что специалист по ITSM или кто-либо ещё, ищущий последние данные о CI, действительно получит их. Вместо этого они получают последнюю записанную версию этих данных (или атрибута).
Это не новый вызов и не новое решение. Концепция федеративной CMDB или CMS ещё старше, чем дискуссии, которые я упоминал в начале этой статьи. В блоге 2006 года Троя Дюмулена (Troy Dumoulin) федеративная CMDB описывается так: “главная база данных (она же CMDB) ссылается на внешнюю базу данных для получения подмножества информации.”
Это имело смысл с точки зрения точности CMDB. Появляется возможность получить доступ к самым последним данным относительно CI без необходимости хранить детальную информацию в одном месте. Это, безусловно, облегчило поддержание CMDB, хотя нужно понимать, что данные в источнике могут оказаться не актуальными.
Теперь подумайте, а если бы ваша CMDB предоставляла данные о CI в режиме реального времени, но только по мере необходимости? А для этого запись о CI в CMDB мгновенно обновлялась бы по запросу, в режиме реального времени, непосредственно из самой CI.
И такие решения сегодня есть. Их использование снимает необходимость хранения по существу исторических данных в базе CMDB, извлекая данные из конечного источника, самой CI.
Конечно, база данных CMDB все ещё может периодически заполняться с помощью инструментов сканирования или мониторинга. Но насколько полезны данные о CI в реальном времени для людей в службе поддержки, работающих с проблемами, изменениями, исполняющих другие роли в ITSM! Точные данные и информация способствуют принятию лучших решений, и этот подход также напоминает мне старые пословицы о том, что “качество важнее количества” и что “иногда меньше значит больше”. Кроме того, применение концепции “вытягивания” (pull) вместо “выталкивания” (push) хорошо согласуется с современными идеями в области оптимизации рабочих процессов.
“Но мы не используем нашу CMDB”
Более десяти лет назад Роб Ингланд (Rob England) говорил о “клубе 5%”. Это была “элитная группа менее 5% организаций, которые действительно преуспели в обосновании и внедрении CMDB”. Этот процент также был подкреплен данными исследований EMA.
К счастью, всё пошло своим чередом, и в конце 2013 года я написал в блоге об использовании инструментов ITSM, используя агрегированную статистику заказчиков:
“В настоящее время 82% компаний используют CMDB. Но это не обязательно означает, что все они управляют конфигурациями. Это означает, что они используют базу данных CMDB и содержащуюся в ней информацию для поддержки других процессов ITSM, таких как управление инцидентами, изменениями, активами и мощностями.”
Это приводит нас к третьему потенциальному переосмыслению вашей CMDB…
Переосмыслите #3 – на самом деле речь идет не об управлении сервисными конфигурациями
Надеюсь, приведенная выше статистика заставит вас задуматься. В то время, более семи лет назад, упомянутый выше процент казался очень высоким, да и сейчас ещё кажется. Но теперь давайте вспомним приведённую ранее цитату из ITIL 4 о том, что данные управления конфигурациями могут использоваться в задачах ITSM, таких как “анализ влияния, анализ причин и следствий, анализ рисков, распределение затрат, анализ и планирование доступности.”
Поэтому, если вы еще так не делаете, и особенно если вы чувствуете, что чрезмерно ориентированное на данные мышление помешало успеху или даже убило вашу CMDB, посмотрите на сбор данных о CI как на средство достижения целей, а не как на цель саму по себе. Сделайте CMDB представлением данных, которые важны для операционной деятельности и достижения результатов вместо того, чтобы пытаться сделать её максимально подробной.
Конечно, вы можете спросить: “Но что делать, если вам понадобились данные или информация, которые вы не включили в CMDB?” На что я бы ответил: “Вы бы предпочли, чтобы мы хранили потенциально неточную информацию, получение которой связано с дополнительной сложностью и затратами на случай, если она нам понадобится в будущем?” Это вызовет больше проблем с точностью данных, чем преимуществ.
Итак, пришло ли время, чтобы ваши усилия в области CMDB были сосредоточены на том, что действительно важно – на ключевых данных, которые улучшают операционную деятельность и результаты? А также для того, чтобы признать важность точности данных в CMDB для улучшения процесса принятия решений и достижения результатов?
Надеюсь, что вышеперечисленные три возможности переосмыслить использование CMDB или внедрение одной из них в вашей организации будут полезны.
Автор: Стивен Манн (Stephen Mann), источник.