Миграция в IaaS: пошаговый план переноса инфраструктуры

Безопасная миграция в IaaS выполняется волнами: инвентаризация, целевая архитектура, подготовка landing zone, пилот, репетиция, перенос и стабилизация. Самая рискованная стратегия — перенести виртуальные машины «как есть» без карты зависимостей, критериев приёмки и проверенного отката.

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

Сначала подтвердите цель миграции

Сформулируйте измеримую причину перехода:

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

Фраза «перейти в облако» не задаёт архитектурного решения. Перед проектом полезно проверить выбор модели по сравнению IaaS и собственного дата-центра.

NIST SP 800-145 определяет IaaS как модель, в которой потребитель получает вычисления, хранилище, сети и другие базовые ресурсы, а управляет ОС, приложениями и частью сетевых компонентов. Именно эта граница должна быть отражена в матрице ответственности.

Этап 1. Инвентаризация и зависимости

Для каждого workload соберите:

• владелец и бизнес-критичность;
• серверы, ОС, версии и лицензии;
• CPU, RAM, диск, IOPS и сетевой профиль;
• базы, файловые ресурсы, очереди и внешние API;
• правила firewall, DNS, сертификаты и учётные записи;
• окна обслуживания, RPO и RTO;
• требования к размещению и защите данных;
• текущая стоимость и сезонность.

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

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

Этап 2. Выбор стратегии для workload

Не каждое приложение нужно переносить одинаково:

Стратегия	Суть	Когда подходит
Rehost	Перенос без существенного изменения	Быстрый выход при совместимой архитектуре
Replatform	Ограниченная адаптация платформы	Можно снять часть операционной нагрузки
Refactor	Изменение архитектуры приложения	Есть сильная бизнес-причина и время
Retain	Временно оставить на месте	Зависимости или требования не готовы
Retire	Вывести из эксплуатации	Система больше не создаёт ценности

Массовый rehost переносит в IaaS технический долг и старые ограничения. Массовый refactor, напротив, объединяет два рискованных проекта. Фиксируйте решение отдельно по каждому workload.

Этап 3. Landing zone до первой VM

Подготовьте базовый контур:

• структура проектов, сетей и сегментов;
• маршрутизация, VPN или выделенный канал;
• identity federation, MFA и роли;
• управление ключами и секретами;
• эталонные образы и hardening;
• централизованные логи, метрики и события аудита;
• резервное копирование и политика хранения;
• теги владельца, среды, сервиса и центра затрат;
• квоты и защитные лимиты.

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

Этап 4. Пилот и репетиция

Пилот должен проверить не только запуск:

1. развёртывание через повторяемую автоматизацию;
2. сетевую связность и DNS;
3. доступ пользователей и сервисных учётных записей;
4. производительность на типичном и пиковом профиле;
5. backup и тестовое восстановление;
6. обновление, мониторинг и реагирование;
7. расчёт расходов по реальному потреблению;
8. откат в исходный контур.

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

Этап 5. Перенос данных

Выбор метода зависит от размера, темпа изменений и RPO:

• backup/restore — проще, но требует окна;
• репликация — уменьшает простой, но усложняет согласованность;
• экспорт/импорт — удобен для отдельных наборов;
• синхронизация файлов — требует контроля удаления и прав;
• application-level dual write — самый сложный вариант и нуждается в строгой сверке.

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

Этап 6. Cutover и откат

Для окна переключения подготовьте:

• freeze изменений и список разрешённых исключений;
• ответственного за решение go/no-go;
• точный таймлайн и каналы связи;
• снижение TTL DNS заранее, если используется DNS-переключение;
• smoke-тесты и сквозные бизнес-проверки;
• критерии отката и последний безопасный момент;
• план обработки очередей после запуска.

Откат — не фраза «вернём DNS». После записи данных в новом контуре нужно знать, как вернуть изменения или остановить их до принятия окончательного решения.

Этап 7. Стабилизация

После переключения оставьте период усиленного наблюдения. Сравнивайте задержку, ошибки, потребление ресурсов и стоимость с baseline. Затем:

• удалите временные права и правила сети;
• обновите CMDB, схемы, runbook и DR-план;
• подтвердите backup и восстановление;
• настройте бюджеты и алерты расходов;
• зарезервируйте постоянную нагрузку только после измерений;
• согласованно выведите старые ресурсы.

Не удаляйте исходный контур до завершения периода отката и формальной приёмки.

Критерии приёмки

• Все критичные бизнес-сценарии выполняются.
• Данные сверены по согласованному методу.
• Показатели производительности не хуже допустимого порога.
• Логи, метрики, трассировки и алерты работают.
• RPO/RTO подтверждены тестом.
• Доступы соответствуют матрице ролей.
• Стоимость видна по сервису и владельцу.
• Runbook и план аварийного восстановления обновлены.
• Откат либо завершён, либо официально закрыт.

Типичные ошибки

• Перенос неизвестных зависимостей.
• Публичные адреса вместо спроектированной сети.
• Копирование старых привилегий без пересмотра.
• Оценка стоимости только по CPU и RAM.
• Первый тест backup проводится после cutover.
• DNS считается мгновенным переключателем.
• Старый контур отключается до сверки данных.
• Успешный health check принимается за бизнес-приёмку.

CTA: «Лоджик Телеком» может помочь провести инвентаризацию, спроектировать целевой контур и план волн миграции. Начните с пилота, в котором проверяются производительность, восстановление и откат — три результата важнее самого факта запуска VM.