Какие стратегии деплоймента существуют

Что проверяют

Понимаете ли вы, как выкатить новую версию без простоя и быстро откатиться, и что это требует от кода, а не только от инфраструктуры. Python-разработчику следом почти всегда задают вопрос про миграции базы: что будет, когда старая и новая версии работают одновременно.

Как отвечать

Назовите стратегии с ценой каждой:

• recreate: остановили старую версию, запустили новую. Просто, но с простоем. Годится, когда две версии не могут жить вместе;
• rolling update: инстансы заменяются постепенно. Это поведение Deployment в Kubernetes по умолчанию, темп задают maxSurge и maxUnavailable (по умолчанию 25%). Какое-то время трафик обслуживают обе версии;
• blue-green: рядом с рабочим окружением поднимают второе с новой версией и после проверки переключают на него трафик. Откат это обратное переключение, но ресурсов нужно вдвое больше;
• canary: новая версия получает малую долю трафика, например 5%, и её долю поднимают, пока метрики в норме. В Kubernetes это делают Argo Rollouts, Flagger или веса в сервис-мешах;
• shadow-трафик: копия реальных запросов идёт на новую версию, но её ответы пользователю не отдаются. Хорошо для проверки под нагрузкой, опасно для запросов с побочными эффектами;
• feature flags: код выкатывается выключенным, функцию включают отдельно и для части пользователей. Деплой отделяется от релиза.

Для Python-сервиса добавьте детали: миграции Alembic или Django идут по схеме expand/contract (добавить колонку, выкатить код, потом убрать старое), readiness-проба не пускает трафик на неготовый процесс, Gunicorn или Uvicorn по SIGTERM дорабатывают текущие запросы, а задачи Celery от старой версии должны читаться новыми воркерами.

Где спотыкаются

Забывают про схему базы. При rolling и canary старый код работает с новой схемой, и переименование колонки одной миграцией роняет старые поды.

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

Путают canary и A/B-тест. Канарейка проверяет стабильность версии по ошибкам и задержкам, A/B-тест сравнивает продуктовые метрики, у них разные цели и сроки.