Миграция в облако редко ломается на этапе копирования данных. Она ломается на деталях, о которых не подумали заранее: на задании в cron, которое осталось на старом сервере, на DNS-записи с TTL в сутки, на внешнем сервисе, у которого в белом списке только старый IP-адрес. Эта статья — план, по которому мы проходим переезды, с акцентом на то, что проверять до переключения и что делать, если оно не прошло.
Инвентаризация: что на самом деле переезжает
Первый шаг — не выбор облака, а список. Полный список того, что работает сейчас, включая то, о чём все забыли.
- Сервисы и приложения. Не только основное приложение, но и воркеры, планировщики, боты, внутренние панели, старые версии API, которые кто-то ещё использует.
- Данные. Базы, файлы пользователей, кэши, очереди. Для каждой — объём, скорость изменения и допустимое время недоступности.
- Зависимости. Внешние API, платёжные системы, почтовые сервисы, SMS-шлюзы. Особенно те, где ваш адрес прописан в белом списке или в настройках обратных вызовов.
- Задания по расписанию. Cron на серверах, задачи в планировщиках, скрипты резервного копирования. Это самое частое, что остаётся работать на старой площадке после переезда.
- Сертификаты, домены, DNS. Где управляются, кто имеет доступ, когда истекают.
- Секреты и конфигурация. Переменные окружения, ключи, файлы настроек, которые лежат на сервере и нигде больше.
Самый надёжный способ собрать список — пройтись по работающим процессам, открытым портам и заданиям на каждом сервере, а не по документации. Документация описывает то, что планировалось.
Выбор площадки
Выбор облака — это выбор ограничений, с которыми вы будете жить несколько лет. Критерии, которые имеют значение на практике:
- Требования к размещению данных. Если вы обрабатываете персональные данные граждан РФ, первичная запись должна происходить на территории страны. Это сужает список до российских площадок: Yandex Cloud, Selectel, VK Cloud, Timeweb Cloud и других.
- Нужные управляемые сервисы. Управляемая база данных, объектное хранилище, Kubernetes, балансировщик. Чем больше вы берёте как сервис, тем меньше сопровождаете сами, но тем сложнее уйти.
- Сетевая связность. Задержки до ваших пользователей и до внешних систем, возможность приватной сети, стоимость исходящего трафика.
- Стоимость при реальной нагрузке. Считайте не по прайсу, а по вашему профилю: объём данных, трафик, число запросов к хранилищу. Разница между площадками часто в деталях вроде платы за операции с объектами.
- Поддержка и ответственность. Что провайдер гарантирует, как быстро отвечает, что происходит при инциденте на его стороне.
Не выбирайте площадку по презентации. Разверните на ней тестовый стенд и прогоните типовую нагрузку, прежде чем подписывать договор.
Тестовый перенос
Перед боевым переключением нужен полный прогон на копии. Не частичный, не «проверим основное», а полный.
- Разверните инфраструктуру на новой площадке из описания в коде: Terraform, Ansible, манифесты Kubernetes, что используете. Если описания нет, миграция — хороший момент его создать, иначе новая площадка будет такой же невоспроизводимой, как старая.
- Перенесите копию данных по тому же механизму, который планируете использовать в боевом переключении. Засеките время: это ваше окно недоступности.
- Запустите приложение на новой площадке на тестовом домене и пройдите ключевые сценарии руками и автотестами. Вход, оплата, загрузка файла, отправка письма, выполнение фонового задания.
- Сравните данные. Число строк в таблицах, контрольные суммы файлов, последние записи по времени. «Перенеслось без ошибок» и «перенеслось всё» — разные утверждения.
- Проверьте интеграции с тестовых адресов. Внешний сервис, который отвергает запросы с нового IP, лучше обнаружить сейчас.
- Запишите все команды и порядок действий. Это сценарий боевого переключения.
Окно переключения
Нулевой простой возможен не всегда, и обещать его заранее нельзя. Он зависит от архитектуры, объёма данных и способа их синхронизации. Честный подход — определить допустимое окно вместе с бизнесом и уложиться в него.
Чтобы окно было коротким, данные переносят в два этапа: основной объём заранее, а в момент переключения — только изменения с момента последней синхронизации. Для баз это репликация или инкрементальный перенос, для файлов — повторная синхронизация, которая переносит только новое.
Порядок в окне обычно такой:
- Перевести старую площадку в режим только для чтения или остановить запись. Пользователи видят предупреждение, а не ошибку.
- Выполнить финальную синхронизацию данных и проверить её результат.
- Переключить трафик на новую площадку.
- Прогнать проверочный сценарий на боевом домене.
- Включить запись и снять предупреждение.
Старую площадку не выключайте. Она остаётся в режиме только для чтения до тех пор, пока не пройдёт срок наблюдения, о котором ниже.
DNS и TTL
DNS — то, что чаще всего портит аккуратный план. Запись с TTL в 24 часа означает, что часть пользователей будет приходить на старый адрес ещё сутки после переключения, и если старая площадка продолжает принимать запись, вы получите расхождение данных на двух площадках.
- Снизьте TTL до минут за несколько дней до переключения, чтобы старое значение успело истечь во всех кэшах.
- Убедитесь, что доступ к управлению DNS есть у того, кто будет переключать, и он проверен заранее.
- Если возможно, переключайте трафик не через DNS, а через балансировщик или прокси, который уже смотрит на обе площадки. Тогда переключение мгновенное и обратимое.
- Старая площадка после переключения должна либо перенаправлять на новую, либо работать только на чтение. Принимать запись она не должна.
План возврата
План отката пишут до переключения, а не во время инцидента. Он отвечает на три вопроса: по каким признакам мы решаем откатиться, кто принимает это решение и какие именно действия выполняются.
- Критерии. Например: доля ошибок выше порога, ключевой сценарий не работает, интеграция с платёжной системой не отвечает, и это не исправляется за заранее оговорённое время.
- Ответственный. Один человек, который говорит «откатываемся». Решение комитетом в момент инцидента не принимается.
- Действия. Вернуть DNS или балансировщик на старую площадку, снять с неё режим только для чтения, перенести обратно данные, записанные на новой площадке за время работы. Последний пункт самый сложный, и именно он определяет, сколько времени можно оставаться на новой площадке с правом отката.
Если возврат данных с новой площадки на старую невозможен, об этом нужно знать заранее: тогда точка невозврата наступает в момент включения записи, и критерии отката должны проверяться до неё.
Что проверить после переезда
Первые дни после переключения — период наблюдения. Старая площадка ещё жива, план отката ещё действует.
- Мониторинг и алерты настроены на новую площадку и действительно срабатывают. Проверьте это, а не предполагайте.
- Резервное копирование работает с новой площадки и копии восстанавливаются. Задание, оставшееся на старом сервере, копирует старые данные.
- Задания по расписанию выполняются на новой площадке и не выполняются на старой. Двойная отправка писем или двойное списание — типичное последствие.
- Сертификаты обновляются автоматически на новой площадке.
- Расходы соответствуют расчёту. Первый счёт покажет, что вы забыли учесть.
- Старую площадку отключайте по плану, с финальной копией данных и после того, как все проверки прошли.
Подробнее о том, как мы организуем перенос, на странице миграции серверов и сервисов в облако, а о настройке наблюдения после переезда — на странице мониторинга и восстановления.
Что дальше
Если переезд уже планируется и нужен взгляд со стороны на текущую инфраструктуру и список рисков перед ним, начните с бесплатного экспресс-аудита за 48 часов.