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

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

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

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

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

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. Павел Солопов

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

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

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

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

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

    1. Андрей

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

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

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

  2. Роман Журавлёв

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

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

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

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

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

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

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

    — ...

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

  3. Павел Солопов

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

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

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

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

  4. Роман Журавлёв

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

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

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

  5. Павел Солопов

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

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

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

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

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

АВГ
28