Корпоративная ИТ-инфраструктура: чек-лист аудита перед миграцией в облако

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

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

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

1. Инвентаризация: найти реальные рабочие нагрузки

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

1. Назначение и владелец. Какой процесс поддерживает сервер или приложение, кто отвечает за его работоспособность, есть ли у владельца регламент восстановления.

2. Тип нагрузки. Продуктивная, тестовая, демонстрационная, аналитическая, пакетная или архивная. У каждого типа свой режим нагрузки и собственные требования к отказоустойчивости.

3. Потребление ресурсов. Утилизация CPU и RAM, дисковая нагрузка, объём хранилища, сетевой трафик, количество пользователей и характер обращений.

4. Зависимости. Какие базы данных, файловые ресурсы, API, очереди, DNS, сертификаты, системы идентификации и мониторинга использует приложение.

5. Лицензии и договоры. Срок действия, модель лицензирования, ограничения по размещению, стоимость продления и возможность передачи прав при смене платформы.

6. Критичность. Какие бизнес-процессы остановятся при сбое, насколько допустим простой, существуют ли резервные сценарии работы вручную.

В предаудитете используются два характерных сигнала для обнаружения неиспользуемой инфраструктуры. Первый — средняя утилизация CPU и RAM ниже 5% в течение 90 дней. Второй — отсутствие входящих сетевых соединений более 90 дней. В обоих случаях сервер попадает в кандидаты на отключение, но решение принимается после проверки его назначения.

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

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

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

2. Карта зависимостей и целевые метрики RPO/RTO

Виртуальная машина редко работает в одиночку. ERP взаимодействует с CRM, электронным документооборотом, почтой, корпоративным каталогом и аналитическими хранилищами. Общие сервисы — DNS, управление доступом, выпуск сертификатов, журналирование, резервное копирование и мониторинг — связывают приложения в единую систему. Если эти связи не отражены на схеме, команда может перенести отдельные компоненты формально успешно, а затем получить сбой в середине рабочего процесса.

Для каждой связи следует зафиксировать:

• тип взаимодействия: синхронный API, пакетный обмен, общая база, файловая передача;
• владельца сервиса с каждой стороны;
• требования к задержке, пропускной способности и доступности;
• порядок обработки ошибок и повторных запросов;
• окно пакетной загрузки и его связь с клиентским трафиком;
• влияние изменения на другие процессы.

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

Эти показатели должны рождаться из бизнес-процесса, а не выбираться как технические значения «по умолчанию». Связь выглядит так:

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

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

3. Юридический аудит: данные, лицензии и ограничения регулятора

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

Локализация персональных данных

152-ФЗ требует локализации баз данных с персональными данными граждан РФ на территории страны. Аудит должен охватывать не только основную базу, но и резервные копии, журналы, файловые хранилища, аналитические витрины и данные, которые передаются подрядчикам или в системы поддержки.

Для каждого информационного потока фиксируются:

• категория данных и субъект персональных данных;
• место физического размещения основной и резервной копий;
• получатели данных, включая подрядчиков;
• маршруты доступа для администраторов и вендоров;
• сроки хранения и порядок удаления;
• договорные и технические меры защиты.

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

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

Ограничения для значимых объектов КИИ

Для значимых объектов критической информационной инфраструктуры с 1 января 2025 года действует запрет на применение иностранного программного обеспечения. Поэтому часть систем должна оставаться в текущем контуре, что соответствует стратегии Retain в модели 6R, либо переходить на сертифицированное решение.

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

Лицензии и права на перенос

Иностранные проприетарные лицензии нельзя считать переносимыми в российский облачный контур без проверки соглашения. Нужно сопоставить:

• территорию использования;
• допустимость размещения у стороннего провайдера;
• лимиты пользователей, устройств и экземпляров;
• условия технической поддержки;
• срок действия и порядок продления;
• платформенные ограничения конкретной версии продукта.

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

