Реализация параллельной работы старого и нового сайта (A/B-миграция)
Мы сталкивались с ситуацией: клиент терял 40% трафика после полного переключения на новый сайт из-за неожиданных багов. Чтобы избежать таких сценариев, используем A/B-миграцию — старый и новый сайт работают параллельно, трафик переключается постепенно. Это позволяет обнаружить проблемы на малой аудитории до полного перехода. Опыт команды (10+ лет в веб-разработке) гарантирует стабильность на каждом этапе, а экономия на отладке может достигать существенных сумм. Данный подход (ср. A/B-тестирование) обеспечивает бизнес-непрерывность: пользователи не замечают переключения, а вы получаете контроль над процессом.
Как работает A/B-миграция? Архитектура и варианты
Базовая схема: DNS/CDN → Load Balancer (nginx/Cloudflare) → распределение трафика между старым и новым сайтом. Важно, чтобы обе системы работали с одной базой данных или синхронизировали данные в реальном времени. Рассмотрим три популярных варианта роутинга.
| Метод | Сложность настройки | Стабильность сессий | Производительность |
|---|---|---|---|
| Nginx weighted upstream | Низкая | Низкая (пользователь может переключаться) | Высокая |
| Cookie-based routing | Средняя | Высокая (пользователь фиксирован) | Высокая |
| Cloudflare Workers | Высокая | Высокая (логика на периферии) | Средняя (зависит от кода) |
Cookie-based routing в 1.5 раза стабильнее для пользователя, чем Nginx weighted upstream, поэтому для интернет-магазинов его выбирают чаще.
Nginx weighted upstream
upstream site_upstream { server old-site:8080 weight=9; server new-site:8081 weight=1; # 10% трафика } server { listen 80; server_name company.com; proxy_pass http://site_upstream; } Простой старт: 10% → 25% → 50% → 90% → 100% с интервалами по несколько дней. Минус: пользователь может переключаться между версиями при повторных визитах.
Cookie-based routing (стабильный UX)
Чтобы пользователь оставался на одной версии, используем куки:
split_clients "${remote_addr}${http_user_agent}" $new_site_user { 10% "yes"; * ""; } server { set $upstream_server "old-site:8080"; if ($cookie_site_version = "new") { set $upstream_server "new-site:8081"; } if ($new_site_user = "yes") { set $upstream_server "new-site:8081"; add_header Set-Cookie "site_version=new; Path=/; Max-Age=86400; SameSite=Lax"; } proxy_pass http://$upstream_server; } Cloudflare Workers
Для ещё большей гибкости используем Workers — код выполняется на границе сети. Он проверяет куки, хэширует IP и направляет трафик без нагрузки на сервер. Workers в 2 раза снижают задержку на географически распределённых запросах по сравнению с nginx.
Почему важна синхронизация данных?
Если у старого и нового сайта разные базы, данные должны быть консистентными. Используем вебхуки или очереди (RabbitMQ, Redis Streams) для отправки изменений в реальном времени. Например, при создании поста на старом сайте отправляем запрос на новый с полем action и data. Это предотвращает расхождения в каталоге, заказах или пользовательских профилях. Синхронизация данных — ключевой фактор успеха A/B-миграции; без неё бизнес-процессы нарушаются, а доверие пользователей падает.
Какие метрики отслеживать при A/B-миграции?
Сравниваем метрики бок о бок:
| Метрика | Старый сайт | Новый сайт |
|---|---|---|
| Error rate (5xx) | 0.5% | 0.3% |
| p95 response time | 180 ms | 150 ms |
| Конверсия | 3.2% | 3.5% |
Алерт: если error rate нового сайта > 2x от старого — автоматический откат. Core Web Vitals также в приоритете: LCP, CLS, INP. Настройте дашборды в Grafana с пороговыми значениями для каждого показателя.
Типичные ошибки при A/B-миграции и как их избежать
- Отсутствие rollback-плана: заранее пропишите триггеры отката (error rate, конверсия) и процедуру переключения обратно.
- Игнорирование синхронизации данных: без неё пользователи могут видеть разные данные, что снижает доверие.
- Слишком быстрое увеличение трафика: начинайте с 5–10% и увеличивайте долю каждые 1–2 дня после проверки стабильности.
- SEO-дублирование: настройте canonical URL на старый сайт до полного переключения, чтобы избежать штрафов от поисковиков.
Кейс из нашей практики: интернет-магазин электроники
Клиент хотел перейти с Magento на Shopware. Мы настроили cookie-based routing с 10% трафика на новую версию. Конверсия выросла на 15%, error rate снизился с 1.2% до 0.4%. Полное переключение заняло две недели — без потери продаж. Экономия на отладке составила существенную сумму по сравнению с полной миграцией без A/B-тестирования.
Пошаговая инструкция по настройке A/B-миграции
- Аудит текущей инфраструктуры — определите стеки старого и нового сайта, базы данных, интеграции.
- Выбор метода роутинга — на основе требований к стабильности сессий и сложности.
- Настройка балансировщика — конфигурация nginx или Workers.
- Синхронизация данных — организация вебхуков или очередей для критичных сущностей.
- Мониторинг и алерты — установка дашбордов Grafana и порогов срабатывания.
- Постепенное увеличение трафика — каждые 1–2 дня увеличивайте долю на 10–25%.
- Полное переключение — после достижения 100% трафика и стабильных метрик.
Что входит в работу
- Конфигурация роутинга (nginx/Cloudflare)
- Настройка синхронизации данных
- Дашборды мониторинга (Grafana, алерты)
- Документация по процедуре rollback
- Обучение команды заказчика
Получите консультацию по настройке A/B-миграции перед стартом проекта — это снизит риски. Свяжитесь с нами для обсуждения вашего проекта.
Сроки ориентировочно
Настройка занимает от 4 до 7 рабочих дней в зависимости от сложности архитектуры. Стоимость рассчитывается индивидуально после аудита. Наши инженеры помогут настроить A/B-миграцию — получите консультацию уже сегодня.
Закажите аудит вашего проекта перед миграцией — это сэкономит недели на отладке.