Российские пользователи и европейская команда: где разместить staging и production

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

Вопрос поэтому звучит не «в какой стране ставить серверы», а точнее: что именно должна доказывать каждая среда и чьими глазами мы на неё смотрим. Ниже — разбор по шагам, а в конце — один условный релиз, который проходит через обе площадки.

Чью скорость мерим: две среды — два вопроса

Production отвечает на вопрос: «Хорошо ли живётся реальному пользователю?» Здесь важны маршрут от клиента до сервера, время ответа, стабильность соединения и доступность тех сервисов, с которыми приложение разговаривает по ходу запроса. Если основная аудитория находится в России, сетевой путь от неё до сервера — первое, что стоит проверить. Не рейтингом стран, а собственным измерением: запустить тестовый сервер в рассматриваемых локациях, пройти с реальных пользовательских сетей и посмотреть задержку и потери. Публичное предложение MAATRIX перечисляет локации UK, US, RU и FR, так что сравнивать есть что, но выбор делается по вашему маршруту, а не по общим представлениям.

Staging отвечает на другой вопрос: «Поведёт ли себя этот релиз в production так, как мы ожидаем?» Скорость отклика для конечного пользователя здесь вторична. Важнее другое: чтобы среда собиралась и запускалась так же, как боевая, чтобы разработчики и тестировщики могли быстро в неё зайти и чтобы ошибки, найденные там, воспроизводились и в production, и наоборот.

Из этого следует практичный вывод. Расположить staging рядом с командой — разумно, потому что работать с ним будут люди, а не клиенты. Расположить production ближе к клиентам — разумно по той же причине. Но разница в странах сама по себе ничего не гарантирует: она создаёт дополнительное расстояние, которое нужно сознательно учесть, когда вы сравниваете результаты двух сред. Страница в staging, открывающаяся из Европы за 80 мс, ничего не говорит о том, как она откроется из России. Для проверки сетевого пути для российских клиентов нужен отдельный замер с российской стороны, а не вывод из тестов европейской среды.

Три разных «скорости» в одной системе

Удобно развести их явно, иначе в обсуждениях они смешиваются:

• Скорость для клиента — время ответа production с пользовательских сетей. Её оценивают по production или по зеркальному измерительному серверу в той же локации.
• Скорость для команды — как быстро разработчик заходит на staging по SSH, деплоит, смотрит логи. Здесь выигрывает близость к команде.
• Скорость релиза — сколько времени проходит от коммита до проверенного выпуска. Она зависит от автоматизации, а не от страны.

Staging в Европе будет быстрым для второго и третьего пунктов и ничего не скажет о первом. Это не недостаток, если все понимают, что именно проверяется.

Рабочие сведения и учебные данные

Вторая развилка — данные. Соблазн понятен: взять дамп production и развернуть в staging, чтобы всё было «как настоящее». Но это не просто технический шаг. В production лежат реальные клиенты: имена, телефоны, адреса, история заказов. Копирование таких сведений в среду, где к ним получат доступ разработчики в другой стране, — отдельное решение с юридическими и организационными последствиями. Нельзя считать, что расположение сервера в другой стране само по себе делает такую копию безопасной или, наоборот, допустимой. Размещение сервера не заменяет ни основания для обработки данных, ни ограничений на доступ, ни договорённостей с теми, кто эти данные передал.

Практичный подход — не копировать реальные персональные данные без явного основания и строить в staging учебный набор. Он может быть устроен по-разному:

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

Отдельная тема — то, что кроме базы данных тоже содержит персональные сведения: загруженные файлы, логи запросов, очереди сообщений. Логи с телефонными номерами в теле запроса — привычная находка. Здесь полезно помнить, как работает обратный прокси. В документации NGINX сказано, что директива proxy_pass_request_body по умолчанию включена и передаёт тело исходного запроса, а исходные заголовки тоже передаются по умолчанию, причём отправляемыми заголовками можно управлять через proxy_set_header. Для нашей задачи это значит: если вы направляете часть трафика или копию запросов в staging, вместе с ними по умолчанию уедут и тело запроса, и заголовки, включая то, что в них лежит. Прежде чем что-то зеркалировать, решите, какие заголовки нужно убрать или заменить, и не рассчитывайте, что прокси сам «очистит» запрос.

Что у staging и production должно совпадать

Если данные в staging учебные, а страна другая, остаётся вопрос: на что тогда можно полагаться при проверке? Ответ — на совпадение свойств, которые влияют на поведение кода. Методология Twelve-Factor App рекомендует уменьшать различия между разработкой, тестированием и production по инструментам, времени и участникам. Эту мысль удобно применить как фильтр: сначала выписать различия между средами, потом решить, какие из них безобидны, а какие способны испортить проверку.

Различия делятся на три группы.

Должно совпадать

• Состав и версии компонентов: база данных, кэш, очередь, веб-сервер, рантайм приложения. Если в staging SQLite, а в production PostgreSQL, часть ошибок вы не увидите вовсе.
• Способ сборки и запуска: один и тот же образ или артефакт, одна и та же команда старта, те же переменные окружения по составу (значения разные, набор — тот же).
• Конфигурация обратного прокси: лимиты размера тела, таймауты, заголовки. Много «странных» ошибок случается именно на стыке приложения и прокси.
• Миграции схемы: они выполняются теми же инструментами в том же порядке.

Может отличаться

• Размер сервера. Staging обычно меньше. Ресурсы тарифа — отправная точка для теста, а не обещание ёмкости, поэтому staging на одном из младших тарифов (например, Ba или Uab) вполне осмысленен для функциональных проверок, а production можно сопоставить по ресурсам с реальной нагрузкой, которую вы измерили.
• Объём данных. Для большинства проверок достаточно малого набора.
• Домены и сертификаты. Конечно, у staging свой адрес.

Различается, но опасно

Сюда попадают скрытые различия: другая версия базового образа, другой часовой пояс, другая локаль, другая версия клиентской библиотеки. Про образы стоит сказать отдельно. В документации Docker отмечено, что теги образов изменяемы, а фиксация digest закрепляет определённый образ. Следовательно, если в обеих средах указан тег вроде latest или мажорной версии, то в день, когда вы собираете staging, и в день, когда выпускаете production, под одним тегом могут лежать разные образы. Staging тогда проверяет не то, что поедет в бой.

Закрепление по digest решает эту проблему, но создаёт другую обязанность: та же документация указывает, что закреплённый образ не получает будущие исправления автоматически, и его обновление требует отдельного действия. Это не повод отказываться от фиксации, а повод завести привычку: обновление базового образа — осознанное изменение, которое сначала проходит через staging, а потом через production. Так закрепление работает на воспроизводимость, а не превращается в забытую зависимость.

Разные страны добавляют ещё один слой различий, который легко пропустить: сеть. Часовой пояс сервера, доступность внешних репозиториев пакетов, скорость скачивания образов, поведение DNS. Если staging в Европе спокойно тянет образы и пакеты из любого реестра, а production в России упирается в недоступный или медленный источник, выпуск сломается именно на боевой стороне, хотя staging его «одобрил». Лечится это тем, что артефакт собирается один раз и в готовом виде переносится в обе среды, а не собирается заново на каждой площадке.

Как команде заходить в среды и что делать с внешними интеграциями

Европейские разработчики будут работать со staging постоянно, а вот к production им нужен гораздо более узкий доступ. Это разные уровни, и страна расположения сервера эту разницу не создаёт: её создают права и процессы.

Удобный способ работать на удалённой машине — Remote SSH для VS Code. Согласно документации, он позволяет открыть папку удалённого компьютера, а команды и часть расширений выполняются на удалённой стороне через VS Code Server. Для staging это удобно: разработчик в Европе правит код, запускает тесты и смотрит логи там, где всё реально работает, не воспроизводя окружение на ноутбуке. Одна оговорка из той же документации: установка VS Code Server требует загрузки компонентов, но возможна загрузка локально с передачей на сервер. Это пригодится, если у сервера ограничен исходящий доступ: компоненты можно скачать на рабочей машине и передать на сервер вручную.

Для production такой интерактивный доступ разумнее не раздавать широко. Редактировать код прямо на боевом сервере — плохая привычка в любой стране; боевая среда должна меняться через выпуск проверенного артефакта. Доступ на чтение логов и метрик, возможность выполнить заранее оговорённую операцию — достаточно для большинства задач. Root-доступ, который MAATRIX даёт на VPS, — это возможность, а не рекомендация раздавать его всем: распределить права внутри команды предстоит вам самим.

Внешние интеграции: где ломается сходство

Платёжные шлюзы, SMS-провайдеры, службы доставки, государственные и банковские API — всё, что приложение вызывает снаружи, ведёт себя по-разному в зависимости от того, откуда пришёл запрос. Некоторые сервисы ограничивают доступ по географии или по спискам разрешённых адресов. Поэтому нельзя заранее считать, что сторонний API ответит по иностранному IP так же, как по российскому: это нужно проверить конкретно для каждой интеграции. Если staging в Европе не может дойти до нужного API, это не обязательно ошибка кода, а возможно, ограничение со стороны провайдера.

Практичные варианты, которые стоит держать в голове:

• Тестовые контуры провайдеров. Многие сервисы предлагают песочницу с тестовыми ключами; staging должен ходить именно туда, а не в боевой контур. Заведите отдельные ключи, чтобы случайный тестовый платёж не ушёл по-настоящему.
• Заглушки. Для интеграций без песочницы или с ограничением по адресу пишется эмулятор, возвращающий типовые ответы и типовые ошибки. Он проверяет логику вашего кода, но не реальную сетевую доступность.
• Отдельная проверка доступности из production-локации. То, что нельзя проверить из Европы, проверяется коротким дымовым тестом уже на боевой стороне, при выпуске.

Так честно распределяются роли: staging проверяет логику и совместимость, дымовой тест production проверяет сеть и реальные интеграции. Одна среда не заменяет другую.

Один релиз между двумя площадками

