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

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

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

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

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

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

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

ITIL 4 Foundation, MPT, DSV, DPI, CDS, HVIT, DITS
и другие интересные аббревиатуры от участников разработки

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

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

    Но вот в текущей деятельнсоти оно окажется бесполезным.

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

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

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

    • Андрей

      Скептик тоже видимо готовился к семинару itSMF Russia 🙂

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

      Ну а дальше частности: можно выделить группу ЭК (например, критичные сервера) и любые действия с ними регистрировать; можно выделить вид действий (например, действия с электропитанием) и их всегда регистрировать, а можно регистрировать вообще все изменения и 95% из них пускать по упрощенной схеме. It depends.

  • «вопрос сместился от «нужно ли знать?» до «рисково ли это?»»

    ...да нет, никуда он, скорее всего, не сместился. Просто «рисково ли это» - один из вариантов ответа на уточняющий вопрос «А почему это нужно знать?»

    Другие варианты:

    — «дорого ли это?» (отдельно — в отношении работ по изменению, отдельно — в отношении цены (не)проведения изменения)

    — «связано ли это с формальным соответствием (compliance)?»

    — «сложно ли это?»

    — «ресурсоемко ли это?»

    — ...

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

  • Да... Не простые вопросы, очень уж они зависят от знания, квалификации и кругозора специалиста.

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

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

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

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

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

    Хотя «закостенелая жижа» — метафора сильная.

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

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

  • Андрей

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

  • Измеримость измеримостью, если показатель измерим, это не значит, что его может измерить любой специалист.

    Обладает ли каждый системный администратор знаниями достаточными для того, чтобы ответить на вопрос:

    «Сколько стоят эти изменения?», «Какие потери понесёт наша компания если не сделать эти изменения?», «Высокий ли риск у этого изменения?».

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


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

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

  • Рубрики

  •  
  • Самое свежее

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT