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

Где граница между изменениями и “просто работой”?

Опубликовано 20 января 2011
Рубрики: ITIL, ITSM, Управление изменениями
Комментарии

Скептик отвечает на вопрос читателя о границе между Изменениями (проводимыми под контролем соответствующего процесса) и рутинной работой по администрированию.

Вкратце ответ Скептика звучит так:

"Записи об изменениях содержат информацию о том, что что-то было изменено. Если вам важно знать, когда что-то изменяется – регистрируйте такие действия. Любая задача по администрированию, по которой должна быть обеспечена возможность последующего аудита проведенных модификаций, должна управляться как изменение."

Аргументы и подробности – в блоге Скептика

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

  • Хорошее определение предлагает многоуважаемый Скептик, но применить его реально только при разработке, чтобы на высоком уровне как-то зафиксировать, понятие изменения.
    Но вот в текущей деятельнсоти оно окажется бесполезным.

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

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

    Нужные простые правила. Несколько вопросов ответив на которые специалист поймёт изменение или не изменение. А вот что за вопросы это должны быть?…

    • Андрей

      Скептик тоже видимо готовился к семинару itSMF Russia 🙂
      Эта тема активно обсуждалась. В общих словах решили, что в случае, когда риски изменения велики (например, конфигурационные файлы крупного портала), то регистрируем, а если малы (файлы тестовой среды), то нет. Теперь правда вопрос сместился от «нужно ли знать?» до «рисково ли это?», но, по крайней мере, теперь ответ может быть как-либо измерен в потерях, простоях или иначе.
      Ну а дальше частности: можно выделить группу ЭК (например, критичные сервера) и любые действия с ними регистрировать; можно выделить вид действий (например, действия с электропитанием) и их всегда регистрировать, а можно регистрировать вообще все изменения и 95% из них пускать по упрощенной схеме. It depends.

  • “вопрос сместился от «нужно ли знать?» до «рисково ли это?»”
    …да нет, никуда он, скорее всего, не сместился. Просто “рисково ли это” – один из вариантов ответа на уточняющий вопрос “А почему это нужно знать?”
    Другие варианты:
    – “дорого ли это?” (отдельно – в отношении работ по изменению, отдельно – в отношении цены (не)проведения изменения)
    – “связано ли это с формальным соответствием (compliance)?”
    – “сложно ли это?”
    – “ресурсоемко ли это?”
    – …

    Скептик, во всяком случае, в своем блоге именно так развивает основной ответ. Да и я с ним вполне согласен.

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

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

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

    А про жижу – это вопрос целей в первую очередь. Я вот знал одного ИТ-руководителя, который своему менеджеру изменений поставил такую цель: 100% отклоненных RFC + стабильно высокая удовлетворенность инициаторов.
    Хотя “закостенелая жижа” – метафора сильная.

    • Ага, эдакое промежуточное состояние вещества получается. 🙂

      как грязь на московских дорогах, и жидкая и с ботинок не отчистишь. 🙂

  • Андрей

    Собственно измеримость критериев и является показателем их пригодности. А вариантов вопросов может быть сколько угодно.

  • Измеримость измеримостью, если показатель измерим, это не значит, что его может измерить любой специалист.
    Обладает ли каждый системный администратор знаниями достаточными для того, чтобы ответить на вопрос:
    “Сколько стоят эти изменения?”, “Какие потери понесёт наша компания если не сделать эти изменения?”, “Высокий ли риск у этого изменения?”.
    Особенно по последнему вопросу, если бы каждый администратор мог честно и точно на него ответить, то и процесс управления изменениями не понадобился бы.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM