В посте про мысли об управлении изменениями у нас с Леонидом (Leonid) случился диалог на тему "Зачем нужен процесс управления конфигурациями как процесс, достаточно ли его сделать процедурой в рамках процесса управления изменениями". Леонид высказал мнение:
… тяжеловесный конфиг, пожирающий массу ресурсов, мог быть реализован в виде пары процедур в процессе управления изменениями и в процессе «Контроля и оценки», плюс разовый проект по созданию CMDB. А вы как думаете?;)
Тема мне показалась интересной, поэтому я вынес ее в отдельный пост. Не буду в очередной раз говорить, что ситуации и задачи бывают разные, попробую изложить несколько тезисов, которые, как мне кажется, говорят в защиту организации управления конфигурациями в виде процесса.
1. Управление конфигурациями – это не только обновление CMDB. На мой взгляд, успешная работа этого процесса, во многом зависит от того насколько структура CMDB, правила учета, отвечают потребностям специалистов, которые будут использовать CMDB. Поэтому важно наличие регулярного пересмотра правил учета, с обязательным выявлением новых потребностей. При этом важно не стесняться выкидывать из CMDB ту информацию, которая больше не нужна и на актуализацию которой не стоит тратить ресурсы. Поэтому "разовым проектом по созданию CMDB" тут не обойтись.
2. Важен контроль соответствия CMDB потребностям, информации должны доверять, а для этого необходим контроль не только наполненности CMDВ, но и соблюдения установленных правил учета. Т.к. нам важно наличие достоверной информации в CMDB, на основании которой можно принимать решения, а не просто знать, что "что-то там написано по этому поводу, но лучше проверить". Поэтому контроль соблюдения процедур процесса, правил учета очень важен. Именно поэтому я обычно рекомендую ограничивать круг лиц, которые имеют возможность обновления CMDB. Т.к. обучить и проконтролировать работу 5 человек проще, чем 150.
3. Дополнительные процедуры выявления и устранения расхождений позволяют понять насколько хорошо работает процесс и скорректировать информацию, не проходят ли изменения мимо процесса, что это за изменения, почему так происходит и т.д. При этом выявление и устранение расхождений не обязательно должно быть периодическим, например, таким как аудиты, но и могут быть привязаны к другим триггерам. Например, выполнение повседневной работы специалистами (верификация).
При этом каждая процедура в рамках процесса управления конфигурациями направлена на достижение одной цели: предоставление достоверной, актуальной и востребованной информации. Для того чтобы цель достигалась, необходима координация в решении задач процесса. Поэтому, как мне кажется, эти инструменты должны быть сосредоточены в одних руках – руках менеджера процесса управления конфигурациями.
Можем попробовать придумать ситуации, когда можно отказаться от управления конфигурациями в виде процесса. Мне видится, что такие ситуации могут быть, например, в случае недостатка ресурсов или при условии незначительного числа изменений, производимых с учитываемыми элементами.
Сразу оговорюсь, что не считаю пример, приведенный мною в первой части дискуссии отрицательным или положительным, это просто пример, свежий и наглядный. Здесь я продолжу ссылаться на этот пример, кто не помнит о чем речь, смотрите мои комментарии к статье Евгения «Мысли об управлении изменениями».
Теперь пройдемся по тезисам:
1) Улучшения наиболее разумно вводить по результатам. Как я уже говорил «в нашем текущем проекте» улучшения конфига свелись к упрощению процедур ввода информации в CMDB. Причем, упрощения столь значительны, что у меня и появилась мысль о бессмысленности существования конфига, как отдельного процесса. Улучшений же в части использования информации из CMDB не было, так как ею до сих пор просто не пользуются, все «и так знают». Причина такой ситуации, как мне кажется, в том, что в охват процесса управления изменения включены такие работы, информацию для которых проще найти в иных источниках, нежели в CMDB.
Про необходимость регулярного пересмотра правил учета спорить не буду, так как на практике регулярно менять правила мне не приходилось. Чисто умозрительно, кажется, что частое изменение правил ведет к утрате доверия к этим правилам и снижению востребованости CMDB.
2) Как я уже говорил, в «нашем случае», создающие, использующие и контролирующие информацию в CMDB одни и те же люди. Одно это уже явно намекает на необходимость упрощения процедур, чтобы люди не передавали работу сами себе по N-цать раз, что выведет из себя не то что высоко ценящего себя айтишника, но даже и профессионального сборщика картонной тары.
3) Опять же, те, кто выполнял первичное наполнение CMDB, делал изменения в обход процесса и те, кто потом делал аудит CMDB, одни и те же люди, какой уж тут контроль. Эти же люди, по идее, должны пользоваться информацией из CMDB. Но CMDB, как источник информации, видимо не имеет преимуществ перед теми источниками информации, которыми пользовались исполнители изменений раньше. Таким образом, не пользуясь CMDB, люди не особо стараются поддерживая ее в актуальном состоянии, круг замыкается.
«При этом каждая процедура в рамках процесса управления конфигурациями направлена на достижение одной цели: предоставление достоверной, актуальной и востребованной информации» – все верно, НО, на практике часто оказывается, что информация из CMDB не востребована, а поддержание достоверности и актуальности невостребованной информации очень трудоемкая и абсолютно бесполезная работа.
Итого: Я думаю, что в большинстве случаев конфиг правильнее делать как часть процесса управления изменениями. А еще лучше, внедрив, например, процесс управления изменениями, через некоторое время хорошенько подумать, нужен ли конфиг вообще. Внедрять же сначала конфиг, а потом еще что-нибудь, считаю неправильным.