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

Люди для CMDB или CMDB для людей


«Кто на ком стоял? — крикнул Филипп Филиппович, — потрудитесь излагать ваши мысли яснее»
Михаил Булгаков, «Собачье сердце»

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

Я же при обсуждении этой заметки в очередной раз вспомнил, как при первом прочтении ITIL мне показалось, что в части описания управления конфигурациями в книге содержится парадокс, терминологический казус. Как выяснилось, парадокса нет. Но в реальной жизни некотоые попытки организовать практику управления конфигурациями иногда напоминают попытку воспроизвести этот парадокс (может быть тоже невнимательно читали ITIL? 🙂 )

Попробую запутать и вас.
Система Управления Конфигурациями (Configuration Management System, CMS) в официальном переводе определяется так:

Набор инструментов, данных и информации, которые используются для поддержки процесса управления сервисными активами и конфигурациями. CMS – часть общей системы управления знаниями по услугам, включает в себя инструменты для сбора, хранения, управления, обновления, анализа и представления информации обо всех конфигурационных единицах и их взаимоотношениях. CMS может также включать в себя информацию об инцидентах, проблемах, известных ошибках, изменениях и релизах. CMS поддерживается процессом управления сервисными активами и конфигурациями и используется всеми процессами управления ИТ-услугами.

Т.е. первое предложение говорит нам о том, что CMS используется для поддержки процесса управления сервисными активами и конфигурациями (Service Assets and Configuration Management, SACM). А первая фраза последнего предложения – о том, что процесс SACM поддерживает CMS.

Ещё раз. CMS поддерживает SACM, а SACM поддерживает CMS. Это что, Уроборос (змея, кусающая себя за хвост)?
Может быть проблема в переводе? Смотрим на оригинальное опредление CMS:

A set of tools, data and information that is used to support service asset and configuration management. The CMS is part of an overall service knowledge management system and includes tools for collecting, storing, managing, updating, analysing and presenting data about all configuration items and their relationships. The CMS may also include information about incidents, problems, known errors, changes and releases. The CMS is maintained by service asset and configuration management and is used by all IT service management processes.

Вроде бы, дело не в переводе.
То есть мы имеем вот такую картину?
стрелки обозначают «использует» (или наоборот «поддерживает»)


Так? Да. Но это не вся правда. В определении CMS также сказано, что она «используется всеми процессами управления ИТ-услугами». Т.е. не только SACM является потребителем информации из CMS.

Казалось бы, это очевидно и даже банально. Но нередко, судя по тому, как организация выстраивает практику управления конфигурациями, складывается впечатление, что практика работает сама на себя. Т.е. создание CMS (или, используя более распространённый термин, CMDB [Configuration Management DataBase]) является самоцелью, а не инструментом для решения какой-то иной задачи.

И ровно на преодоление этой проблемы направлена заметка, упомянутая в самом начале.

Собственно, подход, описанный в ней, на мой взгляд, имеет смысл использовать при построении/оптимизации любых управленческих практик.

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

  • Павел С.

    Т.е. можно сказать. что система управления инцидентами это подсистема Системы Управления Конфигурациями?

    • Может быть и такой вариант не исключен. Но, не думаю, что авторы имели в виду это.

      Из процитированного определения CMS лишь следует, что CMS может содержать информацию об инцидентах. При этом не сказано, какую. Например, нам может быть небезынтересна возможность получения информации об инцидентах, связанных с теми или нами конфигурационными единицами (CI). Что скорее всего мы реализуем в системе учета инцидентов путём указания ссылок на соответствующие объекты в CMS (CMDB). Но вряд ли мы будем хранить в CMS всю информацию, необходимую для управления процессом Incident Management.

      Подтверждением этой идеи, как мне кажется, является в том числе картинка Figure 4.9 Example of the application of the architectural layers of the CMS из книги ITIL «Преобразование услуг»


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

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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как 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 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT