Blue-green и канареечный деплой: что выбрать

Blue-green позволяет мгновенно переключить продакшен между двумя окружениями, а канареечный деплой выпускает новую версию на небольшой доле трафика. Ошибка выбора стоит не только машинных ресурсов: неудачный релиз может затронуть всех пользователей, оставить несовместимые записи в базе и усложнить откат. Ниже — практическое сравнение двух схем для сервисов, которые нужно обновлять без длительного простоя.

В чём разница между двумя схемами

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

В канареечной схеме новая версия получает только часть запросов. Доля может задаваться через ingress, балансировщик, service mesh или специализированный контроллер релизов. Сначала проверяется небольшой сегмент, затем трафик увеличивается ступенями.

Обе схемы решают одну задачу — снизить риск обновления без остановки сервиса. Но риск они распределяют по-разному: blue-green упрощает откат после переключения, а canary уменьшает радиус поражения до переключения.

Blue-green отвечает на вопрос «как быстро вернуться назад», а canary — на вопрос «как не отправить сомнительную версию всем сразу».

Канареечный релиз — это постепенная выдача новой версии части пользователей или запросов с контролем метрик и возможностью остановить продвижение.[1]

Сравнение по цене и риску

Здесь нет универсального победителя. Если вам важен короткий и понятный rollback, blue-green чаще оказывается проще. Если главный страх — незаметная ошибка в рабочем трафике, canary даёт более контролируемый путь к релизу.

Как выбрать схему для конкретного сервиса

Выбирайте blue-green, если важен быстрый возврат

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

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

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

Выбирайте canary, если ошибка проявляется только на реальном трафике

Канареечная схема сильнее там, где поведение зависит от размера запросов, конкретных клиентов, региона, типа устройства или редких бизнес-сценариев. Тестовый набор может пройти успешно, а проблема появится только у части пользователей.

Цена — операционная сложность. Вам нужны стабильные правила распределения трафика, отдельные метрики по версиям и понятные условия остановки. Если новая версия получает запросы, но её ошибки смешиваются с показателями старой, canary превращается в декоративный процент без контроля.

Для первого этапа обычно выбирают небольшую долю трафика, затем увеличивают её по заранее заданным ступеням. Универсального процента нет: он зависит от объёма запросов, допустимого риска и того, как быстро система накапливает статистику.

Что проверить до первого переключения

1. Опишите границы релиза. Зафиксируйте, какие версии приложения, конфигурации, очереди и фоновые задачи входят в поставку. Если blue-green переключает только HTTP-трафик, а worker уже запущен в двух версиях, это не полный rollback.
2. Проверьте совместимость базы. Используйте изменения, которые старая и новая версия могут пережить одновременно: сначала добавляйте новые поля или таблицы, затем переводите код, а удаление старого оставляйте на отдельный релиз. Проверка — старая версия продолжает читать и записывать данные после выката новой.
3. Разделите метрики по версиям. Смотрите не только среднее время ответа, но и доли ошибок, таймауты, коды 4xx и 5xx, потребление CPU и памяти, длину очередей и бизнес-результат. Проверка — по каждой версии можно увидеть собственные значения за одинаковый интервал.
4. Определите условие остановки. До релиза запишите, при каком росте ошибок, задержки или отказов канареечный этап прекращается. Проверка — дежурный инженер может принять решение по дашборду, не споря о том, «похоже ли это на проблему».
5. Протестируйте возврат. Выполните rollback на стенде или в отдельном тестовом окружении, включая возврат маршрутизации, остановку фоновых задач и очистку временной конфигурации. Проверка — старая версия принимает новые запросы и не получает повреждённые данные.

Где обе схемы ломаются

Несовместимые изменения базы

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

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

Сессии, кеши и постоянные соединения

Если сессия хранится только в памяти конкретного инстанса, переключение между blue и green может разлогинить пользователя. При canary один и тот же клиент может попадать на разные версии, если балансировщик не обеспечивает закрепление маршрута.

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

Фоновые задачи и повторная обработка

При одновременном запуске двух окружений worker может дважды взять одну задачу или начать обрабатывать очередь новым форматом. Отдельно проверьте блокировки, идемпотентность операций и правила остановки старых обработчиков.

Неправильная маршрутизация

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

Когда что выбирать

• Blue-green — если у вас один основной сервис, есть запас ресурсов и требуется максимально простой сценарий возврата.
• Canary — если важна проверка на настоящем трафике, а система умеет надёжно разделять пользователей и собирать метрики по версиям.
• Комбинация — если можно сначала поднять green как отдельное окружение, а затем направить на него небольшой процент трафика. Это объединяет изоляцию blue-green с постепенной проверкой canary, но требует более сложной маршрутизации.

Не выбирайте canary только потому, что он экономит ресурсы на первом этапе. Если нет автоматического контроля метрик и безопасного возврата, вы просто переносите риск из момента переключения в процесс наблюдения.

Что делать дальше

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

Для Kubernetes конкретная реализация зависит от используемого ingress, балансировщика или контроллера прогрессивных поставок; названия полей и возможности могут различаться между версиями. После выбора механизма отдельно проверьте три показателя в продакшене: долю ошибок по версиям, p95 или p99 задержки и время от команды rollback до восстановления стабильного трафика.