4. Проверка баз данных и подготовка к репликации

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

Для каждой базы уточняются:

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

2. Роль нагрузки. Транзакционная система, аналитическое хранилище, архив, справочник или интеграционная шина.

3. Поток транзакций. Средняя и пиковая нагрузка, объём операций записи, работа пакетных заданий, наличие крупных транзакций.

4. Репликация и согласованность. Допустимая задержка, поведение конфликтов, работа последовательностей, DDL и перенос объектов, специфичных для СУБД.

5. Резервное копирование. Регулярность копий, срок хранения, возможность полного восстановления и проверка целостности после переноса.

6. Сетевой путь. Пропускная способность, задержка, доступность облачной зоны и устойчивость соединения.

7. Откат. Возможность прекратить репликацию, восстановить согласованное состояние и перенаправить приложения без потери подтверждённых операций.

Отдельный технический риск возникает при репликации PostgreSQL. Для логической репликации требуется запас дискового пространства под журналы упреждающей записи WAL: не менее 30% от текущего объёма базы данных на источнике. Если эти 30% не заложены, процесс может упереться в нехватку места уже во время репликации, когда остановить и перезапустить передачу данных наиболее затратно.

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

5. Стратегии 6R, волны внедрения и расчёт эффекта

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

Глубокую переработку архитектуры, то есть Refactor, разумно переносить на вторую волну. На старте команды обычно выбирают Rehost или Replatform для сервисов, которые можно перенести с меньшим количеством изменений. Это позволяет быстрее получить управляемый результат и высвободить ресурсы, а сложные переработки проводить уже на основе данных о реальной эксплуатации.

Как связать стратегии с волнами

1. Подготовительная волна. Завершить инвентаризацию, удалить подтверждённо ненужные компоненты, согласовать RPO/RTO, проверить юридические ограничения и подготовить тестовые стенды.

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

3. Вторая волна. Провести Refactor там, где текущая архитектура ограничивает масштабирование, стоимость эксплуатации или скорость выпуска изменений.

4. Завершающая волна. Отключить старую инфраструктуру, освободить лицензии и помещения, передать поддержку в обновлённый процесс эксплуатации.

Repurchase и Retire обычно образуют отдельные потоки работы. Переход на SaaS требует управления не только инфраструктурой, но и продуктом, обучением команды и изменением процесса. Выключение ненужных систем должно завершаться юридически корректным прекращением договоров и проверкой отсутствия зависимостей.

Для каждой волны нужен отдельный план отката. В него входят критерии запуска отката, ответственный руководитель, состояние баз данных, порядок переключения DNS или балансировщика, возврат конфигураций, проверка бизнес-процессов и сообщение команде. Резервный вариант без назначенного ответственного и критерия переключения остаётся лишь запасной записью в презентации.

Как считать эффект от миграции

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

Облако не гарантирует снижение совокуанной стоимости владения. При Rehost «как есть» компания может арендовать мощности вместе с неиспользуемыми ресурсами и платить больше, чем за собственную инфраструктуру. Поэтому в расчёт включаются освобождение серверов, лицензий и площадки, но также двойной период эксплуатации во время миграции, стоимость отката и возможные простои.

Отдельно оценивается time-to-market. Если цель — быстрее выпускать новые продукты и обрабатывать клиентские обращения, сложность миграции становится бизнес-метрикой. В одном проекте простая стратегия для периферийных сервисов вполне может соседствовать с глубокой переработкой ядра, если у команды достаточно времени, компетенций и отдельного бизнес-обоснования.

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

Решение о миграции принимается не по числу виртуальных машин, а по готовности процессов: каждая критичная система имеет владельца, понятные RPO/RTO, проверенную зависимость, законный сценарий размещения и рабочий план отката. Такой аудит помогает двигаться к облаку управляемыми волнами, сохраняя управляемость бизнеса и давая команде понятный порядок действий на каждом этапе.