Управление изменениями в ИТ-инфраструктуре: процесс по ITIL, роли и автоматизация

Процесс управления изменениями в ИТ — это планирование и реализация добавления нового элемента в ИТ-инфраструктуру, замены или изъятия старого. Без этого не обойтись, так как в любом действующем ИТ-ландшафте периодически выходят из строя устройства, обновляется ПО, модернизируется оборудование. Когда изменения в ИТ-инфраструктуре срочные и являются следствием форс-мажоров и сбоев, их последствия сложно предвидеть. Поэтому они часто становятся причинами инцидентов. Чтобы сделать их управляемыми, предсказуемыми и внедрять с наименьшими рисками, управление изменениями в ITIL 4 выделено в отдельный процесс — Change Enablement. Рассмотрим, как он реализуется в ITSM-решении.

---

Содержание

Типы изменений
Стандартные изменения
Нормальные изменения
Экстренные изменения

Зачем управлять изменениями

Кто участвует: роли и CAB

Этапы процесса управления изменениями
Идентификация
Обсуждение
Оценка и согласование
Планирование
Реализация
Мониторинг и завершение

Как оценить влияние изменения: CMDB и ресурсно-сервисная модель

Метрики и типичные ошибки

Главное

---

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

Изменение может затрагивать совсем незначительную на первый взгляд составляющую инфраструктуры. Но так как все ее компоненты связаны с ИТ-сервисами, бизнес-процессами, а также друг с другом, в любом случае важно учитывать характеристики объекта и возможное влияние на пользователей и бизнес. По процессу управления изменениями ITIL они бывают трех типов: стандартные, нормальные и экстренные. Первые два типа планируются, третий не бывает плановым.

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

Стандартные — это регулярные и заранее согласованные изменения с низкими рисками. Для них существуют понятные сценарии выполнения, поэтому они не требуют отдельного длительного согласования. Например:

• обновление программного обеспечения;
• создание стандартной учетной записи сотрудника;
• обновление базы данных по утвержденному регламенту.

Главная особенность стандартного изменения — предсказуемость. Компания заранее понимает его влияние, необходимые ресурсы и последовательность действий.

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

Это более существенные изменения, для которых нет единого утвержденного алгоритма реализации. Они требуют оценки рисков, анализа влияния и согласования. Например:

• изменение архитектуры приложения;
• обновление критичной ИТ-системы;
• перенос сервиса на другой участок инфраструктуры.

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

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

Это изменения, которые компания стремится свести к минимуму. Они возникают в ответ на сбои и инциденты и требуют максимально быстрого внедрения. Например:

• исправление критической уязвимости;
• восстановление работоспособности сервиса после сбоя;
• устранение ошибки, которая влияет на пользователей.

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

Стандартные изменения реализуются с помощью неоднократно провереннной последовательности действий и несут в себе минимум рисков. Нормальные внедряются планово, поэтому у специалистов могут проанализировать их, оценить и прогнозировать последствия. Риски есть, но они предсказуемы. Экстренные изменения самые опасные с точки зрения рисков, так как не оставляют возможности оценить их и подготовиться.

Зачем управлять изменениями

При масштабировании бизнеса инфраструктура меняется постоянно: развиваются сервисы, растет количество интеграций, увеличивается зависимось бизнеса от ИТ. В результате управление изменениями выходит за рамки контроля отдельных технических операций. Если процесс не выстроен, компания сталкивается с типичными проблемами.

Без управления изменениями	С управлением изменениями
Выполняются без полной оценки последствий	Риски анализируются заранее
Сложно определить причины сбоя	Сохраняется история всех действий
Возникают непредвиденные простои	Есть план внедрения и отката
Непонятно, как ИТ влияет на бизнес	ИТ и бизнес работают в едином информационном поле

Управление изменениями позволяет перейти от модели «реагируем на проблемы» к модели «предвидим последствия и управляем развитием и обновлением инфраструктуры».

Кто участвует: роли и CAB

Успех изменения напрямую зависит от людей, которые его реализуют. При выстроенном процессе обычно в нем участвуют несколько специалистов со своими зонами ответственности. Рассмотрим ключевые роли, а также функции CAB — Консультативного совета по изменениям. Цепочка их взаимодействия выглядит так.

Инициатор — тот, кто замечает проблему или потребность и продумывает путь решения, для которого необходимо изменение. Он формулирует запрос — Request for Change (RFC), или иногда он обозначается как Change Request (CR), обосновывает его необходимость и ценность, направляет менеджеру изменений.

Менеджер изменений — это куратор всего процесса. Он обеспечивает соблюдение регламентов, рассматривает поступающие запросы, классифицирует их, организует рассмотрение на CAB, производит оценку рисков. Менеджер изменений проверяет RFC на соответствие требованиям и передает владельцу услуги.

Владелец услуги — ответственный за сервис, которого касается изменение. Он также оценивает потенциальное влияние и последствия. Затем запрос уходит на рассмотрение CAB.

СAB — консультативный комитет экспертов, которые оценивают изменения и выносят решение, внедрять или нет. Обычно у CAB по ITIL есть постоянный состав, но могут привлекаться и другие специалисты, если того требует специфика изменения. Эксперты анализируют риски, влияние на смежные системы и, если запрос получает одобрение, определяют оптимальный сценарий реализации. Затем владелец услуги передают RFC исполнителям.

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

Этапы процесса управления изменениями

Внедрение изменения происходит в несколько последовательных этапов.

Идентификация

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

Для изменения потребуется подать запрос в Service Desk — Change Request (CR). Либо его вручную составляет специалист, либо заявка автоматически создается системой зонтичного мониторинга, если метрики приближаются к критическим значениям.

Запрос должен содержать всю информацию на старте: описание изменения, обоснование необходимости, предполагаемые результаты и примерный план реализации. Например, в случае обновления ИТ-системы план в CR будет таким:

1. Создание бэкапов текущей версии системы.
2. Установка новой версии на тестовом сервере.
3. Тестирование функциональности и совместимости данных.
4. Перенос изменений на рабочий сервер (планируемое время — воскресенье, 02:00 по местному времени).

На этом этапе важно заложить в запрос максимум данных. Например, Naumen Service Desk автоматически извлекает информацию из CMDB и системы мониторинга.

Обсуждение

Изменение не бывает обособленным и изолированным. Оно всегда на что-то влияет, поэтому при планировании необходимо учитывать мнение заинтересованных сторон. Чтобы определить участников, нужно учесть:

• сервисы, работоспособность которых обеспечивает данное оборудование;
• критичность этих сервисов для бизнес-процессов;
• оборудование, с которым связан объект изменения.

Ответственный за изменение рассылает заинтересованным сторонам Request for comments (RFC) — запрос на комментирование. Они получают всю информацию, изложенную в CR, возможность сформулировать предложения и дополнить данными, которыми инициатор мог не располагать. Далее он анализирует полученные комментарии и на их основе актуализирует запрос на изменение.

Оценка и согласование

Когда обсуждение завершено, ответственный, исходя из всей полученной информации, оценивает:

• сроки реализации;
• ресурсы (бюджет, трудозатраты);
• возможные риски.

И дополняет этими вводными запрос. Затем отправляет максимально наполненный данными CR на согласование в CAB, где и решается: быть или не быть изменению.

Планирование

На начальном этапе в запросе на изменение составляется предварительный план реализации. Здесь он обретает более четкую форму — превращается в список конкретных задач с конкретными сроками. Задачи назначаются на исполнителей, и в указанный срок изменение переходит на стадию реализации.

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

Реализация

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

Например, в Naumen Service Desk специалисты работают прямо в карточке своей задачи: оставляют комментарии, формируют отчеты. Эта информация доступна другим участникам, поэтому взаимодействие происходит в одном контексте, а весь процесс прозрачен для ответственного за изменение. Также все этапы работы отображаются на диаграмме Ганта.

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

Мониторинг и завершение

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

Как оценить влияние изменения: CMDB и ресурсно-сервисная модель

Чтобы принимать обоснованные решения, компания должна понимать текущее состояние своей инфраструктуры: какие объекты существуют, как они связаны между собой и какие сервисы зависят от конкретных компонентов. Эту задачу помогает решать CMDB (Configuration Management Database) — база данных конфигурационных единиц в Service Desk. Она хранит информацию об объектах инфраструктуры и их взаимосвязях: серверах, приложениях, сетевом оборудовании, сервисах и других элементах ИТ-ландшафта. Например, в CMDB специалист может увидеть:

• какие виртуальные машины использует объект, который нужно изменить;
• какие ИТ-сервисы зависят от него;
• какие подразделения бизнеса могут столкнуться с последствиями изменения.

Service Desk и CMDB создают основу для управления изменениями: система — для организации процесса и взаимодействия, база конфигураций — для понимания того, на что именно повлияет изменение.

На основе CMDB строится ресурсно-сервисная модель (РСМ). Она наглядно показывает связи технических компонентов с услугами. Это помогает заранее определить критичность изменения и выбрать подходящее время для его реализации.

Помимо CMDB в управлении изменениями помогает искусственный интеллект. ИИ-модели в мониторинге анализируют метрики оборудования и могут предсказать, когда оно выйдет из строя и на какие сервисы повлияет.

Таким образом вместо срочного восстановления после сбоя компания может заранее запланировать изменение: заменить устаревшие маршрутизаторы, расширить сетевые мощности или изменить архитектуру подключения. Переход от реактивной работы к проактивному управлению — одна из ключевых целей современных ITSM-процессов.

Метрики и типичные ошибки

Чтобы оценивать выстроенное управление изменениями: насколько процесс эффективен, стабилен и безопасен — используются несколько основных метрик.

Коэффициент успешных изменений — это доля преобразований, реализованных с первой попытки, без непредвиденных сбоев, последствий и откатов. Определяется как отношений таких изменений к общему числу внедренных в расчетный период. Чем выше значение этой метрики — тем лучше.

Доля экстренных изменений — процент тех, что внедрены не по установленному регламенту, а в срочном порядке для устранения критического сбоя, аварии или уязвимости. Этот показатель стремятся снижать и следить, чтобы он не превышал 10%. Высокое значение говорит о недостаточной проактивности в управлении инфраструктурой.

Количество инцидентов, спровоцированных изменениями — сюда входят сбои в работе и доступности ИТ-сервисов, происшедших в результате проведенных плановых работ. Эта метрика показывает качество работы с изменениями. Если она высокая, они некорректно оцениваются, а последствия не продумываются, как и риски. Снижения этого показателя говорит о росте зрелости управления изменениями.

Среднее время реализации изменения — это период от регистрации Request for Change до его реализации. С его помощью можно судить о скорости работы ИТ-подразделения. Чаще всего эта метрика увеличивается из-за долгой оценки и согласований. Однако слишком низкое значение может свидетельствовать, что эта работа ведется поверхностно, а значит, повышаются риски. Эта метрика нуждается в детализации за счет разбивки реализации изменения на этапы.

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

Главное

1. Изменения необходимы в любом действующем ИТ-ландшафте. Когда они спонтанные и неподготовленные, высоки риски сбоев в ИТ-сервисах и бизнес-процессах.
2. Управления изменениями в ИТ в ITIL 4 выделено в отдельный процесс — Change Enablement, который помогает сделать их контролируемыми, продуманными, с предсказуемыми результатами.
3. Автоматизация процесса управления изменениями с помощью ITSM-решения позволяет сформировать четкий и регламентированный процесс изменений, который базируется на выстроенных цепочках взаимодействия и актуальных данных об инфраструктуре в CMDB.

Готовы взять изменения в ИТ под контроль? Покажем, как это сделать с  помощью решений Naumen. Оставьте заявку, и мы проведем демонстрацию.