Выбор стратегии деплоя

Действуй как Release Engineer. Выбери стратегию деплоя для {{service}}. Профиль трафика: {{traffic_profile}}. Tolerance: {{risk_tolerance}}.

Шаги

1. Оцени 4 измерения сервиса.

   • Statefulness. Stateless (web/API) → любая стратегия. Stateful (worker с in-memory state, БД) → ограниченный выбор.
   • Backward compatibility. Новая версия совместима со старой (одна БД-схема, один API contract)? Если нет — нужны expand-contract миграции.
   • Traffic shape. Steady RPS → canary удобен. Spiky (cron, batch) → rolling/blue-green проще.
   • Бюджет инфры. Blue-green требует 2× capacity на время деплоя. На малых инсталляциях это дорого.

2. Сравни 5 стратегий.

3. Decision tree.

   • Stateless + steady traffic + есть observability? → canary (5% → 25% → 100% с auto-promotion).
   • Stateless + spiky / низкий трафик? → rolling с health-check.
   • Большой релиз (мажор, breaking deps) + бюджет на 2×? → blue-green.
   • Новый алгоритм/тяжёлая логика, нужна prod-валидация без риска? → shadow (mirror traffic, compare outputs).
   • Постепенный rollout фичи по сегментам пользователей? → feature flag (поверх любой deploy-стратегии).
   • Stateful воркер с in-memory state? → blue-green или managed drain (graceful shutdown с persistent state checkpoint).

4. Combination strategies.

   • Canary + feature flag: деплоим binary через canary (инфраструктурная безопасность), фичу включаем через flag (продуктовая безопасность).
   • Blue-green + DB migration: миграция запущена до switch (expand), switch, после стабилизации — contract.
   • Shadow → canary → rolling: для критических сервисов прогоняем последовательно.

Anti-patterns

• ❌ Canary без auto-promotion и без auto-rollback — превращается в «manual prod testing» с забытой канарейкой неделями.
• ❌ Blue-green с shared state (одна БД, общий cache) — green получает данные blue'я, тесты на green не отражают реальность.
• ❌ Rolling deploy с maxUnavailable=0 на 2-реплика сервисе — деплой никогда не закончится.
• ❌ Feature flag без kill-switch и без TTL — флагов становится 200, никто не помнит что они делают.
• ❌ Shadow trafic, но при этом тень пишет в БД — корраптит данные.

Формат вывода

## Выбранная стратегия: <name>
## Обоснование
- Statefulness: ...
- Traffic: ...
- Risk: ...
- Cost: ...

## Implementation plan
- Tooling (Argo Rollouts / Flagger / vanilla k8s / Cloud-native)
- Traffic split steps
- Promotion criteria (metrics + thresholds)
- Rollback triggers

## Pre-flight checklist
- [ ] Backward-compat verified
- [ ] Observability ready (per-version metrics)
- [ ] DB migrations decoupled
- [ ] Rollback runbook tested

## Risks & mitigations
| Risk | Likelihood | Mitigation |

Принцип: стратегия — это не «модно vs немодно». Это compromise между скоростью feedback и blast radius. Выбирай по сервису, а не по компании.