Что заказчик подразумевает под управлением конфигурациями?

Как это ни странно, но из нескольких проектов по внедрению процесса управления конфигурациями, в которых я участвовал, только про один можно сказать, что внедряли именно этот процесс :). То есть в этом проекте заказчика интересовали именно функциональные возможности учитываемых элементов, учет функционального влияния элементов друг на друга и на предоставляемые услуги. В остальных же случаях получался сильный перекос в сторону учета ИТ-активов.

Вообще, на мой взгляд, такие проекты (по учету ИТ-активов) очень легко выявить – позадавайте заказчику вопросы про связи между учитываемыми элементами. Если заказчик не заинтересован в построении ресурсно-сервисной модели, или хотя бы в учете связей функционального влияния в контексте групп учитываемых элементов (компонентов ИТ-систем, ИТ-систем) то, скорее всего, от вас ждут не управление конфигурациями :).

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Pavel Solopov

    А мне вот на тему управления конфигурациями недавно пришла другая интересная идея pasol-711.livejournal.com/11194.html (пользуясь случаем попиарю свой мало_кем_читаемый журнальчик).

    Так вот по этой идее выходит, что практически какой бы процесс вы не строили, то вы строите управление конфигурациями (в какой-то части). 🙂

  2. Вадим

    Ответ простой: потому что это сложно — реально конфигурацией управлять. Гораздо ближе и понятнее душе айтишника приобретение :о))) какого-либо ИТ актива или, хотя бы, лицензии и управление каким-нибудь оборудованием (сервером). Да и текущее построение ИТ служб суть функциональное, приводящее к конфликтам на основе тезиса «в моем королевстве все в порядке, это у вас там бардак».

    Кратко это выражается как отсутствие сервисного подхода.

    P.S. кстати, почему широко используется название процесса «управление конфигурациями», а не «управление конфигурацией»?

    все ж таки в первоисточнике название «configuration management», а не «configurationS management»

    1. Георгий

      Вадим, то есть то, что Incident Management переводят как управление инцидентамИ, Problem Management переводят как управление проблемами итд, вас менее смущает, чем в случае конфига? 🙂

      1. Вадим

        да, как это ни странно не смущает.

        т.к. конфигурация, как справедливо написал Павел в своем малочитаемом блоге: Конфигурация — Взаимное расположение каких-нибудь предметов, соотношение каких-нибудь предметов

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

        1. Георгий

          Коллеги, я думаю, дополнят и поправят, но

          1. «процесс управляет сразу всей кофигурацией ИТ среды» — неверно в большинстве случаев, охват процесса определяется в начале проектирования, как один из основных оправных пунктов, но, я лично, никогда не видел, чтобы охват был равен ВСЕЙ ИТ-среде, всегда это некое подмножество, выбираемое по разным важным для клиента критериям

          2. «информацию об этой — текущей — конфигурации, а не о каких то других» — неверно, даже в книгах по тексту есть понятия «Configuration baseline» и «Snapshot», откуда понятно, что процесс может предоставлять информацию не только о текущей конфигурации, но и о других.

          3. Ну и само по себе наличие процесса несет в себе ценность для других процессов (а кроме этого в нем никакой и нет), в том числе через возможность what-if анализа при планировании изменений и релизов

  3. Аида

    Это все конечно здорово, но всегда есть Баба-Яга, которая против!

    Как убедить администратора конфигурационной единицы, поделиться информацией для актуализации этой самой единицы в CMDB? Все элементы так или иначе связаны между собой. так например, мы не можем считать информацию заведенную в CMDB о какой-нибудь АСке совершенной, пока не актуализируем информацию о всех связанных с ней КЭ от самой АСки вплоть до корзина на которой находится физический сервер. КАК убедить одного из администраторов в том, что его элемент необходим в CMDB в актуализированным? Я всего месяцев 7 как стала менеджером процесса управления конфигурациями, порой доходит до смешного, я провожу целые розыскные работы по выявлению новых баз данных и заведению для них соответствующих КЭ, но ведь эту БД еще и актуализировать нужно.

    Процесс управления конфигурациями тесно связан и с процессом управления и релизами, и инцидентами, и проблемами.

    Главный враг менеджера управления конфигурациями — это неконтактный ITшник.

    1. Вадим

      главный враг — отсутствие полномочий! в обычной ситуации — с какой стати ИТишник (неважно контактный или неконтактный) должен не пойми кому что-то предосталять и актуализировать.

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

      в процесс ввода в действие какой-либо системы или ИТ-компонента нужно в обязательном порядке включить менеджера процесса УК (для согласования/информирования и т.п.), чтобы он своевременно узнавал о появлении соответствующей КЕ. ввод в действие не должен производиться при незадокументированных КЕ. также в ваших условиях имело бы смысл проводить регулярный аудит на эту тему. важно чтобы у вас были полномочия, т.е. чтобы вас в конечном счете слушали!

      1. Аида

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

      2. Аида

        за день может и не много изменений, а вот за месяц достаточно. Нужно придумать какой-то простой способ документировать эти изменения. Я пытаюсь понять действительно ли ВСЕ изменения должны документироваться? или есть какие-то исключения?

        «если это делается админами без отражения...то за это надо бить палкой по рукам» — Вадим, это не наш метод. Так я могу только отпугнуть администратора и остаться одной с помирающим CMDB на руках. Думю тут тоже можно придумать метод для ограничения доступа к CMDB тех администраторов которые чаще других позволяют делать бесконтрольные изменения. может хоть папку какую создать? и перемещать элемент в папку для редактирования перед назначением администратору задания на изменение, а потом возвращать в папку в которой доступ к элементу не возможен. Но опять же для меня лишняя работа.

        «наверное надо что-то сделать и для упрощения регистрации выполненных изменений с КЕ» — Надо! только что?

        Вобщем Думать, Думать, Думать...

    2. Pavel Solopov

      Современные тенденции в области работы с данными таковы. что большая часть данных является неструктурированной. Пытаться структурировать их это сизифов труд.

      Надо развивать технологии работы с неструктурированными данными, как это иногда ещё называют Enterprise 2.0 (или уже 3, даже).

      Как это относится к CMDB? Наверняка каждый администратор ведёт какую-то свою cmdb, которая помогает ему в работе. При этом каждый ведёт её в том виде, в котором ему удобнее. Надо построить такую CMDB, которая даст возможность искать информацию во всех этих локальных cmdb, и в идеале строить связи между ними (хотя связи можно отдать и на усмотрение человека).

      Я тут хотел построить простейший пример такой CMDB на базе бесплатного поискового сервреа от MS. Но пока не удалось найти свободного сервера, чтобы её развернуть. 🙂

  4. Аида

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

    Еще есть момент. Текущие корректировки КЭ. нашла неверно пропечатанное слово в названии АС, или перепривязала логический сервер из родительских в дочернии, увидела ошибку в версии? поменяла папку или категорию конфигурационного элемента. без запроса на изменение. В стандарте прописано, что любые изменения должны быть задокументированы, но это ведь не реально! Администраторы АС имеют доступы к редактированию своих КЭ и какие-то незначительные изменения могут делать бесконтрольно. Конечно существуют отчеты и я часто делаю выгрузку по всем изменениям в КЭ. Но для меня видется практически нереальным сидеть и разбирать какие из этих изменений были проведены по ЗНИ, а какие были сделаны по инициативе администратора. Может я еще не созрела до какого-то гениально простого выхода из этой ситуации?Реально ли отображать все корректировки CMDB в ЗНИ?

    1. Вадим

      IMHO если кто-то что-то сделает, то результат должен отражаться в CMDB, иначе она будет совсем не нужна, т.к. не будет содержать актуальной информации.

      если это делается админами без отражения (несмотря на то, что отражение изменения является их обязанностью), потому что муторно и лениво. то за это надо бить палкой по рукам.

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

      должно быть «не занесено изменение в CMDB — работа не закончена, не выполнена».

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

      и вопрос: почему нереально? у вас так много каждодневных изменений по мелочи? почему?

      наверное надо что-то сделать и для упрощения регистрации выполненных изменений с КЕ.

      1. Аида

        за день может и не много изменений, а вот за месяц достаточно. Нужно придумать какой-то простой способ документировать эти изменения. Я пытаюсь понять действительно ли ВСЕ изменения должны документироваться? или есть какие-то исключения?

        «если это делается админами без отражения...то за это надо бить палкой по рукам» — Вадим, это не наш метод. Так я могу только отпугнуть администратора и остаться одной с помирающим CMDB на руках. Думю тут тоже можно придумать метод для ограничения доступа к CMDB тех администраторов которые чаще других позволяют делать бесконтрольные изменения. может хоть папку какую создать? и перемещать элемент в папку для редактирования перед назначением администратору задания на изменение, а потом возвращать в папку в которой доступ к элементу не возможен. Но опять же для меня лишняя работа.

        «наверное надо что-то сделать и для упрощения регистрации выполненных изменений с КЕ» — Надо! только что?

        Вобщем Думать, Думать, Думать...

        P.S. Как-то странно у меня сообщения отправляются. Прошу прощения за бардак в полосе

        1. Вадим

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

          если у вас есть соответствующие распоряжения по отражению изменений в CMDB, а сотрудники (админы) их не выполняют, то за что им платят зарплату? за невыполненные до конца поручения? в качестве фантазии — ввести коэффициент к мотивационной схеме соответствующий коэффициенту правильно отраженных в CMDB поручений. будет отражена половина — получат половину, если всё будет отражено в CMDB — получат полностью.

          задача менеджера УК не подтирать за админами, а контролировать актуальную конфигурацию ИТ инфраструктуры.

          а возня с доступом — это возня и есть. вы же сами пишете «админы делают бесконтрольные изменения»... ограничения в доступе только помешают решить проблему.

  5. Аида

    «в качестве фантазии — ввести коэффициент к мотивационной схеме соответствующий коэффициенту правильно отраженных в CMDB поручений. будет отражена половина — получат половину, если всё будет отражено в CMDB — получат полностью.» Фантазия фантазией, а это кажется выход! 🙂

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

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

Empty