Change Management: управление изменениями по ITIL 4

Зачем нужен процесс управления изменениями

Большинство серьёзных инцидентов в IT-инфраструктуре — результат плохо продуманных изменений. Обновили версию библиотеки — легло приложение. Перенастроили firewall — отвалился филиал. Мигрировали БД — сломалась интеграция. По разным оценкам, 60–80% инцидентов в продакшене связаны с недавними изменениями.

Change Management решает эту проблему через формализацию:

• Любое изменение фиксируется как RFC (Request for Change).
• Оценивается риск для бизнес-процессов.
• Согласовывается с заинтересованными сторонами.
• Планируется окно выполнения с уведомлением пользователей.
• Выполняется с заранее описанным планом отката (rollback).
• Анализируется постфактум — что пошло хорошо, что не так.

Три типа изменений

Стандартные изменения

Низкий риск, типовая процедура, предварительно утверждённый шаблон. Не требуют индивидуального согласования каждый раз. Примеры:

• Выдача доступа по заявленному шаблону
• Плановое обновление антивирусных баз
• Создание учётной записи нового сотрудника
• Установка стандартного софта из каталога

Стандартные изменения — 70–80% от общего потока. Чем больше изменений вы можете переводить в эту категорию, тем ниже накладные расходы.

Нормальные изменения

Требуют оценки рисков и формального согласования. Это основной поток «серьёзных» изменений. Примеры:

• Обновление версии корпоративного ПО
• Изменение политики паролей в AD
• Миграция БД на новое хранилище
• Добавление нового домена в инфраструктуру

Для нормальных изменений работает полный цикл: оценка → CAB → планирование → внедрение → PIR.

Экстренные изменения

Проводятся срочно для устранения критичного инцидента или угрозы безопасности. Согласование — в упрощённой процедуре (Emergency CAB или устное согласование CTO/CIO), но обязателен разбор постфактум.

• Патч критичной уязвимости безопасности
• Откат аварийного обновления
• Экстренное увеличение ресурсов сервера

Жизненный цикл RFC

Стандартный поток для нормального изменения включает пять этапов:

1. Регистрация RFC — заявитель описывает изменение: что, зачем, когда, какие системы затронуты, план реализации, план отката.
2. Оценка рисков и impact-анализ — назначенный инженер анализирует возможные последствия, затрагиваемые сервисы, необходимые ресурсы.
3. Согласование CAB (Change Advisory Board) — группа из представителей IT и бизнеса утверждает или отклоняет. Для мелких — упрощённое согласование.
4. Планирование и выполнение — назначается окно работ (обычно вне рабочего времени), уведомляются пользователи, выполняется изменение.
5. Post-Implementation Review (PIR) — через 1–7 дней разбор: всё ли прошло по плану, нужна ли корректировка, были ли инциденты.

CAB — Change Advisory Board

CAB — это регулярное совещание, на котором рассматриваются RFC. Типовой состав:

• Change Manager (ведёт встречу)
• Представитель инфраструктуры
• Представитель приложений / разработки
• Представитель информационной безопасности
• Представители бизнеса (если затрагиваются критичные сервисы)

Частота — еженедельно или раз в две недели. Длительность — 30–60 минут. Повестка — список RFC с готовой документацией.

План отката: обязательный элемент

Ни одно изменение не должно приниматься без чёткого плана отката. Минимум вопросов, на которые отвечает rollback-план:

1. Критерии отката — при каких симптомах принимается решение откатывать.
2. Триггер решения — кто и в какой момент решает откатывать.
3. Процедура отката — конкретные шаги, команды, восстановление из бэкапа.
4. Оценка времени — за сколько физически можно откатиться.
5. Кто выполняет — конкретные имена дежурных инженеров.

Для сложных изменений план отката репетируется на тестовой среде до выполнения на продакшене.

Окно изменений

Окно изменений (change window) — заранее согласованный интервал времени, в который проводятся работы с возможным downtime. Цели:

• Минимизировать влияние на пользователей
• Дать бизнесу возможность спланировать работу
• Обеспечить наличие ответственных на случай проблем

Типовые окна:

• Стандартное — ночью с субботы на воскресенье (наименьшая нагрузка)
• Еженедельное — заранее известный регулярный интервал (например, вторник 22:00–00:00)
• Ad-hoc — по согласованию с бизнесом для нестандартных случаев

Критичные системы часто имеют change freeze — периоды, когда изменения запрещены полностью (например, закрытие квартала, чёрная пятница, год).

Post-Implementation Review

PIR — обязательный этап, который большинство команд пропускает. Зря. Это 15-минутный разбор, который отвечает на 5 вопросов:

1. Достигнуты ли цели изменения?
2. Соответствует ли фактический результат плану?
3. Были ли незапланированные downtime или инциденты?
4. Что сработало хорошо?
5. Что можно улучшить в следующий раз?

Результат PIR — пополнение базы знаний и корректировка шаблонов для будущих изменений. Подробнее о БЗ — в статье о базе знаний.

Метрики процесса

Типовые ошибки

• Слишком жёсткая процедура для всех — даже мелкое изменение требует часа бумажной работы. Команда саботирует через «закрытие глаз». Решение: три уровня процедуры по типам.
• CAB как формальность — изменения рассматриваются «задним числом», когда работа уже сделана. Решение: без одобрения CAB изменение не выполняется технически (через права доступа к продакшну).
• Нет связи с инцидентами — когда после изменения падает сервис, инцидент не привязывается к RFC. Метрика «incidents caused by changes» не работает. Решение: обязательное поле «связано с изменением» в форме инцидента.
• План отката только на бумаге — в момент аварии оказывается, что бэкапа нет или процедура не работает. Решение: тест плана отката перед выполнением критичных изменений.
• Нет PIR — уроки не извлекаются, одни и те же ошибки повторяются. Решение: PIR — обязательный шаг в workflow изменения, без него заявка не закрывается.

Поддержка в ITSM-системе

Технологически Change Management требует:

• Отдельный тип заявки «Изменение» с расширенной формой
• Шаблоны стандартных изменений с преднастройкой
• Мультиэтапные согласования с разными ролями
• Связи RFC с инцидентами и проблемами
• Календарь изменений для визуализации окон работ
• Автоматическая отправка уведомлений заинтересованным

Всё это есть в TIQQET как встроенный workflow.

Вывод

Change Management — это не бюрократия, а страховка от крупных инцидентов. Хорошо выстроенный процесс сокращает количество аварий, связанных с изменениями, на 40–60% в первый же год.

Ключ к успеху — дифференцированный подход. Стандартные изменения проходят на автопилоте, нормальные получают CAB-внимание, экстренные — упрощённую процедуру с обязательным разбором. Лёгкая процедура плюс жёсткий PIR работают лучше, чем тяжёлый формализм плюс саботаж.