Тестовый (staging) сервер перед обновлением прода

MAATRIX GAMES

Обновил плагин на проде в пятницу вечером — а через полчаса сервер лежит, у половины игроков крашится клиент, и ты откатываешь бекап под вопли в дискорде. Знакомо? Единственный рабочий способ этого избежать — тестировать изменения не на живом сервере, а на отдельной копии, которая ведёт себя так же, но её падение никто, кроме тебя, не заметит.

Зачем staging, если и так есть бекапы

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

Схема простая: у тебя два инстанса. Боевой — на него заходят игроки, он должен работать стабильно. Тестовый — копия боевой конфигурации без реальных игроков, на которой гоняешь новую версию мода, обновление ядра сервера (Paper/Forge/Fabric сборку) или новый плагин, смотришь логи и только после этого переносишь изменения на прод.

Отдельный слот на хостинге для staging — не роскошь, а страховка. Для большинства модов и плагинов хватает минимального тарифа: тестируется совместимость и логика запуска, а не нагрузка сотен игроков. Дешевле держать второй сервер младшей конфигурации, чем один раз положить прод на праздниках, когда обновление накатывали "и так сойдёт". Исключение — если тестируешь именно поведение под нагрузкой (TPS, лаги от нового мода со сложной логикой): тогда железо staging должно быть близко к проду, иначе тест не покажет реальную картину.

Что копировать: конфиги и плагины, а не весь мир

Главная ошибка новичков — тащить на staging весь мир целиком. Это долго (мир на активном Rust или ARK-сервере может весить десятки гигабайт), не нужно для большинства тестов и создаёт риск спутать, на каком инстансе ты сейчас находишься.

Что реально нужно копировать:

• Конфигурационные файлы — server.properties, bukkit.yml, spigot.yml, paper-world-defaults.yml для Minecraft; server.cfg, oxide/config/*.json для Rust; serverautoexec.cfg для CS2. Подробно о работе с этими файлами — в статье работа с конфигурационными файлами игрового сервера.
• Папку плагинов/модов целиком — plugins/ или mods/, включая их конфиги в подпапках.
• Права и группы — файлы permissions-плагина (например, базу LuckPerms), чтобы на staging были те же роли, что на проде.
• Whitelist/ops/banned-ip, если тестируешь именно права доступа.

Что копировать почти никогда не нужно:

• Полный мир игроков (region-файлы, save-файлы карты) — вместо этого генерируй новый тестовый мир с тем же seed или бери небольшой кусок карты.
• Базу игроков с личными данными, если тест не касается конкретно данных.

Исключение — если тест именно про совместимость мода с существующим миром (новый мод генерации ландшафта в Minecraft может ломаться на старых чанках). Тогда нужен слепок реального мира, но это отдельный тип теста, не рутинная проверка обновлений.

Разворачиваем staging пошагово

Возьмём Minecraft на Paper как основной пример — логика переносится на любой другой движок с поправкой на пути к файлам.

1. Создай второй сервер — младший тариф с тем же движком (Paper/Forge/Fabric той же мажорной версии, что и на проде).
2. Скопируй конфиги и плагины по SFTP/rsync, не трогая папку world:

rsync -avz --exclude='world*' --exclude='logs' \
  user@prod-host:/home/minecraft/server/ \
  user@staging-host:/home/minecraft/server/

1. Сгенерируй новый тестовый мир — запусти сервер с пустой world/, он создаст новый по текущему level-seed из server.properties. Окружение получается похожим на прод, но данные игроков не трогаются.
2. Поменяй порт и MOTD, чтобы не спутать staging с продом визуально — впиши в server-port и motd что-то вроде [STAGING] Не для игроков.
3. Зайди сам (или с 1-2 тестерами) и проверь, что базовый функционал жив: чат, крафт, команды, RCON.
4. Только теперь накатывай то изменение, ради которого всё затевалось.

Для Rust, ARK, 7 Days to Die логика та же: копируешь конфиги (server.cfg, GameUserSettings.ini, Game.ini), генерируешь тестовую карту с тем же seed через SteamCMD (см. установка и обновление игровых серверов через SteamCMD), запускаешь на отдельном порту.

Синхронизация конфигов между staging и продом

Тут легко запутаться, в какую сторону идёт синхронизация. Разделяй два направления жёстко.

Прод → staging (перед тестом) — забираешь актуальные конфиги и список плагинов с боевого сервера, чтобы тестировать на близкой к реальности базе. Делай это перед каждым циклом тестирования, а не одноразово при создании staging — конфиги на проде могли поменяться руками через RCON или консоль хостинга с прошлого раза.

Staging → прод (после успешного теста) — переносишь только то, что реально менялось: файл мода/плагина, изменённый конфиг. Не перезаписывай весь прод содержимым staging целиком — так легко случайно откатить чужое изменение, которое кто-то другой из команды внёс на проде за это время.

Если к проду есть доступ у нескольких человек, заведите правило: изменения конфигов вносятся только через git-репозиторий или через staging, а не руками в консоли хостинга — иначе синхронизация быстро превращается в гадание, что где актуальное.

Чек-лист перед выкладкой на прод

Прежде чем переносить протестированное со staging на боевой сервер, пройди по списку:

• Сервер на staging работает минимум 15-20 минут без крашей и без спама ошибок в консоли.
• Проверены логи на предмет WARN/ERROR от новых модов/плагинов — не только факт запуска, но и чистота логов.
• Основные команды и функции, завязанные на изменённый мод/плагин, протестированы вручную.
• Проверена совместимость с другими установленными плагинами — конфликты по id команд, событиям, слотам меню случаются чаще, чем кажется.
• Есть свежий бекап прода, сделанный непосредственно перед обновлением (см. автобекапы игрового сервера: настройка расписания) — staging не отменяет бекап, а дополняет его.
• Известен план отката, если после выкладки что-то пойдёт не так — та же процедура, что и в статье про обновление сервера без потери прогресса игроков.
• Игроки предупреждены о плановом техническом окне, если обновление требует рестарта в прайм-тайм.

Для проектов с несколькими серверами в сети (прокси Velocity/BungeeCord) — протестируй изменение и на staging-версии прокси-конфига, а не только на бэкенд-сервере, если оно затрагивает маршрутизацию или лимиты.

Автоматизация синхронизации через rsync

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

Пример скрипта синхронизации конфигов и плагинов прод → staging (запускать перед тестом):

#!/bin/bash
# sync-to-staging.sh
PROD_HOST="user@prod-host"
PROD_PATH="/home/minecraft/server"
STAGING_PATH="/home/minecraft/staging"

rsync -avz --delete \
  --exclude='world*' --exclude='logs' --exclude='cache' \
  "$PROD_HOST:$PROD_PATH/plugins/" "$STAGING_PATH/plugins/"

rsync -avz \
  "$PROD_HOST:$PROD_PATH/server.properties" "$STAGING_PATH/"

echo "Синхронизация завершена: $(date)"

Флаг --delete в первой команде важен — иначе на staging будут копиться плагины, которые давно удалили с прода, и ты будешь тестировать не ту конфигурацию, что реально в бою. Для одиночного файла во второй строке --delete не нужен.

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

Частые вопросы