Blue-Green und Canary Releases

(Abschnitt: Architektur und Protokolle)

1) Warum wir „sichere Ausrollen“ brauchen

In modernen Systemen geht es bei der Veröffentlichung nicht nur um die Lieferung von Code, sondern auch um ein überschaubares Experiment im Vertrieb: Wir minimieren gleichzeitig das Risiko (wir brechen die Nutzer nicht auf) und verkürzen die Rückkopplungszeit (wir sehen schnell den Effekt). Zwei klassische Strategien - Blue-Green und Canary - lösen dies auf unterschiedliche Weise, aber mit einem gemeinsamen Ziel: Null Downtime, schneller Rollback, SLO-Beobachtbarkeit.

2) Grundlegende Definitionen

Blue-Green

Wir halten zwei vollständige Kopien der Prod-Umgebung: aktiv (Blau) dient dem Verkehr, passiv (Grün) bereitet die neue Version vor. Die Umschaltung erfolgt atomar (Schalter/Flip) auf Balancer/Router-Ebene. Wenn es schlimmer wird, kehren wir sofort zu Blue zurück.

Canary

Wir rollen die Teile aus: zuerst ein kleiner% des Verkehrs (zum Beispiel 1-5%), beobachten die Metriken/SLO, dann erhöhen wir den Anteil schrittweise (10% → 25% → 50% → 100%). Bei Degradation - Rollback oder Stop beim vorherigen stabilen Schritt.

3) Wann welcher Ansatz besser ist

• Wir brauchen einen sofortigen Rollback ohne komplizierte Manöver.
• Architektur/Budget ermöglicht doppelte infrastrukturelle Duplizierung.
• Wir wollen große Migrationen oder Plattform-Updates (OS/JDK/Rantime) isoliert durchführen.
• Die Anwendungs-/Verbindungspools reagieren empfindlich auf einen allmählichen „gemischten“ Zustand.

• Sie müssen den Blast-Radius minimieren und das Verhalten auf dem Benutzeranteil sehen.
• Hohe Release-Frequenz, progressive Lieferung als Norm.
• Es gibt eine reife Beobachtbarkeit und automatische Tore (error budget, latency, conversion).
• Das Produktteam möchte Hypothesen testen: Auswirkungen auf Conversion, Retention, LTV usw.

4) Allgemeine Grundsätze für eine erfolgreiche Veröffentlichung

Idempotente Bildartefakte: das gleiche Bild/Paket in allen Phasen.
Deterministische Konfiguration: config als Code, Vergleichbarkeit von Umgebungen.
Beobachtbarkeit nach Design: Protokolle, Metriken, Traces, Alerts; SLI/SLO im Voraus.
Schnelles, automatisiertes Rollback: Die Schaltfläche/der Rollback-Befehl ist Teil der Pipeline und nicht der manuellen Magie.
Kompatible Schaltungsänderungen: Strategie expand-migrate-contract (siehe § 10).
Routing auf L7-Ebene (wünschenswert): Flexibilität durch Header/Cookies/Pfade/API-Versionen.

5) Blau-Grün: Architektur und Prozess

5. 1 Topologie

Zwei Prod-Stacks: Blau (aktiv) und Grün (Kandidat).
Allgemeine externe Abhängigkeiten: CDN, externe APIs, Warteschlangen; DB ist ein Sonderfall (siehe § 10).
Schaltpunkt: Balancer/Ingress/Gateway.

5. 2 Schritt-für-Schritt-Flow

1. Wir heben Green unter einem neuen Artefakt (vNext) an, führen Smoktests durch.
2. Run auf Autotests gegen Grün (e2e, vertraglich, regressiv).
3. Wir wärmen den Cache/die Sessions auf (falls zutreffend), synchronisieren die Hintergrundjobs/Warteschlangen.
4. Wir schalten den Verkehr auf Grün: atomar flip (DNS TTL niedrig, Route/Listener swap, Ingress Gewicht = 100%).
5. Wir beobachten SLO in den ersten Minuten/Stunden (goldene Signale: Latenz, Fehler, Sättigung + Geschäftsmetriken).
6. Bei Problemen - sofortige Rückkehr zu Blau (Flip Back).

5. 3 Vor-/Nachteile

Vorteile: sofortiger Rollback, einfaches mentales Modell, saubere Isolation.
Nachteile: Verdoppelung der Infrastruktur, Komplexität mit stateful Komponenten und Datenmigrationen.

6) Canary: Architektur und Prozess

6. 1 Topologie

Ein einziger Prod-Cluster; mehrere Versionen des Dienstes (stabil und kanarisch) hinter einer einzigen Front.
Der Verkehr wird nach Gewichten (1-5-10-25-50-100%) oder nach Zielen (nach Header/Cook/ID) aufgeteilt.

