Почему это сложнее, чем кажется

Многие команды недооценивают масштаб работы. На бумаге все выглядит просто: скачал образ, загрузил в новое облако, переключил DNS. На практике выясняется, что часть сервисов завязана на проприетарные AWS-решения (Lambda, SQS, DynamoDB), которых нет в российских облаках в том же виде. Или что база данных весит 4 ТБ и ее физически невозможно перелить за ночь.

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

Шаг 1. Инвентаризация – знай, что переносишь

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

Что нужно зафиксировать по каждому сервису:

  • Тип ресурса (VM, контейнер, managed-сервис, функция)
  • Зависимости – что к нему обращается и что использует он сам
  • Объем данных и скорость их прироста
  • Допустимое время простоя (RTO) и допустимая потеря данных (RPO)
  • Критичность для бизнеса (критичная, важная, вспомогательная)

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

Шаг 2. Выбор целевого провайдера

Уточните у провайдера, есть ли у него аналог тех managed-сервисов, которые вы используете. Если вы активно использовали AWS RDS, убедитесь, что новый провайдер поддерживает вашу СУБД в managed-режиме. Самостоятельно поднять PostgreSQL на VM вы сможете, но это дополнительная операционная нагрузка.

⚠️ Важно: Проверьте не только наличие сервиса, но и ограничения – версии СУБД, лимиты по объему, особенности резервного копирования и SLA. Разница в деталях часто оказывается критичной.

Шаг 3. Пилот на одном сервисе

Выберите один некритичный сервис и перенесите его полностью. Цель – не ускорить миграцию, а понять, с какими проблемами вы столкнетесь. Сетевые настройки, особенности IAM нового провайдера, отличия в поведении managed-баз лучше выяснить на тестовом кейсе.

На пилоте обязательно измерьте реальную скорость передачи данных между старым и новым облаком. Это определит, сколько времени займет перенос остальных сервисов. 100 Мбит/с кажется много, но 1 ТБ при такой скорости – это более 22 часов непрерывной передачи.

Шаг 4. Стратегия переноса данных

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

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

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

Шаг 5. Переключение и проверка

День переключения не означает момент миграции данных. К этому времени данные уже должны находиться на новой площадке. День X – это переключение трафика. Алгоритм выглядит так:

  • Снизить TTL DNS до минимума (60–300 секунд) за несколько дней до переключения
  • Перевести систему в read-only или режим обслуживания
  • Дождаться полной досинхронизации данных
  • Переключить DNS на новый IP
  • Проверить все критичные сценарии по чек-листу
  • Держать старую инфраструктуру еще 2–4 недели как резерв

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

Реальные шишки, которые другие команды уже набили на практике.

Слишком большая вера в интернет. Пропускная способность канала между разными регионами вещь капризная. Данные могут переноситься часами там, где вы рассчитывали на минуты, и весь график переезда сместится.

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

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

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