Миграция на сервер больше без простоя: чек-лист

Перенос приложения на сервер большего размера без простоя — это не копирование диска и не смена IP в DNS. Для стека на Ubuntu 24.04 LTS и Nginx 1.24+ безопасный сценарий выглядит иначе: новый сервер поднимают параллельно старому, проверяют на реальном трафике без пользователей, затем переключают запросы через балансировщик или прокси. В этой статье — чек-лист перед продакшеном для приложения, у которого база данных остаётся на отдельном сервере или управляемом сервисе.

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

«Сервер стал больше» может означать разные операции. Если вы меняете только виртуальную машину приложения, база данных, Redis, объектное хранилище и DNS остаются прежними. Это самый предсказуемый вариант. Если одновременно переносится PostgreSQL, меняется схема базы или переезжают файлы пользователей, проект уже нельзя считать простой заменой app-сервера.

Зафиксируйте это письменно до начала работ:

• что переносится: приложение, веб-сервер, фоновые воркеры, cron-задачи;
• что остаётся на месте: база данных, очереди, хранилище файлов, домен;
• какой компонент переключает трафик: балансировщик, reverse proxy или DNS;
• какой показатель означает успех: например, отсутствие ответов 5xx и ошибок авторизации в течение согласованного окна наблюдения;
• кто принимает решение об откате и сколько времени команда готова наблюдать новую машину.

Три способа сменить сервер

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

Для продакшена обычно безопаснее схема blue-green deployment^*: старый сервер остаётся рабочим, новый запускается рядом, а маршрутизатор переводит на него запросы после проверки.

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

* Blue-green deployment — схема с двумя окружениями: blue — текущая версия, green — новая. В каждый момент времени пользовательский трафик направлен в одно из них, но второе остаётся доступным для проверки или отката.

Чек-лист перед созданием нового сервера

1. Зафиксируйте воспроизводимую конфигурацию

Новый сервер нельзя настраивать только по памяти системного администратора. Запишите версию ОС, Nginx, runtime, менеджера процессов, системные пакеты, переменные окружения и правила firewall. Если приложение собирается из репозитория, укажите точный commit или тег, а не ветку main.

Проверьте отдельно:

• версию PHP, Python, Node.js или другого runtime;
• расширения и системные библиотеки, от которых зависит сборка;
• часовой пояс и синхронизацию времени;
• лимиты открытых файлов, размер временного каталога и доступное место;
• права пользователя, под которым запускается приложение;
• сертификаты, ключи SSH и доступ к секрет-хранилищу.

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

2. Проверьте сетевой контур

Убедитесь, что новый сервер видит базу данных, очередь, SMTP, объектное хранилище и внешние API. Важна не только исходящая связь: проверьте, разрешены ли входящие соединения от балансировщика, health check и служебных систем мониторинга.

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

3. Подготовьте самопроверку приложения

Health check должен отвечать на вопрос «процесс принимает трафик», а не выполнять тяжёлый бизнес-запрос. Отдельная проверка готовности должна подтверждать доступ к критичным зависимостям: базе, очереди и хранилищу. Если приложение возвращает 200, но не может записать заказ, такой health check вводит балансировщик в заблуждение.

Перед переключением проверьте на новом сервере:

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

Каждый пункт должен иметь наблюдаемый результат: HTTP-код, запись в журнале, созданную тестовую сущность или задачу в очереди. Одного ответа «страница открылась» недостаточно.

Данные, сессии и фоновые задачи

Файлы и загрузки

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

Сессии

Локальные сессии в файлах или памяти ломают вход при переключении между серверами. Надёжнее хранить их в общей Redis-инфраструктуре или базе, если это поддерживает ваш стек. Sticky sessions^** могут временно скрыть проблему, но не решают её: после сбоя старого сервера пользователь всё равно потеряет сессию.

** Sticky sessions — привязка пользователя к одному экземпляру приложения на уровне балансировщика. Она уменьшает вероятность перехода между серверами, но создаёт неравномерную нагрузку и усложняет отказоустойчивость.

База и миграции схемы

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

Схема, которая сначала удаляет колонку, а потом выкатывает новый код, опасна: старый сервер ещё обслуживает запросы и может обратиться к уже удалённому объекту.

План переключения и отката

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

1. Снизьте нагрузку на старую машину и убедитесь, что резервное копирование базы завершилось успешно.
2. Установите приложение на новый сервер из зафиксированной версии.
3. Подключите новый экземпляр к зависимостям, но не направляйте на него пользовательский трафик.
4. Выполните smoke-тесты: авторизация, чтение, запись, файл, очередь, внешняя интеграция.
5. Добавьте новый сервер в балансировщик с нулевым или малым весом и проверьте health check.
6. Переводите трафик постепенно, если это умеет ваш балансировщик. Смотрите на 4xx, 5xx, задержку, загрузку CPU, память, соединения с базой и длину очередей.
7. После переключения не выключайте старую машину сразу. Оставьте её готовой к возврату трафика на согласованный срок.

Критерии отката задайте заранее. Например: рост 5xx относительно базового уровня, ошибки подключения к базе, потеря загрузок или увеличение p95-задержки выше принятого порога. Сам порог нельзя выдумать универсальным числом: возьмите его из обычных показателей именно вашего сервиса за сопоставимый период.

Что чаще всего ломается

• 502 Bad Gateway. Nginx не достучался до приложения. Проверьте порт, systemd-сервис, bind-адрес и журнал приложения.
• 502 или таймаут при обращении к базе. Новый IP не добавили в правила доступа либо неверно перенесли параметры подключения.
• Пользователь вышел из аккаунта. Сессии хранятся локально или на серверах используются разные секреты подписи cookie.
• Сайт открывается, но изображения пропали. Файлы были на локальном диске старой машины, а общий storage не подключён.
• Задачи выполняются дважды. Воркеры запустили на обоих серверах без блокировки, разделения очередей или идемпотентной обработки.
• Запросы идут на старый сервер. Это может быть кеш DNS, старое правило балансировщика или постоянные соединения, которые ещё не drained.

Что сделать после миграции

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

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