6. 2 Schritt-für-Schritt-Flow

1. Deploy canary-Versionen in der gleichen cluster/ASG/NSG.
2. Routing eines Teils des Datenverkehrs (z. B. 1-5%) auf Canary.
3. Automatische SLI/SLO-Prüfungen und Geschäftsmetriken; Gates in CI/CD (Fehlerrate, p95 Latenz, CPU/RES, Konvertierung, Fehler/Return).
4. Schrittweise Erhöhung des Verkehrsanteils beim Passieren von Gates.
5. Volle Rollout bis zu 100% und Deaktivierung der alten Version; beim Abbau - Auto-Rollback.

6. 3 Vor-/Nachteile

Vorteile: minimales Risiko für die meisten Benutzer, datengetriebene Lösung.
Nachteile: Sie brauchen eine reife Beobachtbarkeit, kompetentes Routing, das Risiko einer „Version Skew“ zwischen den Instanzen.

7) Verkehrslenkung

Stufe L4: Saldo nach IP/Ports; einfach, aber wenig Flexibilität.
Ebene L7: HTTP/S-Regeln - Pfad, Host, Header, Cookies, User-Agent, GeoIP, SNI.

• Gewichtetes Routing (Gewichte 1-100%).
• Header-based/Cookie-based (Festlegen eines Benutzers in einer Gruppe).
• Session Stickiness (wichtig für stateful/cached Skripte).
• Schatten-/Verkehrsspiegel (wir spiegeln Anfragen in die neue Version „heimlich“).

8) Tools und Implementierungen (Beispiele)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
CD-Plattformen: Spinnaker, Argo CD, GitHub Actions + Progressive Delivery Plugins, GitLab/CD.

9) Beobachtbarkeit, SLI/SLO und Gates

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Geschäftsmetriken: Konversion, Autorisierungen, Zahlungen/Erfolge, Durchschnittsscheck, Ablehnung durch Trichterschritte.

• Fehlerschwelle (z. B. error rate canary ≤ baseline + X%).
• Die Latenz von p95 ist nicht schlechter als baseline für mehr als Δ.
• Geschäftsschwelle (z.B. Conversion-Rückgang
• Das Error Budget per SLO darf nicht beschleunigt ausbrennen.

Schrittdauer: Mindestzeit, die für die statistische Signifikanz ausreicht (abhängig vom Verkehr).

10) DB-Migrationen und Interoperabilität der Systeme

Die Hauptregel: Releases sind sicher, wenn die Back- und Forward-Versionen kompatibel sind.

1. Expand: Fügen Sie neue Spalten/Indizes/Tabellen hinzu, ohne die alte Version zu brechen.

2. Deploy app vNext (liest/schreibt in ein neues Schema, kann aber auch mit dem alten arbeiten).

3. Migrationsdaten (Hintergrund/Batch, idempotent, mit Checkpoints).

4. Vertrag: Wir entfernen alte Felder/Felder nach der Stabilisierung.

Anti-Muster: Migrationen, die zum Zeitpunkt des Blau-Grün-Wechsels eine exklusive Sperrung erfordern; Unmöglichkeit des Herunterladens des Schemas; „double write“ ohne Deduplizierung.

11) Rollback und Unfallpläne

Blau-Grün: sofortiger Flip auf Blau; Wir überwachen die „Schwänze“ der Green-Hintergrundjobs.
Canary: Gewichtsrückschlag (z.B. von 25% nach hinten um 5% oder 0%); automatischer Abort bei Alerts.
Daten: durchdachte Politik der Wiederholung/Kompensation (idempotency keys, „inbox/outbox“ Muster, Deduplizierung von Nachrichten).
Ficheflagi: schneller Kill-Switch zum Abschalten von teilweise ausgerollten Möglichkeiten.

12) Arbeiten mit State und Sessions

Sticky-Sessions für Kanarienvögel oder Speichern von Sessions extern (Redis/Memcached), so dass die Versionen austauschbar sind.
Cache im Voraus aufwärmen (Green warm-up) und Invalidation beim Flippen berücksichtigen.
Hintergrund-Worker: Lassen Sie keine „Rennen“ zwischen den Versionen zu - Warteschlangen trennen oder laut Version „führen“.

13) Sicherheit und Compliance

Zugang zu Green/Canary - durch Zero Trust: Servicekonten, minimal erforderliche Rollen.
Geheimnisse und Schlüssel - über KMS/Secrets Manager; Schalten Sie die Rotation ein.
Verkehr - nur TLS; endpoint's Versionen sind deutlich gekennzeichnet; Überwachung von Routing- und Release-Aktivitäten.

14) Kosten und Leistung

