Управление изменениями (Change Management) по ITIL

Change Management (управление изменениями) — это процесс ITIL, который вводит любое изменение в IT-инфраструктуре через контролируемую процедуру: оценку риска, согласование, планирование отката и фиксацию. Цель — внедрять нужные изменения, не ломая работающие сервисы.

Эта страница — часть разбора процессов ITIL и опирается на материал блога «Договор на IT-обслуживание: на что смотреть», где управление изменениями упоминается как часть зрелого регламента услуг.

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

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

Change Management отвечает на простой вопрос: «прежде чем что-то менять в боевой инфраструктуре, кто это согласовал, кто оценил риск и что мы будем делать, если станет хуже?». Процесс не запрещает изменения — он делает их предсказуемыми. Для бизнеса это означает меньше «внезапных» простоев из-за работ, о которых никто не знал.

Типы изменений по ITIL

ITIL делит изменения на три категории — по уровню риска и порядку согласования.

• Стандартные (standard) — рутинные, низкорисковые, заранее одобренные изменения с известной процедурой. Например, заведение нового пользователя, плановое обновление антивирусных баз, добавление рабочего места по шаблону. Отдельного согласования каждый раз не требуют — порядок уже утверждён.
• Нормальные (normal) — изменения, которые проходят полную процедуру: запрос, оценка риска, согласование, планирование, внедрение, проверка. Сюда попадает большинство значимых работ: обновление сервера, миграция сервиса, изменение топологии сети.
• Экстренные (emergency) — изменения, которые нужно внести срочно, обычно чтобы устранить критичный инцидент или закрыть уязвимость ИБ. Процедура ускоренная, но фиксация и согласование (хотя бы постфактум) всё равно обязательны.

Как устроен процесс

Нормальное изменение проходит несколько шагов, и каждый из них — это точка контроля.

Запрос на изменение (RFC, Request for Change) — формальная заявка: что меняем, зачем, на каких системах, когда, кто исполнитель. Без RFC изменение не существует для процесса.

Оценка и приоритизация — анализ риска и влияния: что сломается, если пойдёт не так, сколько пользователей затронуто, есть ли зависимость от других систем. На этом шаге изменение либо допускается, либо отправляется на доработку.

Согласование — низкорисковые изменения утверждает ответственный (change manager), значимые и рисковые выносятся на CAB (Change Advisory Board — совет по изменениям). CAB — это не обязательно совещание: для среднего бизнеса это может быть короткое согласование между техническим руководителем и заказчиком.

Планирование и окно — определяется время работ (обычно технологическое окно в нерабочее время), план внедрения и обязательный план отката (rollback) — как вернуть всё назад, если изменение провалится.

Внедрение и проверка — изменение вносится, после чего проверяется, что сервисы работают штатно. Если нет — выполняется откат.

Закрытие и ретроспектива — изменение фиксируется в журнале. Неудачные изменения разбираются: почему оценка риска не сработала. Этот вывод часто становится входом для управления проблемами.

Связь с другими процессами

Change Management не работает в вакууме. Запрос на изменение часто приходит из Service Desk — например, пользователь запросил новый доступ. Если инцидент требует структурного исправления, Problem Management формирует RFC на устранение корневой причины. А сам Change Management — один из ключевых процессов в общей системе ITSM (IT Service Management — управление IT-услугами).

Как это выглядит у среднего бизнеса

Полноценный CAB с регламентами и ролями — это история крупных организаций. Для компании на 50–150 рабочих мест управление изменениями обычно реализуется проще, но по той же логике: значимые работы не делаются «на горячую» в рабочее время, у каждой есть согласованное окно, план отката и уведомление пользователей. Даже простой регламент «любое изменение на боевом сервере — только по согласованию и с возможностью откатить» снимает большую часть самонанесённых инцидентов.

В рамках IT-аутсорсинга управление изменениями — часть зрелого процесса обслуживания. Мы вносим изменения в инфраструктуру клиента контролируемо: с оценкой риска, в согласованное окно, с планом отката и фиксацией в отчёте. Это снижает риск, что плановая работа превратится в незапланированный простой.

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

• ITIL-процессы — управление IT-услугами — общий каркас, в который входит управление изменениями
• Управление проблемами (Problem Management) — поставщик запросов на изменение для устранения корневых причин
• ITSM — управление IT-услугами — управленческая дисциплина, частью которой является Change Management
• Service Desk — единая точка обращений — источник части запросов на изменение