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

Разрушители легенд: управление конфигурациями невозможно без процесса управления изменениями

Опубликовано 6 октября 2012
Рубрики: CMDB, конфигурации и активы, ISO 20000, ITIL, Управление изменениями
Комментарии

Недавний разговор об управлении конфигурациями и изменениями опять напомнил мне извечный вопрос о курице и яйце. А разговор, в сущности, был на тему, правда ли необходимо внедрение управления изменениями для обеспечения актуальности CMDB? Распространённое мнение гласит: «Да, управление изменениями необходимо, иначе мы не сможем отслеживать изменения и, следовательно, CMDB утратит актуальность». Я не согласен.

Даже если апеллировать к каноническим текстам (книжкам ITIL), назначение процесса управления конфигурациями – «is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed». В то время, как процесс управления изменениями отвечает за «control the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services». Что называется, почувствуйте разницу. И вывод прост и полностью согласуется с практикой: за актуальность данных CMDB отвечает менеджер процесса управления конфигурациями. Это его задача так наладить контроль инфраструктуры, чтобы данные CMDB своевременно обновлялись, независимо от того, есть процесс управления изменениями или нет.

Да, если есть управление изменениями, то снижается риск проведения несанкционированных и незарегистрированных изменений. То есть от внедрения этих двух процессов вместе безусловно есть эффект синергии (поэтому, в частности, в ISO 20000 версии 2005 года было требование «There shall be an integrated approach to change and configuration management planning», хотя из версии 2011 года это требование, к сожалению, удалили). Но говорить, что для управления конфигурациями необходимо внедрение процесса управления изменениями (иначе скоро CMDB потеряет актуальность) это всё равно что утверждать что автомобиль нужен для руля, а не наоборот (иначе куда его девать, этот руль, в самом деле?!).