Blue-Green verdoppelt die Infrastruktur (zum Zeitpunkt der Veröffentlichung oder dauerhaft) - legen Sie ein Budget fest.
Canary ist sparsamer, erfordert jedoch Überwachungstools und Engineering-Zeit für die Automatisierung.
Optimierung: Auto-Scaling, ephemerale Umgebung, Verkürzung des Fensters der parallelen Existenz von Versionen.

15) Checklisten

Vor der Veröffentlichung

• Image/Bild aus einer Hand gefördert, Signaturen geprüft.
• Testplan, Alerts und SLO-Gates konfiguriert.
• DB-Migrationen - im Expand-Modus, Downgrade-Pläne verfügbar.
• Rollback-Plan - geprüft in staging/production-like.

Während der Veröffentlichung

• Metriken und Protokolle werden mit baseline verglichen.
• Für Canary - Schritte und Schwellenwerte festgelegt; für Blau-Grün - Flip-Back-Bereitschaft.
• On-Call-Befehle sind auf dem neuesten Stand, es gibt ein Feedback-Fenster.

Nach der Veröffentlichung

• SLO ist nicht gesunken, error budget ist normal.
• Post-Release-Migrationen/Bereinigungen abgeschlossen.
• Retrospektive und Aktualisierung der Playbooks.

16) Häufige Fehler und Anti-Muster

Roll-out ohne Metriken: keine Daten - keine überschaubare Lösung.
Mischung inkompatibler OBD-Schaltungen, keine Downgrade-Strategie.
Zufälliges Mischen des Verkehrs: Es gibt keine Stickiness, Benutzer „springen“ zwischen den Versionen.
Versteckte stateful-Abhängigkeiten (lokale Laufwerke, In-Memory-Caches).
Eine lange DNS-TTL verhindert einen schnellen Flip (Blau-Grün).
Fehlende Auto-Gates: Manuelle „On-the-Eye“ -Lösungen bremsen und erhöhen die Risiken.

17) Kombinierte Ansätze

Blue-Green + Canary: Rollen Sie zuerst Green aus, dann rollen Sie innerhalb von Green Canary für einzelne Dienste aus.
Schatten-/Wanderungsverkehr: Vor Canary fahren wir Spiegelverkehr in die neue Version.
Feature Flags (progressive Lieferung): Die Funktionalität wird über eine stabile Version mit „dunklen“ Flaggen nach Segmenten aktiviert.

18) Beispielszenarien (Skizzen)

1. Wir entfalten Grün (v2) hinter dem neuen Listener/Ingress.

2. Wir wärmen die Caches auf, führen Readonly-Checks durch, Rauch.

3. Wir schalten das Gewicht auf Grün = 100%.

4. Wir beobachten SLO 30-60 Minuten; Wenn alles in Ordnung ist, schalten wir Blue aus.

1. Deploy canary vNext (Repliken 5%).

2. Wir ermöglichen 5% Traffic für interne Konten/Testsegment.

3. AutoGate: error rate ≤ baseline + 0 3%, p95 ≤ +20ms.

4. Heben Sie 10% → 25% → 50% alle N Minuten, wenn Sie die Tore passieren.

5. Wir übersetzen Ficheflag zu 100% in alle Segmente; Wir löschen die alte Version.

19) Variationen für verschiedene Architekturen

Monolith: Blau-Grün ist einfacher, Canary ist schwieriger wegen der Unteilbarkeit von fich; Verwenden Sie Ficheflags.
Microservices: Canary ist natürlich; Achten Sie auf serviceübergreifende Verträge (Consumer-Driven Contracts).
Stateful Services: Bevorzugen Sie Blue-Green mit aufwendigen Migrationen und Stickiness.

20) Kurzer Vergleich (Zusammenfassung)

Rollback-Geschwindigkeit: Blau-Grün = sofort; Canary = schnell, aber mit Gewichtsrückschlag.
Infrastrukturkosten: Blue-Green ↑; Canary ↔︎/↓.
Risiko für Nutzer: Canary ist geringer (wir kontrollieren den Anteil).
Komplexität der Implementierung: Blau-Grün ist einfacher zu starten; Canary erfordert eine starke Überwachung und Automatisierung.
Daten-/Schaltungskompatibilität: kritisch für beide; expand-migrate-contract planen.

21) Das Ergebnis

Blue-Green und Canary sind keine sich gegenseitig ausschließenden Strategien, sondern Elemente einer progressiven Lieferung. Die Auswahl hängt von den Kostenbeschränkungen, der Reife der Beobachtbarkeit und der Art der Veränderung ab. Unabhängig vom Ansatz ruht eine nachhaltige Freigabe auf vier Säulen: Automatisierung, Beobachtbarkeit, Abwärtskompatibilität und schnelles Rollback.