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

Пришло ли время переосмыслить ваш подход к CMDB?

Как давно база данных управления конфигурациями (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), источник.

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT