Изменения в ИТ-инфраструктуре: зачем ими управлять и как это делать

Изменения неизбежны в любой инфраструктуре. Бизнес-процессы развиваются и требуют новых мощностей, действующее оборудование изнашивается, у ПО выходят обновления. Все это — изменения. Чем крупнее компания, тем больше изменений.

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

Что такое изменения и какими они бывают

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему управление изменениями необходимо

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

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

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

Что понадобится для управления изменениями

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

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

Business Service Monitoring. Зонтичный мониторинг собирает данные со всех участков ИТ-инфраструктуры, нормализует их, анализирует и передает в ITSM.

Service Desk. Это решение помогает при управлении изменениями, так как отражает динамические процессы ИТ-инфраструктуры. Если системы мониторинга и учета фиксируют состояние, то в Service Desk заинтересованные стороны взаимодействуют при выполнении общей задачи.

Как управлять изменениями

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

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

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

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

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

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

Как внедрить изменение

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

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

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

Для изменения потребуется подать запрос в 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 специалисты работают прямо в карточке своей задачи: оставляют комментарии, формируют отчеты. Эта информация доступна другим участникам, поэтому взаимодействие происходит в одном контексте, а весь процесс прозрачен для ответственного за изменение. Также все этапы работы отображаются на диаграмме Ганта.

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

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

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

Главное

1. Управление изменениями в ИТ-инфраструктуре напрямую влияет на устойчивость бизнеса. Без выстроенного процесса компания действует реактивно — устраняет последствия сбоев вместо того, чтобы предотвращать их. Экстренные изменения всегда обходятся дороже плановых: они требуют сжатых сроков, большего бюджета и создают риски для работы сервисов.
2. Основа управления — учет инфраструктуры. CMDB дает полную картину объектов и их связей с бизнес-сервисами. Ресурсно-сервисная модель показывает, какие услуги окажутся под угрозой в случае сбоя, а значит, позволяет заранее оценить критичность изменения.
3. Зонтичный мониторинг и ИИ-модели прогнозируют отказы оборудования, давая возможность перейти от реагирования к плановой работе. Service Desk становится средой, где проходят все этапы изменений, — от регистрации запроса до завершения изменения и анализа результатов.

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