Практика показывает, что и управление конфигурациями «живёт» без управления изменениями, и даже наоборот (сложнее с изменениями в инфраструктуре, легче с изменениями в приложениях). Не согласны – welcome, обсудим 🙂

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление изменениями и конфигурациями в ИТ
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Также по теме:

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

  • Юрий Ерин

    Конечно же, управление конфигурациями может обходиться без управления изменениями. В этом случае процесс управления конфигурациями вынужен либо взять под свой контроль проведение изменений в отношении конфигурационных единиц и связей, за точность и надежность информации о которых он отвечает, либо периодически “сканировать реальный мир” для выявления изменений и отражения их в CMDB. Наличие процесса управления изменениями облегчает контролировать происходящие изменения реального мира. Однако, в случае когда границы процесса управления изменениями не распространяются на какую-либо часть инфраструктуры, за актуальность информации о которой отвечает процесс управления конфигурациями, последний должен предусмотреть соответствующие процедуры контроля изменений на своей стороне.
    Например, в охват процесса управления изменениями могут не попадать изменения, связанные настольными компьютерами. Если информация о настольных компьютерах и их местоположении должна поддерживаться в актуальном состоянии (например, такое требование к процессу управления конфигурацияи может предъявлять процесс управления инцидентами), процесс управления конфигурациями должен взять под свой контроль перемещения настольных ПК.

  • Александр Жилинский

    Согласны с концепцией, но это очень старая хохма ) Требуем новья!

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

      Саша, кому-то старая. Кому-то до сих пор покоя не даёт. Если бы не недавнее очередное обсуждение, я бы про неё и не вспомнил. А вот видишь, напоминают.
      Новья много про SLM. Но писать про это буду попозже, надо закончить проект и переварить.

      • Александр Жилинский

        У нас много новья про единение каталога (SLM) с конфигом – проведем в следующем году международный семинар )

        • Alexander Peshkov

          Саша, каталог – это совсем не SLM, да же?
          Вот когда я увижу единение нашего SLM с конфигом? Может быть, тогда смогу ответить наконец на древний вопрос Димы про возврат инвестиций от SLM.
          А то как-то стремно … пообещал ведь…

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

            “А то как-то стремно … пообещал ведь…”

            Ух ты, круто. Жду-жду. Хотя любопытно, почему Вы ищете возврат инвестиций SLM в его интеграции с CFG.

            • Alexander Peshkov

              Ха-ха!
              Согласен, не очевидно. Но из Вас это звучит как такая “подначка”. В интеграции с чем еще искать возврат инвестиций, как не с активами 🙂 такое вот словоблудие…

  • Alexander Peshkov

    Что-то курица больно похожа на петуха..
    Что привносит в концепцию забавный нюанс.

  • Олег Скрынник

    Стоп-стоп.
    Таким макаром мы скоро дойдём до того, что управление проблемами возможно организовать без управления инцидентами, управление релизами – без управления изменениями, а SLM – без SLA.

    Сразу видно, что автор поста не читал “Стратегию”.

    • Роман Журавлёв

      Зато Transition читал – вон, вишь, цитирует…
      Я-то читал только словарь. Так кстати, есть такие слова: “Конфигурационные единицы находятся под контролем процесса управления изменениями. Обычно они включают в себя ИТ- услуги, оборудование, программное обеспечение, здания, людей и документы, такие как процессная документация и соглашения об уровне услуг“. В то время как “Конфигурационные записи хранятся в базе данных управления конфигурациями и поддерживаются как часть системы управления конфигурациями”.

      То есть, как это часто бывает, в ITIL можно найти аргументы в пользу почти любой точки зрения.
      “У меня есть принципы! Если они вам не нравятся –
      у меня есть другие.”

      • Alexander Peshkov

        Роман,
        где-то я это уже слышал 🙂

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

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

      “… управление релизами — без управления изменениями…”

      Можно, есть примеры 🙂

      “… а SLM — без SLA.”

      Точно можно. Есть примеры 🙂

  • Igor Muratov

    Мне кажется тут есть передергивание. Некий процесс управления конфигурациями в любом случае существует и отвечает за него менеджер CMDB. В оригинальном посте подразумевается что если процесс существует на уровне отдела, с привлечением группы CMDB то это можно назвать процессом управления конфигурациями. Но по какой-то причине, процесс существующий внутри группы CMDB, направленный на те же самые цели, управлением конфигурацией не может называться.
    Как бы мы не организовывали работу IT, процесс управление конфигурациями должен быть. Это просто порядок действий для достижения нужной цели. Другой вопрос в какие рамки мы такой процесс поместим и в каком объеме конфигураций он участвует.

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

      “Некий процесс управления конфигурациями в любом случае существует и отвечает за него менеджер CMDB.”

      1. Во-первых, в организации конечно может не быть ни CMDB, ни менеджера CMDB. Это медицинский факт.
      2. Во-вторых, можно конечно говорить о том, что процесс существует всегда, но возможно на очень низком уровне зрелости (стремится к нулю). С математической и аудиторской точки зрения это корректно. С точки зрения реальной жизни процесс с уровнем зрелости 0,1-0,5 это то же самое, что процесса нет (если называть вещим своими именами). А конкретно для процесса управления конфигурациями и 1 ничего не значит, потому что время от времени управлять конфигурациями, по мере поступления внешних сигналов – это значит просто собирать данные по требованию начальства, что, конечно, нельзя называть управлением конфигурациями (если называть вещи своими именами).

      Поэтому я передёргивания не вижу. И уж точно не допускаю сознательно 🙂

  • Igor Muratov

    Ну первый случай, я думаю, можно и не рассматривать. Медицина (читай ITSM) в этом случае бессильна 🙂

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

    O да! Это управлением трудно назвать. Однако мне кажется довольно фантастической ситуация при которой CMDB обновляется самостоятельно по мере внесения изменений хаотического характера. Вы видели такое на практике? Поделитесь?
    Должен признать мне трудно аппелировать к практике в широком смысле, поскольку в моем опыте, место где я работаю, это первая компания где я внедряю подобные процессы. Допускаю, что я могу не знать всех возможных вариантов существующих в природе.

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.