Сравните стратегии деплоя: rolling, blue-green и canary. Какие у каждой плюсы, риски и требования к инфраструктуре?
Короткий ответ
- Rolling — постепенная замена инстансов, дефолт в Kubernetes
- Blue-green — два окружения и мгновенное переключение трафика
- Canary — малый процент трафика на новую версию с анализом метрик
- Blue-green даёт быстрый откат, но удваивает ресурсы
- Canary требует управления трафиком и хороших метрик
- Все стратегии требуют обратной совместимости схемы БД
Выбор стратегии — компромисс между скоростью отката, стоимостью ресурсов и зрелостью мониторинга.
Как сказать вслух
пример ответаRolling update — это постепенная замена старых инстансов новыми, он дёшев, но откат небыстрый и в моменте работают обе версии. Blue-green держит два одинаковых окружения: трафик переключается целиком и мгновенно, откат — это переключение обратно, но нужно вдвое больше ресурсов. Canary выводит новую версию на небольшой процент трафика и по метрикам решает, раскатывать ли дальше — это самый безопасный способ, но он требует умного управления трафиком и качественного мониторинга. Отдельно всегда слежу за совместимостью миграций базы, иначе откат невозможен при любой стратегии.
Подробный ответ
Основной ответ
Rolling update заменяет инстансы партиями (в Kubernetes — maxSurge/maxUnavailable); дешёв, но проблемная версия успевает раскатиться широко, а откат занимает время. Blue-green: два полных окружения, релиз ставится в пассивное, прогревается и проверяется, затем трафик переключается на балансировщике целиком; откат мгновенный, цена — двойные ресурсы и требование совместимости БД, так как обе версии смотрят в одну базу. Canary: новая версия получает 1–5–25% трафика с автоматическим анализом метрик (ошибки, латентность) и прогрессивным увеличением; реализуется через Argo Rollouts, Flagger, веса в service mesh или на балансировщике. Общие требования: health checks, обратная совместимость API и схемы данных (expand/contract-миграции), feature flags как дополнение.
Ключевые моменты
- Скорость отката. Blue-green откатывается переключением трафика за секунды; rolling — только повторной раскаткой.
- Цена ошибки. Canary ограничивает blast radius процентом трафика — проблему увидят немногие пользователи.
- Требования canary. Нужны точное деление трафика и автоматический анализ метрик, иначе canary вырождается в формальность.
- База данных. Миграции должны быть обратно совместимы при любой стратегии: обе версии приложения работают с одной схемой.
Практический контекст
Вопрос встречается и в теоретической части, и в system design. На практике выбор зависит от зрелости: большинство живёт на rolling, критичные сервисы заводят canary через Argo Rollouts или Flagger, blue-green чаще применяют для монолитов и окружений с дорогим даунтаймом. Интервьюер ценит, когда кандидат сам поднимает тему миграций БД и автоматического анализа метрик, а не только рисует схемы переключения трафика.
Частые ошибки
- Забывают про совместимость миграций базы данных при откате
- Представляют canary без автоматического анализа метрик — «посмотрим глазами»
- Не упоминают стоимость blue-green в виде двойной инфраструктуры