Как мы мигрируем клиентов за 24 часа — не теряя ни байта

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

Почему миграция имеет плохую репутацию

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

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

Фаза 1: Исследование архитектуры (Дни –7 до –4)

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

Особое внимание уделяем «миграционному долгу» — конфигурационным решениям, которые вызовут проблемы при переключении: жёстко заданные IP-адреса в конфигурациях приложений, SSL-сертификаты, привязанные к конкретным хостнеймам, состояние сессий, хранящееся локально на серверах приложений, и cron-задачи с предположением о конкретных путях файловой системы.

Фаза 2: Репетиция (Дни –3 до –1)

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

Мы также предварительно прогреваем среду Hyper App: кеши наполняются, применяются настройки на уровне ОС, и мы подтверждаем, что производительность под нагрузкой соответствует бенчмаркам.

Фаза 3: Окно переключения (24 часа)

Само переключение планируется на период наименьшего трафика — обычно с 2 до 6 утра по ташкентскому времени. Мы выполняем runbook пошагово, с временными ограничениями на каждый шаг. Если какой-либо шаг занимает дольше отведённого времени — делаем паузу и оцениваем. Если не можем быстро решить — откатываемся.

1. Включить режим обслуживания на приложении (или плавно завершить соединения).
2. Подтвердить, что отставание реплики БД равно нулю — при необходимости подождать.
3. Повысить реплику до primary на Hyper App. Остановить репликацию с источника.
4. Обновить конфигурацию приложения для указания на новые конечные точки вычислений и БД.
5. Уменьшить DNS TTL до 60 секунд (выполнено заранее за 48 часов). Обновить DNS-записи.
6. Отключить режим обслуживания. Запустить полный набор дымовых тестов. Все проверки зелёные → продолжить.
7. Отслеживать частоту ошибок, задержку и количество соединений БД в течение 4 часов.
8. Миграция завершена. Исходная инфраструктура сохраняется в остановленном состоянии 7 дней как вариант отката.

«Я был готов к стрессовой ночи. Вместо этого наблюдал, как runbook выполняется шаг за шагом. К 4 утра всё было зелёным, и я вернулся спать. Лучшая миграция, в которой я участвовал.»
— Руководитель инфраструктуры, региональная e-commerce-платформа

Когда мы откатываемся — и почему это не провал

Мы держим исходную инфраструктуру работающей и доступной в течение первых семи дней после миграции. Если что-то неожиданное всплывает — редко используемая интеграция, граничный случай в приложении — откат занимает менее 30 минут: обновить DNS, повторно повысить исходную БД, готово.

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