Когда пять процентов трафика говорят больше, чем стейджинг

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

Команда откатилась, но осадок остался. Пользователи потеряли доверие, а команда потратила два дня на отладку проблемы, которая проявлялась только в реальных боевых условиях.

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

Две распространённые стратегии — canary-релизы и staged rollout. Они звучат похоже, но решают разные задачи. Понимание разницы помогает выбрать правильный подход для каждого изменения, которое вы выкатываете.

Canary-релизы: пусть трафик решает

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

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

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

Canary-релизы полезны, когда нужно проверить стабильность изменения под реальной продакшен-нагрузкой. Стейдж отлично ловит логические ошибки, но не может воспроизвести хаос продакшена: неравномерные всплески трафика, медленные соединения с БД из определённых регионов или лимиты сторонних API, которые проявляются только под нагрузкой.

Эта стратегия хороша для высокорисковых изменений. Крупные переписывания бизнес-логики, миграции схем БД, обновления библиотек, затрагивающие сеть или конкурентность, изменения поведения кэша — всё это отличные кандидаты для canary-релиза. Если что-то пошло не так, затронута лишь малая часть пользователей, и вы можете быстро слить трафик с новой версии.

Staged rollout: выбираем, кто получит обновление первым

Staged rollout использует другой подход. Вместо случайного разделения трафика вы сами решаете, какие группы пользователей получат новую версию первыми. Эти группы часто называют кольцами (rings).

Первое кольцо может включать вашу внутреннюю команду и горстку бета-тестеров. Второе — процент пользователей из конкретного региона или с определённым типом устройства. Третье — всех пользователей бесплатного тарифа. Четвёртое — корпоративных клиентов с жёсткими SLA.

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

Главное отличие от canary-релизов — осознанность. Вы выбираете, кто получит новую версию, а не просто какой объём трафика. Это важно, когда разные группы пользователей имеют разные ожидания, сценарии использования или договорные обязательства.

Например, если ваше приложение обслуживает как обычных пользователей, так и крупные корпоративные аккаунты с подписанными SLA, вы вряд ли хотите случайно направить корпоративный запрос на багованную новую версию. Staged rollout позволяет сначала протестировать изменение на менее критичных пользователях, а затем расширять на высокоценных клиентов только после подтверждения стабильности.

Staged rollout также хорошо подходит для релизов мобильных приложений. На уровне сети управлять трафиком мобильного приложения сложно. Вместо этого вы выпускаете обновление для небольшого процента пользователей через функцию staged rollout в магазине приложений, мониторите краш-репорты и оценки, а затем расширяете охват.

Комбинирование обеих стратегий

На практике canary-релизы и staged rollout не исключают друг друга. Многие команды объединяют их в единый пайплайн прогрессивной доставки.

Диаграмма ниже показывает обе стратегии бок о бок и то, как их можно выстроить в цепочку.

flowchart TD A[Новая версия готова] --> B{Выбор стратегии} B --> C[Canary Release] B --> D[Staged Rollout] C --> C1[Направить 5% трафика] C1 --> C2{Здорова?} C2 -->|Да| C3[Увеличить до 20%] C2 -->|Нет| C4[Откат] C3 --> C5[Продолжить до 100%] D --> D1[Кольцо 1: Внутренние] D1 --> D2{Проблемы?} D2 -->|Нет| D3[Кольцо 2: Бета] D2 -->|Да| D4[Откат] D3 --> D5[Кольцо 3: Все пользователи] C5 --> E[Объединённый пайплайн] D5 --> E E --> F[Canary 5% → Staged Rings → Полный релиз]

Пайплайн может начинаться с canary-релиза на пяти процентах трафика для проверки технической стабильности. Если canary прошёл, пайплайн переходит к staged rollout: сначала внутренние пользователи, затем бета-тестеры, потом процент продакшен-пользователей и, наконец, все.

Такой комбинированный подход даёт два уровня безопасности. Canary ловит инфраструктурные проблемы — утечки памяти или медленные запросы к БД. Staged rollout ловит пользовательские проблемы — сломанные сценарии для определённых типов аккаунтов или регионов.

Хорошо спроектированный пайплайн прогрессивной доставки может автоматизировать эти решения. Он мониторит заданные метрики, сравнивает их с порогами и либо переходит к следующему шагу, либо ставит релиз на паузу для ручной проверки, либо запускает автоматический откат.

Что нужно иметь перед стартом

Стратегии прогрессивной доставки настолько полезны, насколько полезны данные, на основе которых вы принимаете решения. Без хорошей наблюдаемости canary-релиз — это просто более медленный способ сломать продакшен.

Вам понадобятся:

  • Мониторинг частоты ошибок в реальном времени с разбивкой по версиям
  • Перцентили задержек для новой версии в сравнении со старой
  • Бизнес-метрики, важные для вашего продукта: конверсия, завершение регистрации
  • Возможность связать жалобы пользователей с версией, которую они используют

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

Короткий практический чеклист

Если вы настраиваете прогрессивную доставку впервые, вот краткий список для реализации:

  • Начните с одной стратегии. Выбирайте canary-релизы, если вам важна техническая стабильность под продакшен-нагрузкой. Выбирайте staged rollout, если нужно контролировать, какие пользователи увидят изменение первыми.
  • Определите чёткие критерии go/no-go до начала. Какая частота ошибок допустима? Какое увеличение задержки — уже слишком много? Запишите эти пороги и настройте их в пайплайне.
  • Убедитесь, что мониторинг покрывает как технические, так и бизнес-метрики. Canary может показывать ноль ошибок, но при этом ломать процесс оформления заказа, если пользователи не могут завершить покупку.
  • Отработайте откат. Не ждите, пока что-то сломается, чтобы обнаружить, что переключение трафика занимает десять минут.
  • Комбинируйте стратегии только после того, как освоите каждую по отдельности. Объединённый пайплайн добавляет сложности, и важно понимать каждый уровень, прежде чем накладывать их друг на друга.

Конкретный вывод

Canary-релизы и staged rollout — это не про осторожность ради осторожности. Это про то, чтобы узнать, что продакшен на самом деле делает с вашим кодом, до того, как он доберётся до всех. Стейдж даёт уверенность в ваших тестах. Canary или staged rollout дают уверенность в реальности.

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