Canary Deployment
Eine Deployment-Strategie, bei der neue Modellversionen zunächst nur einem kleinen Teil der Nutzer ausgeliefert werden, um Probleme früh zu erkennen.
Eine Deployment-Strategie, bei der neue Features schrittweise an Nutzergruppen ausgerollt werden – kombiniert A/B-Testing mit kontrolliertem Release.
A/B Rollout rollt neue Features schrittweise aus: Erst 1% der Nutzer, dann 10%, dann 50%, dann alle. So erkennst du Probleme früh, bevor alle betroffen sind.
Der Prozess:
Tag 1: 1% der Nutzer → Monitoring, Fehler prüfen
Tag 2: 10% der Nutzer → Performance, Feedback
Tag 3: 50% der Nutzer → Skalierung testen
Tag 4: 100% der Nutzer → Vollständiger Launch
Bei Problemen: Sofort auf 0% zurück!
Vergleich Deployment-Strategien:
| Strategie | Nutzer-Exposure | Rollback | Use Case |
|---|---|---|---|
| Big Bang | 100% sofort | Schwer | Kleine Änderungen |
| Blue-Green | 100% Switch | Schnell | Infrastruktur |
| Canary | 1-5% → 100% | Schnell | Kritische Services |
| A/B Rollout | Graduell | Sehr schnell | Features |
from hashlib import md5
class FeatureFlag:
def __init__(self, name, rollout_percentage=0):
self.name = name
self.rollout_percentage = rollout_percentage
def is_enabled(self, user_id):
# Sticky Assignment: User bekommt immer gleiches Ergebnis
hash_value = int(md5(f"{self.name}:{user_id}".encode()).hexdigest(), 16)
bucket = hash_value % 100
return bucket < self.rollout_percentage
# Nutzung
new_checkout = FeatureFlag("new_checkout", rollout_percentage=10)
if new_checkout.is_enabled(user.id):
return render_new_checkout()
else:
return render_old_checkout()
# rollout-plan.yaml
feature: new_recommendation_engine
stages:
- name: canary
percentage: 1
duration: 2h
success_criteria:
error_rate: "< 0.1%"
latency_p99: "< 200ms"
- name: early_adopters
percentage: 10
duration: 24h
success_criteria:
error_rate: "< 0.1%"
conversion_rate: "> baseline"
- name: half
percentage: 50
duration: 24h
success_criteria:
error_rate: "< 0.1%"
user_satisfaction: "> baseline"
- name: full
percentage: 100
rollback_trigger:
- error_rate: "> 1%"
- latency_p99: "> 500ms"
def compare_rollout_metrics(feature_name):
control = get_metrics(feature_name, enabled=False)
treatment = get_metrics(feature_name, enabled=True)
comparison = {
"error_rate": {
"control": control["error_rate"],
"treatment": treatment["error_rate"],
"diff": treatment["error_rate"] - control["error_rate"]
},
"latency_p99": {
"control": control["latency_p99"],
"treatment": treatment["latency_p99"],
"diff": treatment["latency_p99"] - control["latency_p99"]
},
"conversion": {
"control": control["conversion_rate"],
"treatment": treatment["conversion_rate"],
"lift": (treatment["conversion_rate"] - control["conversion_rate"])
/ control["conversion_rate"] * 100
}
}
return comparison
def auto_rollback_check(feature, metrics):
thresholds = feature.rollback_thresholds
if metrics["error_rate"] > thresholds["max_error_rate"]:
rollback(feature, reason="Error rate exceeded")
alert("Automatic rollback triggered")
return True
if metrics["latency_p99"] > thresholds["max_latency"]:
rollback(feature, reason="Latency exceeded")
alert("Automatic rollback triggered")
return True
return False A/B Rollout ist wie ein Soft-Opening eines Restaurants: Erst lädst du Freunde ein (1%), dann öffnest du für Nachbarn (10%), dann für alle – so kannst du Probleme früh erkennen und beheben.
Schrittweise Erhöhung des Nutzeranteils (1% → 10% → 50% → 100%)
Feature Flags steuern, wer das Feature sieht
Schnelles Rollback bei Problemen möglich
Feature Releases
Neue Features schrittweise an Nutzer ausrollen
Risikominimierung
Probleme früh erkennen bei kleiner Nutzergruppe
Performance-Tests
Last schrittweise erhöhen
Feedback sammeln
Frühe Nutzer-Reaktionen vor vollem Launch
A/B Testing: Zwei Varianten vergleichen für Entscheidung. A/B Rollout: Eine neue Version schrittweise ausrollen. Oft kombiniert: Rollout mit Metriken-Vergleich.
Abhängig von Risiko und Monitoring. Typisch: 1% für 1h, 10% für 1 Tag, 50% für 1 Tag, 100%. Bei Problemen: Sofort stoppen oder zurückrollen.
Sticky Assignment: Nutzer bleibt in seiner Gruppe (per User-ID Hash). Wichtig für konsistente Experience und valide Metriken.