Для безпечного переключення на новий сайт ми використовуємо A/B-міграцію. Ми стикалися з ситуацією: клієнт втрачав 40% трафіку після повного перемикання на новий сайт через неочікувані баги. Щоб уникнути таких сценаріїв, використовуємо A/B-міграцію — старий і новий сайт працюють паралельно, трафік перемикається поступово. Це дозволяє виявити проблеми на малій аудиторії до повного переходу. Наша команда має 10+ років досвіду та успішно реалізувала понад 20 міграцій. Досвід команди (10+ років у веб-розробці) гарантує стабільність на кожному етапі, а економія на налагодженні може сягати до $3,000. Даний підхід (пор. A/B-тестування) забезпечує бізнес-безперервність: користувачі не помічають перемикання, а ви отримуєте контроль над процесом.
Як працює A/B-міграція? Архітектура та варіанти
Базова схема: DNS/CDN → Load Balancer (nginx/Cloudflare) → розподіл трафіку між старим і новим сайтом. Важливо, щоб обидві системи працювали з однією базою даних або синхронізували дані в реальному часі. Розглянемо три популярні варіанти роутингу.
| Метод | Складність налаштування | Стабільність сесій | Продуктивність |
|---|---|---|---|
| Nginx weighted upstream | Низька | Низька (користувач може перемикатися) | Висока |
| Cookie-based routing | Середня | Висока (користувач фіксований) | Висока |
| Cloudflare Workers | Висока | Висока (логіка на периферії) | Середня (залежить від коду) |
Cookie-based routing краще ніж Nginx weighted upstream у 1.5 рази за стабільністю сесій, тому для інтернет-магазинів його обирають частіше.
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 і направляє трафік без навантаження на сервер. Cloudflare 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%. Повне перемикання зайняло два тижні — без втрати продажів. Економія на налагодженні склала близько $2,000.Покрокова інструкція з налаштування A/B-міграції
- Аудит поточної інфраструктури — визначте стеки старого та нового сайту, бази даних, інтеграції.
- Вибір методу роутингу — на основі вимог до стабільності сесій та складності.
- Налаштування балансувальника — конфігурація nginx або Workers.
- Синхронізація даних — організація вебхуків або черг для критичних сутностей.
- Моніторинг та алерти — встановлення дашбордів Grafana та порогів спрацювання.
- Поступове збільшення трафіку — кожні 1–2 дні збільшуйте частку на 10–25%.
- Повне перемикання — після досягнення 100% трафіку та стабільних метрик.
Що входить в роботу
- Конфігурація роутингу (nginx/Cloudflare)
- Налаштування синхронізації даних
- Дашборди моніторингу (Grafana, алерти)
- Документація з процедури rollback
- Навчання команди замовника
Отримайте консультацію з налаштування A/B-міграції перед стартом проекту — це знизить ризики. Зв'яжіться з нами для обговорення вашого проекту.
Строки орієнтовно
Налаштування займає від 4 до 7 робочих днів залежно від складності архітектури. Вартість розраховується індивідуально після аудиту. Наші інженери допоможуть налаштувати A/B-міграцію — отримайте консультацію вже сьогодні.
Замовте аудит вашого проекту перед міграцією — це зекономить тижні на налагодженні.