Поддержка изменений - важный и нужный элемент управления ИТ
в компаниях любого масштаба.
в компаниях любого масштаба.
Вы не любите управление изменениями?
Вы просто не умеете их готовить!
Вы просто не умеете их готовить!
Практику поддержки изменений часто обвиняют в формализме и всеми силами саботируют её внедрение. Причиной чаще всего является негативный опыт бюрократического согласования «любого чиха».
В то же время это важный и нужный элемент управления ИТ в компаниях любого масштаба.
В то же время это важный и нужный элемент управления ИТ в компаниях любого масштаба.
Изменение — намеренная модификация, которая должна быть оценена по риску и авторизована.
Поддержка изменений — это подход к управлению изменениями, обеспечивающий контролируемое прохождение изменений через принятие решений на основе риска и координацию времени выполнения.
Поддержка изменений — это подход к управлению изменениями, обеспечивающий контролируемое прохождение изменений через принятие решений на основе риска и координацию времени выполнения.
Практика фокусируется на том, чтобы изменения внедрялись эффективно и безопасно.
Цель — сделать изменения предсказуемыми:
Оценить масштаб бедствия влияние изменения помогает управление конфигурациями и управление знаниями.
Оценка риска не всегда равна формальному заседанию CAB (консультативного совета по изменениям): она может выполняться быстро и распределённо, но должна быть явной, документируемой и согласованной с управлением рисками.
Контроль должен быть соразмерен риску:
Цель — сделать изменения предсказуемыми:
- получить понятное обоснование,
- выполнить оценку риска,
- авторизовать,
- определить место в графике изменений .
Оценить масштаб бедствия влияние изменения помогает управление конфигурациями и управление знаниями.
Оценка риска не всегда равна формальному заседанию CAB (консультативного совета по изменениям): она может выполняться быстро и распределённо, но должна быть явной, документируемой и согласованной с управлением рисками.
Контроль должен быть соразмерен риску:
- нормальное изменение согласуется в штатном порядке после оценки зоны влияния и рисков, после чего вносится в график изменений таким образом, чтобы не было конфликтов с уже запланированными изменениями,
- стандартное изменение заранее одобрено и может выполняться по рабочей инструкции,
- экстренное изменение допускает ускоренную авторизацию, но в обязательном порядке требует последующего анализа.
Почему важен график изменений? Во избежание конфликтов.
При этом важно учитывать комплексно все виды изменений. Допустим, если запланировано в рамках регулярного регламентного окна какое-то нормальное изменение, предварительно следует убедиться в отсутствии стандартных изменений, способных оказать влияние и предполагаемых к выполнению в рамках того же окна.
При этом важно учитывать комплексно все виды изменений. Допустим, если запланировано в рамках регулярного регламентного окна какое-то нормальное изменение, предварительно следует убедиться в отсутствии стандартных изменений, способных оказать влияние и предполагаемых к выполнению в рамках того же окна.
Важно! Заявлять необходимо о ЛЮБЫХ, даже самых незначительных, изменениях за исключением тех стандартных изменений, для которых утвержденная модель не предполагает отправку RFC.
Вот тут и начинаются обвинения в формализме! Казалось бы мелочь: быстро перезагрузить сервер, коммутатор или переключить пару кордов. Зачем разводить бюрократию, отправлять заявку?.. А если в этот самый момент идет какая-то важная передача данных, о которой сетевому инженеру не известно, то на пустом месте получаем инцидент, критичность которого зависит от критичности нарушенного бизнес-процесса.
Несколько примеров для наглядности.
- Запрос на обновление версии СУБД для критичной ИТ-услуги оценивается по риску, авторизуется и планируется в графике изменений на окно низкой нагрузки.
- Регулярное обновление антивирусных сигнатур выполняется по предварительно утверждённой модели изменения без отдельной авторизации каждый раз и заранее заносится в график изменений для информации.
- Запрос на создание новых виртуальных машин выполняется по предварительно утверждённой модели изменения без отдельной авторизации каждый раз и планируется в графике изменений на окно низкой нагрузки
- Экстренное изменение для устранения инцидента выполняется с ускоренной авторизацией, а затем проводится обзор после внедрения. При этом останавливаются все работы по графику изменений. Если плановое изменение уже выполняется и не подверглось влиянию инцидента, то решение о его принудительном завершении будет зависеть от оценки влияния на него экстренного изменения и критичности последствий прерывания процесса.