Zero-Downtime-Bereitstellung

(Abschnitt: Architektur und Protokolle)

1) Was ist Zero-Downtime und warum ist es notwendig

• Null Ausfallzeiten für Kunden und Integrationen.
• Vorhersehbare Releases, schnelles Rollback und überschaubares Risiko.
• Halten Sie SLO/SLI (Latenz, Fehler, Verfügbarkeit) innerhalb der Grenzen der Vereinbarungen.

Der Schlüssel zu ZDT ist nicht eine „magische“ Technik, sondern eine Kombination aus Liefermustern, Datenkompatibilität und kompetentem Traffic-Routing.

2) Grundprinzipien von Zero-Downtime

1. Versionskompatibilität: Die neue und die alte Version müssen Verkehr und Daten gleichzeitig korrekt verarbeiten.
2. Idempotenz von Operationen: Die wiederholte Verarbeitung sollte den Zustand nicht brechen.
3. Anmutige Fertigstellung (graceful shutdown) und Entwässerung der Anschlüsse.
4. Schritt-für-Schritt-Gesundheitscheck: Readiness/Liveness-Test, Health-Endpoints.
5. Rollback als erstklassiger Bürger: Rollback ist einfacher und schneller als Hotfix.
6. Beobachtbarkeit durch Design: Release-Tags, einheitliche Dashboards, Alerts durch SLO.
7. Automatisierung: Release und Rollback Skripte - Code, nicht manuelle Anweisungen.

3) Liefermuster ohne Downtime

3. 1 Rolling Update

Nach und nach entfernen wir einige der Instanzen der alten Version aus dem Verkehr, aktualisieren sie auf die neue und kehren zum Pool zurück.

Vorteile: sparsam in der Infrastruktur, nur in der k8s/ASG.
Nachteile: Der Cluster arbeitet seit einiger Zeit mit zwei Versionen gleichzeitig (Version Skew).

3. 2 Blue-Green

Zwei komplette Prod-Stacks: aktiv (Blau) und Kandidat (Grün). Die Verkehrsumschaltung ist ein atomarer Flip.

Vorteile: sofortiges Rollback, saubere Isolierung.
Nachteile: ↑ Infrastrukturkosten, schwieriger mit stateful.

3. 3 Kanarische/Progressive Rollout

Wir geben einen kleinen Teil des Verkehrs (1-5-10-25-50-100%) der neuen Version mit Gates für Metriken.

Vorteile: minimaler Blast-Radius, datengetriebene Lösungen.
Nachteile: Sie benötigen eine reife Beobachtbarkeit und intelligentes Routing.

3. 4 Shadow traffic / Dark launch

Spiegeln Sie reale Anfragen in eine neue Version (ohne Antwort an den Benutzer) oder führen Sie sie versteckt aus, um Metriken zu sammeln.

Vorteile: Früherkennung von Problemen.
Nachteile: Doppelbelastung von Abhängigkeiten, Kontrolle von Nebenwirkungen erforderlich.

4) Verkehrs- und Verbindungsmanagement

4. 1 Readiness/Liveness

Liveness sagt dem Orchestrator, er solle „mich neu starten“.
Bereitschaft - „Lenke den Verkehr nicht, ich bin noch nicht bereit“.
Sie können nicht ohne korrekte Readiness-Logik und Timeouts freigeben.

4. 2 Verbindungsdrainage

• Wir hören auf, neue Verbindungen zu akzeptieren,
• warten auf den Abschluss der aktiven,
• Wir unterbrechen die „Schwebenden“ im Timeout.

4. 3 Sticky Sessions und L7 Level Routing

Sticky ist in stateful-Szenarien nützlich, erschwert aber die Lastbalance.
Die L7-Regeln (per Pfad, Header, Cook, API-Versionen) sind canary/ring-freundlich.

4. 4 Langlebige Verbindungen

WebSocket/gRPC-Streaming: Vor dem Update Drain-Modus + Signal „GOAWAY“ einschalten.
Planen Sie Windows, um die Streams und Backoff-Retrays der Kunden aufzuwiegen.

5) Datenkompatibilität und DB-Migration

5. 1 Expand-Migrate-Contract

1. Expand: Fügen Sie neue Spalten/Indizes/Tabellen hinzu, ohne die alte Version zu brechen.
2. Migration: Wir übertragen Daten hintergrund- und idempotent (Batchi, Checkpoints).
3. Vertrag: Altes löschen wir erst nach Stabilisierung.

5. 2 Praktiken

Vermeiden Sie exklusive DDL-Locks im Release-Fenster.
Versionieren Sie API/Event-Verträge (Schema Registry, CDC).
Für schwere Migrationen - Online-Tools, Replikate, Phasenwechsel.
Dual-Write nur mit Deduplizierung und idempotenten Verbrauchern.
Outbox/Inbox für zuverlässige Integration über Warteschlangen.

6) Caches, Sessions und Hintergrundaufgaben

Sitzungen und Cache sind extern (Redis/Memcached), sodass die Versionen austauschbar sind.
Cache/Jits/Temp-Indizes aufwärmen, bevor sie in den Pool aufgenommen werden.
Teilen Sie die Hintergrundwarteschlangen nach Version auf oder verwenden Sie die Führung, um Rennen zu vermeiden.

