DevOps

Zero-Downtime-Deployment

Zero-Downtime-Deployment ist eine Deployment-Strategie, bei der Software-Updates ohne Unterbrechung des laufenden Betriebs eingespielt werden – Nutzer bemerken vom Update nichts.

Wartungsfenster um 3 Uhr nachts, Hinweise auf geplante Ausfallzeiten, Nutzer, die ins Leere klicken – das war einmal. Moderne Webanwendungen werden ohne spürbare Unterbrechung aktualisiert. Zero-Downtime-Deployment macht es möglich: Die neue Version wird parallel zur alten gestartet, Traffic wird schrittweise umgeleitet, und bei Problemen wird sofort zurückgerollt. Für geschäftskritische Anwendungen ist diese Praxis unverzichtbar.

Was ist Zero-Downtime-Deployment?

Zero-Downtime-Deployment (auch: No-Downtime-Deployment) bezeichnet Deployment-Strategien, die sicherstellen, dass eine Anwendung während eines Software-Updates ununterbrochen verfügbar bleibt. Es gibt verschiedene Ansätze: Blue-Green-Deployment (zwei identische Umgebungen, Traffic wird umgeschaltet), Rolling-Deployment (Instanzen werden nacheinander aktualisiert), Canary-Deployment (neue Version wird zunächst nur für einen kleinen Teil der Nutzer freigeschaltet) und Feature-Flags (neue Funktionen werden im Code aktiviert/deaktiviert, ohne neues Deployment). Voraussetzung ist eine Architektur, die mehrere Instanzen und Backward-Compatible-Datenbank-Migrationen unterstützt.

Wie funktioniert Zero-Downtime-Deployment?

Am Beispiel Blue-Green-Deployment: Zwei identische Produktionsumgebungen (Blue und Green) laufen parallel. Die aktuelle Version läuft auf Blue und empfängt den Live-Traffic. Die neue Version wird auf Green deployt und dort getestet. Wenn alle Tests bestehen, schaltet der Load Balancer den Traffic von Blue auf Green um – in Sekundenbruchteilen. Bei Problemen wird sofort zurück auf Blue geschaltet (Instant Rollback). Beim Rolling-Deployment werden Instanzen nacheinander aktualisiert: Während eine Instanz aktualisiert wird, bearbeiten die übrigen den Traffic. Canary-Deployments leiten zunächst nur 5-10% des Traffics auf die neue Version, überwachen Metriken und erhöhen den Anteil schrittweise.

Praxisbeispiele

Ein Online-Shop deployt täglich neue Features per Blue-Green-Deployment: Kunden bemerken nichts vom Update, und bei einem Fehler ist der Rollback in unter 30 Sekunden erledigt.

Ein SaaS-Anbieter nutzt Canary-Deployments: Neue Features werden zunächst für 5% der Nutzer freigeschaltet. Wenn Error-Rates und Performance stimmen, wird auf 100% erhöht.

Ein Kubernetes-Cluster führt Rolling-Updates durch: Pods werden nacheinander aktualisiert, wobei Health-Checks sicherstellen, dass nur gesunde Pods Traffic empfangen.

Ein Banking-Portal nutzt Feature-Flags: Die neue Überweisungsfunktion ist bereits deployed, aber per Flag deaktiviert. Nach UAT-Freigabe wird sie per Flag-Änderung live geschaltet – ohne Deployment.

Typische Anwendungsfälle

E-Commerce: Online-Shops können es sich nicht leisten, während Geschäftszeiten offline zu sein – Umsatzverlust pro Minute Downtime

SaaS-Plattformen: Globale Nutzer in verschiedenen Zeitzonen erwarten 24/7-Verfügbarkeit

Finanzdienstleister: Regulatorische Anforderungen an Verfügbarkeit und schnelle Rollback-Fähigkeit

Continuous Delivery: Teams, die täglich oder mehrfach täglich deployen, benötigen unterbrechungsfreie Strategien

Microservices-Architekturen: Einzelne Services werden unabhängig aktualisiert, ohne das Gesamtsystem zu beeinträchtigen

Vorteile und Nachteile

Vorteile

Keine Ausfallzeit: Nutzer bemerken vom Deployment nichts – das System ist durchgängig verfügbar
Instant Rollback: Bei Problemen wird in Sekunden auf die vorherige Version zurückgeschaltet
Höhere Deployment-Frequenz: Wenn Deployments risikoarm sind, kann das Team häufiger releasen
Bessere Nutzererfahrung: Keine Wartungsfenster, keine Downtime-Hinweise, keine verlorenen Sessions
Reduziertes Risiko: Canary-Deployments identifizieren Probleme früh, bevor alle Nutzer betroffen sind

Nachteile

Infrastruktur-Komplexität: Blue-Green erfordert doppelte Infrastruktur, Canary braucht intelligentes Traffic-Routing
Datenbank-Migrationen: Schema-Änderungen müssen backward-compatible sein – das erfordert sorgfältige Planung
Monitoring-Aufwand: Automatische Rollbacks erfordern robustes Monitoring mit definierten Health-Checks
Kosten: Zusätzliche Infrastruktur (Blue-Green) oder komplexere Pipeline-Konfiguration erhöhen die Betriebskosten

Häufig gestellte Fragen zu Zero-Downtime-Deployment

Welche Deployment-Strategie ist die beste?

Das hängt vom Kontext ab. Blue-Green ist am einfachsten für Rollbacks, erfordert aber doppelte Infrastruktur. Rolling-Deployment ist ressourceneffizient, aber Rollbacks sind langsamer. Canary-Deployment bietet das beste Risikomanagement, ist aber am komplexesten. Für die meisten Teams ist Blue-Green ein guter Einstieg, mit späterem Upgrade auf Canary.

Wie geht man mit Datenbank-Migrationen bei Zero-Downtime um?

Datenbank-Änderungen müssen backward-compatible sein: Spalten hinzufügen (nicht umbenennen oder löschen), neue Tabellen erstellen, Views als Abstraktionsschicht nutzen. Destructive Änderungen (Spalten löschen) erfolgen erst in einem späteren Deployment, wenn die alte Version nicht mehr läuft. Dieses Expand-Contract-Pattern erfordert Disziplin, ist aber der Schlüssel zu Zero-Downtime-Migrationen.

Braucht man Kubernetes für Zero-Downtime-Deployment?

Nein, Kubernetes erleichtert es durch eingebaute Rolling-Updates und Health-Checks, ist aber keine Voraussetzung. Blue-Green-Deployments lassen sich auch mit einem einfachen Load Balancer und zwei Servern umsetzen. Plattformen wie AWS Elastic Beanstalk, Heroku und Vercel bieten Zero-Downtime-Deployments als integrierten Service.

Unterbrechungsfreie Deployments einrichten?

Wir beraten Sie gerne zu Zero-Downtime-Deployment und finden die optimale Lösung für Ihre Anforderungen. Profitieren Sie von unserer Erfahrung aus über 200 Projekten.

CI/CD-Pipeline aufbauen Kostenlos beraten lassen

Zurück zum IT-Glossar