Canary и shadow deployment ML на собеседовании Data Scientist

Зачем разбирать на собесе

Production ML deployment — не просто replace. На собесе DS / MLE: «отличие canary и shadow», «как rollback».

Shadow deployment

Новая модель работает параллельно старой, но её предсказания не используются для users. Просто логируем.

Request → old model → response (used)
                   → new model → response (logged, not shown)

Зачем:

• Latency / throughput тестирование на real traffic.
• Сравнение predictions old vs new (на одинаковых inputs).
• Безопасно — пользователь видит только old.

Минус. 2× compute cost. Но safe.

Canary deployment

Новая модель работает на малой части traffic (1%, 5%, 10%). Постепенно увеличивается, если метрики OK.

99% → old model
 1% → new model     (initial canary)
                    
 → если ОК через 1 час
 
90% → old
10% → new
   
 → ещё OK
   
0%  → old (стоп)
100% → new

Зачем:

• Реальный feedback (impression на user behaviour).
• Минимизация blast radius при проблемах.
• Постепенно собирается evidence.

Метрики мониторинга:

• Business metrics (CTR, conversion).
• Latency / errors.
• Model-specific (prediction distribution).

Blue-Green

Две версии: текущая (blue) и новая (green). Switch через router — в один момент весь трафик идёт на green.

Pre-cutover:  100% → blue, 0% → green
Cut over:     0% → blue,   100% → green (instant)
Rollback:     instant back to blue

Минус для ML — мгновенный switch, нет gradual rollout. Подходит для simple replacement, не A/B testing.

A/B test для ML

Treatment vs control с RCT. 50/50 (или другая пропорция).

Отличие от canary: A/B test тестирует business hypothesis с statistical significance. Canary — больше про safety / monitoring.

Метрики:

• Primary KPI (revenue, conversion).
• Guardrails (error rate, latency).
• Long-term (retention).

Длительность. Стандарт — 2 недели для weekly cycles. ML A/B часто требует больше (для stable signals).

CUPED. Variance reduction техника, accelerates A/B на ML metrics.

Rollback strategy

Auto-rollback triggers:

• Error rate spike (> threshold).
• Latency p99 spike.
• Business metric drop.
• Model output anomaly.

Mechanism:

• Feature flag toggle (use_new_model = false).
• Routing tier reset.
• Re-deploy old model image.

Speed. Должен быть < 5 минут. На production — automated, не manual.

Частые ошибки

Только staging тестирование без production rollout. Staging ≠ prod traffic. Часть проблем видна только на real.

Всё или ничего. Заменить модель за раз — рисково. Canary всегда (даже на минимальной модели).

Без guardrails. Метрики drift'а / latency на canary должны блокировать дальнейший rollout.

Долгий shadow. 2× compute cost. После N дней — переход к canary.

Reset baseline. Сравнивать new model только с current production. Не с предыдущей версией без context.

Связанные темы

• MLOps на собесе DS
• Data drift на собесе DS
• Feature Store на собесе DS
• MLflow и DVC на собесе DS
• Подготовка к собесу Data Scientist

FAQ

Что такое switchback?

A/B на time slots — все юзеры в один момент видят one variant, потом switch. Полезно для market-level effects (recsys в Uber).

Это официальная информация?

Нет. Статья основана на индустриальных best practices (Netflix, Uber, Google ML deployment).

Тренируйте Data Science — откройте тренажёр с 1500+ вопросами для собесов.