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

Управление конфигурациями – процесс или процедура

В посте про мысли об управлении изменениями у нас с Леонидом (Leonid) случился диалог на тему "Зачем нужен процесс управления конфигурациями как процесс, достаточно ли его сделать процедурой в рамках процесса управления изменениями". Леонид высказал мнение:

… тяжеловесный конфиг, пожирающий массу ресурсов, мог быть реализован в виде пары процедур в процессе управления изменениями и в процессе «Контроля и оценки», плюс разовый проект по созданию CMDB. А вы как думаете?;)

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

1. Управление конфигурациями – это не только обновление CMDB. На мой взгляд, успешная работа этого процесса, во многом зависит от того насколько структура CMDB, правила учета, отвечают потребностям специалистов, которые будут использовать CMDB. Поэтому важно наличие регулярного пересмотра правил учета, с обязательным выявлением новых потребностей. При этом важно не стесняться выкидывать из CMDB ту информацию, которая больше не нужна и на актуализацию которой не стоит тратить ресурсы. Поэтому "разовым проектом по созданию CMDB" тут не обойтись.

2. Важен контроль соответствия CMDB потребностям, информации должны доверять, а для этого необходим контроль не только наполненности CMDВ, но и соблюдения установленных правил учета. Т.к. нам важно наличие достоверной информации в CMDB, на основании которой можно принимать решения, а не просто знать, что "что-то там написано по этому поводу, но лучше проверить". Поэтому контроль соблюдения процедур процесса, правил учета очень важен. Именно поэтому я обычно рекомендую ограничивать круг лиц, которые имеют возможность обновления CMDB. Т.к. обучить и проконтролировать работу 5 человек проще, чем 150.

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

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

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

  • Leonid

    Сразу оговорюсь, что не считаю пример, приведенный мною в первой части дискуссии отрицательным или положительным, это просто пример, свежий и наглядный. Здесь я продолжу ссылаться на этот пример, кто не помнит о чем речь, смотрите мои комментарии к статье Евгения «Мысли об управлении изменениями».

    Теперь пройдемся по тезисам:
    1) Улучшения наиболее разумно вводить по результатам. Как я уже говорил «в нашем текущем проекте» улучшения конфига свелись к упрощению процедур ввода информации в CMDB. Причем, упрощения столь значительны, что у меня и появилась мысль о бессмысленности существования конфига, как отдельного процесса. Улучшений же в части использования информации из CMDB не было, так как ею до сих пор просто не пользуются, все «и так знают». Причина такой ситуации, как мне кажется, в том, что в охват процесса управления изменения включены такие работы, информацию для которых проще найти в иных источниках, нежели в CMDB.
    Про необходимость регулярного пересмотра правил учета спорить не буду, так как на практике регулярно менять правила мне не приходилось. Чисто умозрительно, кажется, что частое изменение правил ведет к утрате доверия к этим правилам и снижению востребованости CMDB.
    2) Как я уже говорил, в «нашем случае», создающие, использующие и контролирующие информацию в CMDB одни и те же люди. Одно это уже явно намекает на необходимость упрощения процедур, чтобы люди не передавали работу сами себе по N-цать раз, что выведет из себя не то что высоко ценящего себя айтишника, но даже и профессионального сборщика картонной тары.
    3) Опять же, те, кто выполнял первичное наполнение CMDB, делал изменения в обход процесса и те, кто потом делал аудит CMDB, одни и те же люди, какой уж тут контроль. Эти же люди, по идее, должны пользоваться информацией из CMDB. Но CMDB, как источник информации, видимо не имеет преимуществ перед теми источниками информации, которыми пользовались исполнители изменений раньше. Таким образом, не пользуясь CMDB, люди не особо стараются поддерживая ее в актуальном состоянии, круг замыкается.

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

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

    • Давайте разбираться по частям: мне кажется, очень тревожным знаком тот факт, что у вас “оказывается, что информация из CMDB не востребована”. Абсолютно согласен с тем, что “поддержание достоверности и актуальности невостребованной информации очень трудоемкая и абсолютно бесполезная работа.”
      Поэтому и возникает вопрос, а как отрабатывает планирование CMDB? Почему невостребованная информация учитывается в CMDB? Где менеджер процесса, который должен выявить потребность в информации, оценить трудоемкость поддержания в актуальном состоянии и исходя из этого спланировать структуру CMDB?
      Отсюда же будет вытекать причина того, что “в охват процесса управления изменения /*** имелось ввиду конфигурациями? ***/ включены такие работы, информацию для которых проще найти в иных источниках, нежели в CMDB”.

      • Leonid

        «Поэтому и возникает вопрос, а как отрабатывает планирование CMDB? Почему невостребованная информация учитывается в CMDB? Где менеджер процесса, который должен выявить потребность в информации, оценить трудоемкость поддержания в актуальном состоянии и исходя из этого спланировать структуру CMDB?»

        Признаться не встречал людей способных в дополнение к основной работе быстро решить столь сложную задачу, даже если бы захотели. Был у меня опыт, когда конфиг работал как надо, и построенная CMDB использовалось по полной, но там специально выделенные люди серьезную работу по выявлению действительно нужной информации. Далее было уделено большое внимание тому как сделать CMDB самым удобным хранилищем информации. В рассматриваемом же в данной дискуссии примере ничего подобного не делалось. Заинтересованным лицам был задан вопрос, какая информация вам нужна для работы, они естественно ответели «вся». Вот всю информацию и попытались запихнуть в CMDB, естественно для реальной работы это оказалось неудобно и CMDB пока не используется. Как теперь выходить из этой ситуации вопрос отдельный но, возвращаясь к теме дискуссии, хочу еще раз подчеркнуть, что в большинстве случаев не надо начинать с конфига.

        «Отсюда же будет вытекать причина того, что «в охват процесса управления изменения /*** имелось ввиду конфигурациями? ***/ включены такие работы, информацию для которых проще найти в иных источниках, нежели в CMDB»

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

        • Я упустил плотный кусок дискуссии по этой теме, но если позволите, взгляд со стороны в виде нескольких стэйтментов:
          Процесс управления конфигурациями без CMDB – это профанация.
          Если процесс показал свою неэффективность, значит ошиблись где-то а начале пути: на целях, на скоупе, при оценке рисков.
          «Погонять» процесс в данном случае означает «заглянуть на следующий уровень его зрелости». Это означает, что не хватило сил и возможностей учесть все риски (трудности, проблемы).
          Как я понял, Леонид проповедует для таких случаев некий «конфигизм»: CMDB «как есть» + Изменения «все что не стандартные и не мажорные». Что ж, в контексте вышесказанного да, CFG это скорее «Регламент», чем Процесс.

          • “Процесс управления изменениями без CMDB – это профанация”, конечно же.

            • Алексей, почему так категорично? Процесс управления изменениями – это прежде всего управление рисками и принятие решений. CMDB обеспечивает для оценки рисков связи, для принятия решений – хранение авторизованного состояния, т.е. разумеется помогает в управлении изменениями. Но разве можно утверждать, что если CMDB нет, то управление изменениями невозможно?

              • Я трижды писал этот пост, дважды что-то нажимал случайно, и опера выкидывала меня “назад” и пост стирался. Поэтому так категорично.
                Я не зря упоминал уровни зрелости и цели процессов. Безусловно, если цель приучить к процессу, то CMDB вторична.
                Я же исходил из простого понимания, что нет смысла управлять изменениями, если мы даже не знаем с чем эти изменения происходят.

                • Ну почему же непременно профанация…
                  Процесс управления изменениями – это всего лишь форма контроля над деятельностью по модификации инфраструктуры, за которую мы отвечаем (в сколь угодно широком понимании термина “инфраструктура”). Он обеспечивает разумную степень уверенности в том, что изменения приносят пользу, не приносят вреда, связанные с ними риски сведены к приемлемому уровню, и все это – за разумные деньги. Это в целом. А в частности и в конкретной ситуации может оказаться, что для решения этой задачи достаточно согласования финансов и бизнес влияния. А в другом случае – требуется еще и оценка влияния на окружающую среду, а в третьем – и на одновременно проводимые изменения.
                  Для каких-то задач можно обойтись без CMDB, для каких-то она будет очень полезна, а для каких-то очень кстати была бы та штука, которую ITIL именует SKMS. То, что её в живой природе не существует, не делает процесс управления изменениями профанацией, а всего лишь делает его ограниченно применимым и менее рациональным. Например, требует сбора нужных данных ad hoc вместо автомагического извлечения их из единой актуальной детальной базы.
                  Нет?

                  • Роман, я частично уже ответил Дмитрию, аргументы у вас по сути похожи.

                    Да, слова правильные.

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

                    А потому что в таком виде он просуществует недолго. Либо он отомрёт совсем, так и не прижившись (бывает), либо мягко интегрируется с уже существующими процедурами согласования изменений в организации (очень вероятно), либо (вариант оптимистичный) выйдет на новый уровень, где уже не “иногда”, а полноценно нужно использовать информацию о связях, (как минимум). Иначе как оценить то самое влияние на бизнес (сервисы)? На одновременно проводимые изменения?.. Каждый раз собирать ad hoc данные? А если это срочный чендж? А если таких изменений много?

                    И самое главное, как и где фиксировать то, что мы наизменяли? Уж по всякому появится база, которая должна будет содержать актуальное состояние хотя бы сегментов инфраструктуры или же ключевых её составляющих и их связи. Не это ли CMDB?

                    Ещё аргумент – я не рассматриваю управления изменениями как изолированный и единственный работающий процесс, так не бывает. А это значит, что мере роста организации и её зрелости, CMDB будет нужна всё больше не только ему.

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

        • “не встречал людей способных в дополнение к основной работе быстро решить столь сложную задачу, даже если бы захотели” – так и не надо быстро. Пересмотр структуры CMDB по итогам работы, штатная процедура, которая заложена в процесс управления конфигурациями на уровне теории. Время идет, требования меняются, появляется опыт эксплуатации CMDB, потребления информации, в итоге появляется та самая информация, которая “позволит лучше спланировать CMDB”.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM