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

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

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

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

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

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

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

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

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

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

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

    0
    0
    1. Андрей

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

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

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

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

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

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

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

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

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

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

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

    — ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    0
    0

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

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

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

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

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)