Staged rollout без простоя: как катим headless-фронт поверх живого Битрикс-бэкенда
Автор: WebGoodPeople
Одно из самых частых возражений против headless-миграции: «мы не можем остановить сайт на неделю для релиза». И это справедливое возражение — если релиз действительно требует остановки. Проблема в формулировке: хороший staged rollout не требует остановки вообще. Ни на минуту.
В статье — наш реальный процесс: 6 шагов от «старый фронт на Битриксе» до «новый Next.js-фронт на 100% трафика», без единого зафиксированного даунтайма. С конкретными техническими решениями и точками отката на каждом шаге.
Почему «релиз = простой» — устаревшая модель
В классической схеме миграции: выкатили новое, проверили, что работает, переключились. Если что-то пошло не так — откатились на старое.
В этой модели есть два больших класса проблем:
- Проверка только на прод-трафике. Dev/staging не воспроизводят реальное поведение. Баги находят пользователи, не тестировщики.
- Откат — это ещё один релиз. Само переключение занимает 10–30 минут, за которые часть пользователей получают ошибки.
Staged rollout — это модель, где «старое» и «новое» сосуществуют одновременно, а переключение трафика идёт процентами. В любой момент можно «откатить» просто уменьшением процента нового трафика — это мгновенно и без простоя.
Архитектура: параллельный фронт над общим бэкендом
Ключевая идея — отделить фронт от бэка через API-слой. Бэкенд (Битрикс, 1С, legacy API) остаётся мастер-системой. Фронт существует в двух экземплярах:
- Старый (PHP-шаблоны Битрикса) — принимает часть трафика
- Новый (Next.js) — принимает другую часть
Оба фронта обращаются к одному и тому же API-слою. Контент/данные синхронизированы автоматически (они в одном источнике).
Переключение между ними идёт на уровне:
- DNS/Load balancer: процент трафика на каждый фронт
- Feature flag: конкретные страницы/модули на новом фронте
- User segment: тестовый сегмент получает новый фронт в 100% случаев
6 шагов staged rollout
Шаг 1. API-прослойка между Битриксом и фронтом
Ставим HTTP-слой между Битрикс и любым клиентом. Этот слой — мастер-контракт. Оба фронта (старый и новый) обращаются к одним и тем же эндпоинтам.
Технически: Next.js API routes или standalone Node.js service, который проксирует запросы в Битрикс через REST и кэширует результаты.
[Browser] → [Next.js API / Node service] → [Bitrix REST] → [MySQL]
Время: 1–2 недели на старт. Можно покрыть 80% сценариев (каталог, карточка, корзина, поиск).
Шаг 2. Полностью рабочий Next.js фронт на staging
Собираем полный клон текущего сайта на Next.js. Все страницы. Все роуты. Вся корзина. Работает на staging-домене.
Критерий готовности: можно полностью пройти user journey (категория → карточка → корзина → оформление) не зная, что ты на новом стеке.
Время: 4–8 недель. На этом этапе ещё нет продакшен-трафика.
Шаг 3. Canary: 5% трафика на новый фронт
Настраиваем load balancer (Nginx/HAProxy/Cloudflare) так, чтобы 5% пользователей попадали на новый фронт. Остальные 95% — на старый.
Критерии выбора «тех 5%»:
- Случайная выборка по IP
- Не VIP-пользователей (они раздражаются и шумят)
- Не весь трафик одной страны/региона (если fail — регион страдает)
Метрики, которые отслеживаем в реальном времени:
- Latency p95 по каждому ключевому endpoint
- Error rate (5xx и JS-ошибки на фронте через Sentry)
- Конверсия checkout на новом vs старом
Если любая из метрик деградирует больше чем на 10% от baseline — автоматический rollback до 0% за 30 секунд.
Длительность Canary: 3–5 дней. Смотрим и выходные (другое поведение трафика).
Шаг 4. Ramp-up: 5% → 20% → 50%
Если Canary прошёл чисто — увеличиваем процент. Рекомендуемая последовательность:
- День 1: 5% (Canary) → 20%
- День 3: 20% → 50%
- День 7: 50% → 100%
Между каждым шагом — дневной buffer для анализа. Вычисляем:
- Статзначимость разницы в конверсии (обычно новый фронт быстрее = конверсия выше)
- Нет ли «поздних» деградаций (которые появляются только на больших объёмах)
Шаг 5. 100% трафика + старый фронт в standby
100% трафика на новом фронте. Старый фронт остаётся живым ещё 2–4 недели. Стоимость хранения — копейки, а стоимость возможного быстрого отката — огромная.
Rollback процедура: меняем конфиг балансировщика, 100% трафика возвращается на старый фронт. Время выполнения: 2 минуты. Проверяется на staging каждую неделю до удаления старого.
Шаг 6. Удаление старого фронта
После 4 недель стабильной работы на 100% удаляем старый фронт. Код остаётся в git и в образе rollback-контейнера ещё 6 месяцев. Физически сервера старого фронта гасим.
Точки отката на каждом шаге
Ключевое свойство staged rollout — на каждом шаге есть откат без простоя:
Шаг Если fail — откатываемся к... Время Canary 5% 0% (весь трафик на старом) 30 сек Ramp-up 20% 5% (вернулись на Canary) 30 сек Ramp-up 50% 20% 30 сек 100% 50% или 0% 2 мин После удаления старого rebuild из образа в Kubernetes 15 минТехнические детали, которые обычно забывают
Data version in headers. Все API-ответы несут заголовок X-Data-Version. Если во время rollout меняется структура данных — старый фронт может не суметь прочитать новый формат. Заголовок позволяет фронтам договариваться.
Session preservation. Пользователь в момент rollout не должен потерять корзину. Session storage живёт в Redis, не привязан к фронту. Оба фронта читают из одного Redis.
CSRF / Cookie domains. Если старый фронт выставляет cookie для example.com, а новый — для www.example.com, сессии потеряются. Проверяем до Canary.
SSO / Auth. Если у вас SSO, JWT или session cookies — один и тот же токен должен работать на обоих фронтах. Обычно требует небольшой адаптер.
SEO: canonical tags. Пока два фронта параллельны, Google может индексировать обе версии. Рекомендуем: оба фронта отдают один и тот же rel=canonical на основной домен. Временный Sitemap на staging — только с noindex.
Что это даёт бизнесу
- Zero-downtime. Ни единой минуты простоя.
- Контролируемый риск. В любой момент можно откатиться за секунды.
- Статистически значимое сравнение. Рядом работают старый и новый — можно честно измерить разницу в конверсии, скорости, ошибках.
- Управляемая скорость. Если хочется быстрее — ускоряем ramp-up. Если консервативно — держим на Canary дольше.
Наш средний проект от «старт API-прослойки» до «100% на новом фронте без старого» занимает 12–16 недель. Из них только 3 недели требуют активной инженерной работы на фронте — остальное время тратится на Canary, ramp-up и стабилизацию.
Что делать прямо сейчас
Если вы готовите миграцию и слышите «это нужно делать за один большой релиз» — покажите эту статью. Это не обязательно. Staged rollout сложнее по инфраструктуре, но ради zero-downtime оно того стоит.
Если не знаете, готов ли ваш стек — закажите 48-часовой аудит. Мы смотрим: есть ли API-слой, как устроена сессия, можно ли поставить балансировщик. За 2 дня возвращаем список «готово» / «надо подготовить» / «блокер».