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

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

Опубликовано 29 февраля 2012
Рубрики: CMDB, конфигурации и активы
Комментарии

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

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

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

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

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

  • Pavel Solopov

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

  • Вадим

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

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

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

    • Георгий

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

      • Вадим

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

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

        • Георгий

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

          1. “процесс управляет сразу всей кофигурацией ИТ среды” – неверно в большинстве случаев, охват процесса определяется в начале проектирования, как один из основных оправных пунктов, но, я лично, никогда не видел, чтобы охват был равен ВСЕЙ ИТ-среде, всегда это некое подмножество, выбираемое по разным важным для клиента критериям
          2. “информацию об этой – текущей – конфигурации, а не о каких то других” – неверно, даже в книгах по тексту есть понятия “Configuration baseline” и “Snapshot”, откуда понятно, что процесс может предоставлять информацию не только о текущей конфигурации, но и о других.
          3. Ну и само по себе наличие процесса несет в себе ценность для других процессов (а кроме этого в нем никакой и нет), в том числе через возможность what-if анализа при планировании изменений и релизов

          • Вадим

            ну ладно …… будем считать, что убедили… )))

  • Аида

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

    • Вадим

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

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

      • Аида

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

      • Аида

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

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

        “наверное надо что-то сделать и для упрощения регистрации выполненных изменений с КЕ” – Надо! только что?
        Вобщем Думать, Думать, Думать…

    • Pavel Solopov

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

  • Аида

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

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

    • Вадим

      IMHO если кто-то что-то сделает, то результат должен отражаться в CMDB, иначе она будет совсем не нужна, т.к. не будет содержать актуальной информации.
      если это делается админами без отражения (несмотря на то, что отражение изменения является их обязанностью), потому что муторно и лениво. то за это надо бить палкой по рукам.
      иначе вы будете свое время постоянно тратить, чтобы за ними уследить и выполнить бюрократическую часть их работы.
      должно быть “не занесено изменение в CMDB – работа не закончена, не выполнена”.

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

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

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

      • Аида

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

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

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

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

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

        • Вадим

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

  • Аида

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

  • Дарья

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

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

      Дарья, мы потому и не закрываем архив ранних публикаций, что в них может быть полезная информация, да и комментировать можно любую заметку портала, независимо от её возраста.
      По сути Вашего вопроса: возможно, ответ частично кроется в процедуре “Верификация и аудит”, которая предназначена в том числе для проверки актуальности информации в CMDB. Проверка может выполняться при выполнении определённых действий в других процессах (скажем, расследовании проблем), перед внесением изменений в инфраструктуру (при оценке и планировании изменения), а также регулярно на основе планов аудита (раз в квартал мы выбираем какую-либо область и проверяем корректность данных в CMDB по этой области). Дополнительно в некоторой части инфраструктуры помогут средства автоматического сбора конфигурационной информации и выявления расхождений в CMDB.
      Более подробно можно почитать в книжке Service Transition, раздел 4.3.5.6

      Плюс Дмитрий Исайченко написал замечательную книгу про измерение ITSM, в ней есть глава про управление конфигурациями. Своевременное выявление расхождений данных CMDB с реальным состоянием конфигурационных единиц – одна из двух ключевых практик процесса, для неё и метрики придуманы. Рекомендую почитать.

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

      Ещё немного добавлю.
      Вы пишете, что стали менеджером управления конфигурациями. Также Вы пишете, что не можете сами проверить достоверность. Похоже, что Вас это смущает.

      По моему глубокому убеждению менеджер не должен проверять достоверность. Равно как и менеджер инцидентов не должен решать инциденты – он должен сделать так, чтобы инциденты решались. А Вы, соответственно, отвечаете за то, что CMDB в порядке. Это не означает, что Вы самостоятельно её наполняете, проверяете, актуализируете и так далее. Вам зарплату платят за *организацию* работы, а не её *выполнение* (я так думаю) 🙂

      Что, разумеется, легче сказать, чем сделать. Это тот самый переход от manage self к manage others, который универсально важен для любой области деятельности.

  • Дарья

    Спасибо большое за ответ!
    Как раз являюсь владелицей этой замечательной книги Дмитрия Исайченко. В нашей компании (может так и везде) аудит проводит Администратор КЕ, он же вводил и изначально всю информацию в карточку КЕ, он же является и “нарушителем”, если забыл что-то зафиксировать. Проблема, на мой взгляд, в том, что при проведении аудита этому сотруднику придется признать свою ошибку. Для некоторых людей – это не проблема, но встречаются такие, которые всегда уверены в своей правоте и при проведении аудита вовсе не станут перепроверять за собой. И правда в этой ситуации может и всплывет на поверхность, но очень не скоро и при какой-нибудь случайности. Возможности организовать аудит таким образом, чтобы проверку осуществляло не заинтересованное лицо, нет. Поэтому один из предложенных в книге показателей (САА – актуальность данных CMDB) – не покажет на 100% истинную картину. Возможно я мыслю в неверном направлении, поэтому прошу меня поправить. Поэтому мучающий меня вопрос – как же проверить достоверность или (переформулирую) организовать процесс таким образом, чтобы информация была достоверной – пока остается открытым.

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

      Администратор КЕ – не единственный ведь пользователь информации о данной КЕ? Иначе бы получилось, что он CMDB для себя лично ведёт в той части, которая касается его КЕ. В то время как смысл CMDB – в общем для всех источнике достоверной информации о КЕ и *связях* между КЕ.
      Таким образом, к информации в CMDB обращаются многие, и по разным поводам. Самое очевидное – сотрудники, устраняющие инциденты. Вряд ли все они устраняют только инциденты, связанные со своими КЕ. Тогда вы можете попробовать ввести следующую практику:
      1. администратор КЕ отвечает за актуальность и полноту информации о своих КЕ
      2. если администратор КЕ нашёл и устранил ошибку в CMDB по своим КЕ, ему за это будет только похвала
      3. если кто-то другой нашёл ошибку в CMDB, то ответственный администратор будет каким-то образом наказан (не обязательно материально, не обязательно жёстко)

      • Андрей Труфанов

        Некоторые не называемые, но известные нам, директора настоятельно рекомендуют рассматривать руководителей и экспертов, допускающих халатность в отношении конфигурационной информации, через прицельные приспособления.
        Выявлять расхождения можно:
        1. целенаправленными аудитами со строго очерченным охватом;
        2. через процесс верификации в процессе выполнения работ с оборудованием, лицензиями и прочими ИТ-активами;
        3. инструментально, опираясь на discovery инструментарий.
        К.м.к. сейчас основная задача, это выяснить масштаб бедствия, т.к. из исходного запроса понимание этого не звучало. После появления такого знания нужно будет выбрать стратегию и план меропритятий по наведению порядка и поддержанию уровня “чистоты”.
        Кроме прочего, рекомендую попробовать измерить текущий “уровень доверия к CMDB” у тех коллег, которые ей пользуются. И работать над повышением этого показателя, увеличивая качество данных и их полезность/востребованность для потребителей.

        • Дарья

          Спасибо большое за ответы! Буду пробовать использовать это на практике:)

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

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

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