Change Management
Что? Зачем? И почему?

Incident Management - восстанавливает сервис.
Problem Management - убирает причину поломки.
Change Management - предотвращает сбои и улучшает сервис.

Если инцидент - пожар, проблема - неисправная проводка,
то Change - это разрешение на ремонт, проверенный план и подписанный акт.
Без него «быстрый фикс» становится бомбой.
Примеры:
▪️ Обновление операционной системы на критически важном сервере.
▪️ Развертывание новой версии корпоративного приложения.
▪️ Изменение конфигурации сетевого оборудования, чтобы увеличить пропускную способность.
▪️ Удаление устаревшего, неиспользуемого компонента инфраструктуры.

Что такое Change Management?
Это процесс контроля изменений в инфраструктуре, продуктах и процессах.
Не запрет на перемены.
А структура для безопасных изменений.

Основные цели Change Management
Цель - не замедлить.
Цель - предотвратить ущерб от "хорошей пятничной идеи в 20:37".

Почему это важно? Потому что:
▪️70% инцидентов начинаются с изменения.
▪️90% из них - с изменения, которое "никто не заметил".
▪️100% из них - с изменения, которое не прошло проверку.

1️⃣ Контроль рисков
Каждое изменение оценивается: что может пойти не так?
Кто пострадает?
Как откатим?
2️⃣Минимизация сбоев
Не "сделаем и посмотрим".
А: протестируем → согласуем → внедрим → проверим.
3️⃣ Прозрачность и аудит
Где, что, кем и когда было изменено?
Теперь вы можете ответить на этот вопрос.
5️⃣ Координация между командами
Разработка, SRE, поддержка, безопасность - все в одном поле.
Никаких сюрпризов в релизе.
5️⃣ Сохранение стабильности сервиса
Не ради "процедуры".
А ради того, чтобы клиенты продолжали пользоваться сервисом.

Когда запускается Change Management?
Всегда.
Если изменение касается:
▪️кода,
▪️конфигурации,
▪️сети,
▪️доступов,

Все идёт через Change Request (CRQ).
Даже если:
▪️"это мелочь",
▪️"раньше так делали без согласования",
▪️"сроки горят".
Горящие сроки - не повод для горящего сервиса.

Как работает процесс?
1️⃣ Инициация изменения
Кто-то хочет что-то изменить.
Пишет CRQ:
▪️Что?
▪️Зачем?
▪️Как?
▪️Риски?
▪️План отката?
2️⃣ Оценка и согласование
Change Advisory Board (CAB) - или упрощённый аналог - смотрит:
▪️Нет ли конфликтов с другими изменениями?
▪️Есть ли ресурсы?
▪️Достаточно ли тестов?
▪️Кто утвердит?
3️⃣ Реализация
Изменение внедряется в согласованное окно.
С контролем, мониторингом, поддержкой на связи.
5️⃣ Проверка и закрытие
Работает ли?
Клиенты не страдают?
Метрики в норме?
→ Закрываем CRQ.
→ Фиксируем в базе знаний.

Кто участвует?
▪️Change Manager - не бюрократ, а координатор.
Он держит процесс в чистоте и вовремя.
▪️Заявитель - разработчик, инженер, SRE, менеджер продукта - кто инициирует изменение.
▪️CAB (Change Advisory Board) - представители поддержки, безопасности, SRE, продуктовой команды.
▪️Incident Manager / ТехПод - на связи, если что-то пойдёт не так.

Типичные ошибки
▪️«Это быстро, давайте без CRQ»
→ Быстро - не значит безопасно.
→ Без CRQ - без отката.
→ А значит, и без контроля.
▪️Change Management = бюрократия
Нет.
Это инструмент доверия.
Ты уверен, что никто не полезет в прод в пятницу вечером без плана.
▪️Не фиксируют результат
Решение есть.
CRQ закрыт.
А в базе знаний - пусто.
→ Через месяц - тот же инцидент.
Потому что "все забыли".

Зачем это измерять?
Потому что:
▪️Количество изменений, прошедших через процесс
Если 30% - значит, у вас полумрак.
Если 100% - значит, порядок.
▪️Процент изменений, вызвавших инциденты
Должен стремиться к нулю.
Если не стремится - где-то прорыв.
▪️Среднее время согласования
Не должно быть "ожидание 5 дней".
Но и не "подписали за 2 минуты".
▪️Доля экстренных изменений
Если больше 10% - значит, процесс не работает.
Люди обходят его.

Итог
Change Management - это тормоз.
Но не для прогресса.
Для хаоса.
Он не запрещает ехать.
Он не даёт врезаться.

#ChangeManagement #ITIL #TechSupport