7) Beobachtbarkeit und Tore durch SLO

Goldene Signale: p95/p99 Latenz, Fehlerrate, RPS, Sättigung, Warteschlangen-Lag.
Business SLA: Autorisierungen, Konvertierungen, erfolgreiche Zahlungen, Ablehnung durch Trichterschritte.
Gates: Rollout kommt nur voran, wenn canary ≤ baseline + Degradationsschwellen und error budget nicht verbrennt.

8) Sichere Fertigstellung und Rollback

Der Rollback ist die gleiche Pipeline, nur in die entgegengesetzte Richtung: feste Befehle, kein „Handcraft“.
Für blau-grün - flip back; für canary - Gewichtsabnahme auf 0% oder den vorherigen stabilen Schritt.
Daten: Kompensationstransaktionen, Neuverarbeitung, Deduplizierung von Ereignissen.

9) Zero-Downtime Checklisten

Vor der Veröffentlichung

• Ein signiertes Artefakt (immutable), ein SBOM und eine Abhängigkeitsprüfung wurden gesammelt.
• Readiness/liveness implementiert und getestet.
• Migrationsplan im Expand-Modus, Reversibilität bestätigt.
• Dashboards und Alerts für die neue Version sind fertig, Release-Tags sind verfilzt.
• Rollback auf staging/pre-prod überprüft.

Während der Veröffentlichung

• Die Entwässerung der Anschlüsse ist eingeschaltet, die Timeouts sind ausreichend.
• Der Verkehr wird schrittweise (canary/ring) oder flip (blue-green) übersetzt.
• Die Metriken werden mit der Baseline verglichen, die Gate-Schwellenwerte werden eingehalten.

Nach der Veröffentlichung

• Nachüberwachung N Stunden, keine Vorfälle.
• Vertragsmigrationen abgeschlossen, temporäre Flaggen/Routen entfernt.
• Retrospektive, Aktualisierung der Playbooks.

10) Anti-Muster

Recreate-deploy ohne drainage und readiness ⇒ clips von Anfragen.
Untrainierte DDL ⇒ Sperren und Timeouts in der Primetime.
Inkompatible Schemata zwischen Service-Versionen mischen.
Keine Idempotenz bei Handlern und Workern.
„Roll-out nach Gefühl“ ohne Tore und Vergleich mit Baseline.
Lange DNS-TTL bei blau-grün, weshalb der Flip stundenlang dauert.
Lokale Sitzungen/Cache im Instance-Speicher bei Rolling/Canary.

11) Implementierungsszenarien

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readiness wartet auf das Aufwärmen (Cache-Initialisierung, Minor-Migration).
Service-Mesh/Ingress mit gewichtetem Routing (1-5-10-25-50-100%).
Alerts: p95, 5xx, Warteschlangen-Lag, Business-Trichter.

11. 2 Blau-Grün in der Cloud

Zwei Stapel hinter dem Balancer: 'blau. example. com` и `green. example. com`.
Aufwärmen grün, Rauch/Regression, dann listener/route swap (oder DNS-Switch mit niedriger TTL).
Bei Problemen - sofortiger Flip zurück.

11. 3 Stateful-Service

Datenreplikationen + Online-Migrationen; Doppelte Lesung mit Validierung.
Hintergrund-Jobs werden durch die „Führung“ der Version oder geteilte Warteschlangen übertragen.
Sitzungen/Cache außerhalb der Instance; sticky ist nur vorübergehend aktiviert.

12) Ficheflags und Client-Anwendungen

Neue Fiches werden durch Flags aktiviert (Segmente: Mitarbeiter → Beta → alle).
Berücksichtigen Sie für mobile/Desktop-Clients die Grenzen der Protokollkompatibilität und die Überlebensfähigkeit älterer Versionen (Deprecationspolitik, Server-Side-Fallback).

13) Leistung und Kosten

Rolling ist billiger, erfordert aber eine sorgfältige Kompatibilität.
Blau-Grün ist zum Zeitpunkt der Veröffentlichung teurer, aber der Rollback ist sofort.
Canary gleicht Risiken und Kosten aus, erfordert jedoch eine starke Beobachtbarkeit.
Sparen Sie durch ephemeral-Preview und Auto-Standreinigung.

14) Mindestreferenz-Pipeline ZDT

1. Build: einzelnes Artefakt, Signatur, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: Rauch, Last, Migrationen im Expand-Modus, Rollback-Prüfung.
4. Prod: Schatten → Canary (Tore) oder blau-grüner Flip.
5. Post-deploy: Beobachtung, Vertragsreinigung, retro.

15) Kurze Zusammenfassung

Zero-Downtime ist eine Disziplin: kompatible Versionen + korrektes Routing + verwaltete Migrationen + Beobachtbarkeit und schnelles Rollback. Wählen Sie ein Muster für den Kontext (Rolling, Blue-Green, Canary), automatisieren Sie die Gates per SLO, halten Sie die Daten idempotent - und Releases sind kein Event mehr, sondern werden zu einem robusten Routineprozess.