Теперь сведём всё в сквозной пример. Условный сценарий: команда добавила в интернет-магазин новый способ расчёта доставки. Изменение затрагивает код, миграцию базы (новая таблица тарифов) и вызов внешнего API службы доставки. Ниже — путь релиза, а не отчёт о реальном проекте.

1. Сборка артефакта. Образ приложения собирается один раз в CI и получает digest. Именно этот образ, а не «тот же тег», будет развёрнут и в staging, и в production. Версии базовых образов в нём закреплены.
2. Выкатка в staging в Европе. Разработчики заходят на сервер, например через Remote SSH, смотрят логи запуска. Миграция выполняется на учебных данных: синтетические клиенты с адресами в разных регионах, несколько странных случаев вроде пустого индекса и очень длинного адреса.
3. Проверка логики. Вызовы службы доставки идут в тестовый контур провайдера или в заглушку. Тестировщик прогоняет сценарии: обычный заказ, заказ с недоступным API, заказ с неверным адресом. Если интеграция из Европы недоступна по условиям провайдера, это фиксируется как известное ограничение среды, а не как баг релиза.
4. Проверка прокси и заголовков. Убеждаемся, что конфигурация обратного прокси в staging та же, что и в production: те же лимиты тела запроса, те же правила для заголовков. Если вы добавили проброс нового заголовка, он проверяется здесь.
5. Решение о выпуске. Есть список того, что staging подтвердил (миграция проходит, расчёт верен, ошибки обрабатываются), и того, что он подтвердить не мог (сетевой путь до боевого API, поведение под реальной нагрузкой из России).
6. Выкатка в production. Разворачивается тот же образ с тем же digest. Миграция выполняется с учётом реального объёма данных; об этом нужно подумать заранее, потому что на учебном наборе она занимала секунды, а на боевых таблицах может идти заметно дольше.
7. Дымовой тест на боевой стороне. Один-два безопасных запроса из российской сети: открывается ли страница оформления, отвечает ли реальный API доставки, нормально ли время ответа. Если что-то не так, откат делается к предыдущему образу по его digest.

Обратите внимание, что разница стран ни разу не потребовала «копировать production». Она потребовала другого: одинакового артефакта, честного списка того, что проверено, и короткого боевого теста для того, что проверить в другом месте невозможно.

Как подобрать ресурсы под назначение

Перейдём к практике размещения. Здесь у MAATRIX есть несколько осмысленных ориентиров, но все они начальные точки для теста, а не обещание ёмкости.

Staging для небольшой команды обычно начинается с компактного тарифа. Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) или Uab (2 vCPU, 4 ГБ, 80 ГБ) подходят для функциональных проверок небольшого приложения, но если вы поднимаете на staging сразу базу, кэш, очередь и сам сервис, памяти может не хватить: проверить это можно только запуском. Если у приложения тяжёлая сборка или заметная база, разумно посмотреть на Heka (4 vCPU, 8 ГБ, 160 ГБ). Для production выбор определяется замерами реальной нагрузки, а не желанием «взять побольше»; тарифы Maat и Djed существуют для случаев, где измерения показали необходимость.

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

По локациям логика такая. Для production — та локация, из которой по вашим замерам удобнее всего дойти российским клиентам; в публичном предложении названы UK, US, RU и FR, и наличие конкретного образа или сервиса в конкретной локации нужно проверять в форме заказа. Для staging — та, откуда удобно работать команде и откуда доступны нужные ей репозитории и реестры. Если замеры показали, что обе задачи решает одна локация, это допустимый и более простой вариант. Разные страны не обязательны сами по себе: они оправданы, когда у сред разные «зрители».

Сам staging на VPS подробно разобран в материале про staging-окружение на VPS; здесь мы касались его только с точки зрения географии. Что касается развёртывания: оплата картой РФ или через СБП и автоматическое создание VPS в течение пары минут после оплаты позволяют поднять временный сервер для замера или для проверки производительности без долгой подготовки. Автоматические резервные копии во всех тарифах в публичном предложении не заявлены, поэтому копии данных и конфигурации лучше настроить самостоятельно, а не рассчитывать на них по умолчанию.

Где чаще всего расходятся ожидания

Несколько типичных ловушек, которые прямо вытекают из географического разделения.

«Работает на staging» воспринимается как «будет быстро в production». Staging в Европе не проверяет путь российского клиента. Если нужен ответ про скорость, измеряйте со стороны клиента, на боевой или зеркальной среде.

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

Тестовый платёж ушёл в боевой контур. Бывает, когда ключи и адреса интеграций хранятся в общей конфигурации. Разделите секреты по средам и проверяйте, что staging физически не имеет боевых ключей.

Образ «тот же», а поведение разное. Причина обычно в изменяемом теге. Закрепление по digest и осознанное обновление закреплённого образа убирают эту неопределённость.

Зеркалирование трафика без очистки. Если вы направляете копию боевых запросов на staging, помните, что прокси по умолчанию передаёт и тело, и заголовки. Без явной фильтрации реальные сведения попадут туда, куда им попадать не нужно.

Две среды, два назначения

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

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