Deployments ohne Ausfallzeit, Schritt für Schritt

Jedes Deployment war früher von einem kleinen Ritual der Angst begleitet. Jemand wählte eine ruhige Stunde, veröffentlichte ein Wartungsbanner, drückte die Daumen und schob den Code aus. Die Nutzer sahen einen Ladeindikator oder einen Fehler, und das Team hielt den Atem an, bis die Health Checks wieder auf Grün sprangen. Dieses Modell ist ein Relikt. Im Jahr 2026 erwarten Ihre Kunden eine Anwendung, die schlicht immer verfügbar ist, und die gute Nachricht ist: Deployment im laufenden Betrieb ist ein gelöstes Problem, sofern Sie es bewusst dafür bauen.

Deployment ohne Ausfallzeit bedeutet, dass Sie neuen Code ausliefern können, während Anfragen weiter fließen, ohne Wartungsfenster und ohne abgebrochene Verbindungen. Es geht weniger um ein einzelnes cleveres Werkzeug als um eine Reihe von Gewohnheiten: den laufenden Traffic nie unterbrechen, immer einen schnellen Rückweg bereithalten und die Datenbank mit Respekt behandeln. Dieser Leitfaden geht die Strategien durch, die schwierigen Teile (Datenbanken, Sessions, Health Checks) und eine Checkliste, die Sie bei Ihrem nächsten Release einsetzen können.

Was "ohne Ausfallzeit" tatsächlich verlangt

Bevor Sie eine Strategie wählen, hilft es, die drei Eigenschaften zu benennen, von denen jeder sichere Rollout abhängt. Vernachlässigen Sie auch nur eine davon, und die ausgefeilteste Deployment-Pipeline wird trotzdem Anfragen verlieren.

• Abwärtskompatibilität. Während eines Rollouts laufen die alte und die neue Version Ihres Codes gleichzeitig. Die neue Version muss die von der alten geschriebenen Daten vertragen, und die alte muss neben der neuen bestehen. Wenn ein Release erst funktioniert, sobald alles umgestellt ist, haben Sie keine Ausfallfreiheit, sondern ein schnelles Wartungsfenster.
• Sauberes Herunterfahren. Wenn Sie eine alte Instanz außer Betrieb nehmen, muss sie aufhören, neue Anfragen anzunehmen, die bereits laufenden abschließen und dann beenden. Eine Instanz, die mitten in einer Anfrage abgeschossen wird, liefert Ihrem Nutzer eine kaputte Antwort, egal wie elegant der Rest Ihrer Pipeline ist.
• Ehrliche Health Checks. Ihr Load Balancer braucht ein verlässliches Signal für "diese Instanz ist bereit zu bedienen" und "diese Instanz fällt aus". Schwache Health Checks sind der mit Abstand häufigste Grund dafür, dass ein technisch korrektes Deployment trotzdem einen Ausfall verursacht.

Bringen Sie diese drei Dinge in Ordnung, und die Deployment-Strategie wird fast zur Formsache.

Die grundlegenden Strategien

Rolling-Deployments

Ein Rolling-Deployment ersetzt Instanzen in kleinen Gruppen. Sie nehmen eine oder zwei alte Instanzen herunter, starten dieselbe Anzahl neuer hoch, warten, bis sie die Health Checks bestehen, und wiederholen das, bis die gesamte Flotte aktualisiert ist. Es ist die Standardeinstellung in Kubernetes und den meisten Container-Plattformen, weil es keine zusätzliche Infrastruktur braucht: Sie nutzen dieselbe Kapazität wieder und wechseln sie lediglich durch.

Der Kompromiss besteht darin, dass beide Versionen während des gesamten Rollouts Live-Traffic bedienen, manchmal über mehrere Minuten. Das macht Abwärtskompatibilität unverhandelbar. Rolling-Updates passen hervorragend zu zustandslosen Diensten mit sauberen, kompatiblen APIs und schlecht zu Fällen, in denen eine Änderung nicht gefahrlos mit der Vorgängerversion koexistieren kann.

Blue-Green-Deployments

Blue-Green hält zwei identische Produktionsumgebungen vor. Das "Blue" bedient den gesamten Traffic, während Sie das neue Release in die untätige "Green"-Umgebung deployen. Sie führen einen Smoke-Test an Green in Isolation durch und schalten dann den Router um, sodass jede Anfrage in einem einzigen sauberen Wechsel an Green geht. Blue bleibt warm und unberührt, sodass Sie in Sekunden zurückschalten können, falls etwas nicht stimmt.

Die Stärken sind ein nahezu sofortiger Umschaltvorgang und ein sofortiger Rollback-Pfad. Der Preis ist, dass Sie während des Releases die doppelte Infrastruktur betreiben, und Sie müssen Datenbankänderungen dennoch sorgfältig planen, weil sich beide Umgebungen in der Regel einen Datenspeicher teilen. Blue-Green glänzt bei Releases, bei denen Sie einen entschiedenen, umkehrbaren Wechsel wollen und die zusätzliche Kapazität für ein kurzes Fenster verkraften können.

Canary-Deployments

Ein Canary-Release leitet einen kleinen Teil des Traffics, sagen wir 5 Prozent, an die neue Version, während alle anderen auf der alten bleiben. Sie beobachten Fehlerraten, Latenz und Geschäftskennzahlen auf diesem Teil. Halten die Zahlen stand, weiten Sie auf 25, dann 50 und schließlich 100 Prozent aus. Verschlechtern sie sich, leiten Sie den Teil zurück, und fast niemand hat es bemerkt.

Canary ist die sicherste Option für Änderungen mit hohem Einsatz, weil es den Wirkungsradius eines schlechten Releases auf einen Bruchteil der Nutzer begrenzt. Es verlangt Ihnen zugleich am meisten ab: Observability in Echtzeit, Metriken pro Version und idealerweise automatisierte Promotion-Regeln, die um Mitternacht vorrücken oder zurückrollen, ohne dass ein Mensch auf ein Dashboard starrt. Hier treffen Deployment-Strategie und gute Observability-Praktiken aufeinander.

Der schwierige Teil ist fast immer die Datenbank

Anwendungscode lässt sich leicht in zwei Versionen gleichzeitig betreiben. Schemata nicht, denn es gibt nur eine Datenbank, und beide Versionen lesen und schreiben sie live. Die Technik, die dies sicher macht, ist das Expand-and-Contract-Muster, und es lohnt sich, es zu verinnerlichen.

Angenommen, Sie möchten eine Spalte von full_name in display_name umbenennen. Dies in einer einzigen Migration zu tun würde den alten Code in dem Moment brechen, in dem sie ausgeführt wird. Stattdessen verteilen Sie die Änderung über mehrere Releases:

1. Expand. Fügen Sie die neue Spalte display_name hinzu, ohne die alte zu entfernen. Deployen Sie Code, der in beide Spalten schreibt und aus der alten liest. Nichts bricht, weil die alte Struktur intakt bleibt.
2. Migrate. Befüllen Sie display_name für bestehende Zeilen aus full_name, in Stapeln, damit Sie die Tabelle nicht sperren.
3. Transition. Deployen Sie eine Version, die aus der neuen Spalte liest, während sie weiterhin in beide schreibt, und überprüfen Sie sie in der Produktion.
4. Contract. Sobald kein laufender Code mehr von full_name abhängt, deployen Sie ein Release, das die alte Spalte entfernt und aufhört, in sie zu schreiben.

Es erfordert mehr Releases, aber jeder einzelne Schritt ist abwärtskompatibel, sodass der Traffic nie abbricht. Dieselbe Disziplin gilt für Indizes (bauen Sie sie nebenläufig auf, damit Sie Schreibvorgänge nicht sperren) und für jede Änderung, die etwas entfernt oder umbenennt. Die Faustregel: Additive Änderungen sind sicher, destruktive Änderungen müssen warten, bis nichts mehr von der alten Struktur abhängt. Genau diese Art von Vertragsdenken behandeln wir in unserem Leitfaden zum Entwerfen von APIs, die Entwickler lieben, und es ist derselbe Reflex, angewandt auf Ihre Datenschicht.

Sessions, Verbindungen und sauberes Herunterfahren

Zwei weitere Details trennen einen reibungslosen Rollout von einem holprigen.

Erstens: Binden Sie den Nutzerzustand nicht an eine bestimmte Instanz. Liegen Sessions im Speicher eines einzigen Servers, meldet das Außerbetriebnehmen dieses Servers jene Nutzer ab. Halten Sie den Session-Zustand in einem gemeinsam genutzten Speicher wie Redis, oder verwenden Sie zustandslose Tokens, damit jede Instanz jeden Nutzer bedienen kann und das Ausrollen einer Instanz unsichtbar wird.

Zweitens: Leeren Sie Verbindungen ordnungsgemäß. Wenn einer Instanz das Herunterfahren angewiesen wird, sollte sie ihren Readiness-Check sofort scheitern lassen, damit der Load Balancer aufhört, ihr neue Anfragen zu schicken, die laufenden bis zum Abschluss weiter bedienen und erst dann beenden. In Kubernetes ist das der preStop-Hook plus ein sinnvoller Wert für terminationGracePeriodSeconds. Ohne ihn verlieren Sie genau die Anfragen, die im Flug waren, als der alte Pod starb, und diese Fehler sind zum Verrücktwerden schwer zu reproduzieren, weil sie nur während Deployments auftreten.

Feature Flags entkoppeln Deployment von Release

Eine der wirkungsvollsten Gewohnheiten in der modernen Auslieferung ist, das Deployen von Code vom Freischalten einer Funktion zu trennen. Liefern Sie den neuen Code im Dark-Modus aus, umhüllt von einem Feature Flag, das in der Produktion ausgeschaltet ist. Der Code ist live, wird von Ihrer Infrastruktur ausgeübt, bleibt aber für die Nutzer unsichtbar. Wenn Sie bereit sind, schalten Sie das Flag um, um die Funktion zu aktivieren, und falls sie sich fehlverhält, schalten Sie es ohne erneutes Deployment wieder zurück.

Das verwandelt ein beängstigendes Release in zwei risikoarme Ereignisse. Es harmoniert außerdem hervorragend mit der Canary-Logik: Aktivieren Sie das Flag zuerst für interne Nutzer, dann für 1 Prozent der Kunden, dann für alle. Die Deployment-Pipeline bringt den Code sicher heraus, und das Flag steuert die Sichtbarkeit nach Ihrem eigenen Zeitplan.

Ihre Checkliste für Deployments ohne Ausfallzeit

Verwenden Sie sie vor und während eines Releases. Sie erfasst die Absicherungen, die am wichtigsten sind.

1. Bestätigen Sie die Abwärtskompatibilität. Prüfen Sie, dass die neue Version Daten und API-Aufrufe der alten verträgt und umgekehrt.
2. Teilen Sie riskante Schemaänderungen auf. Wenden Sie das Expand-and-Contract-Muster an, damit jeder Migrationsschritt additiv und umkehrbar ist.
3. Lagern Sie den Zustand aus. Stellen Sie sicher, dass Sessions und Caches in einem gemeinsam genutzten Speicher leben, nicht im Instanzspeicher.
4. Verdrahten Sie echte Health Checks. Trennen Sie Readiness (bereit für Traffic) von Liveness (noch am Leben), damit der Load Balancer korrekt routet.
5. Aktivieren Sie sauberes Herunterfahren. Konfigurieren Sie das Leeren von Verbindungen und eine Herunterfahr-Gnadenfrist, die lang genug ist, um laufende Anfragen abzuschließen.
6. Wählen Sie die Strategie je nach Änderung. Rolling für routinemäßige zustandslose Updates, Blue-Green für entschiedene, umkehrbare Wechsel, Canary für Änderungen mit hohem Einsatz.
7. Deployen Sie hinter einem Flag. Liefern Sie im Dark-Modus aus und steuern Sie die Sichtbarkeit getrennt vom Deployment.
8. Beobachten Sie die richtigen Metriken. Verfolgen Sie Fehlerrate, Latenz und eine zentrale Geschäftskennzahl pro Version während und nach dem Rollout.
9. Proben Sie den Rollback. Kennen Sie den genauen Befehl oder Schalter zum Zurücksetzen und bestätigen Sie, dass er funktioniert, bevor Sie ihn unter Druck brauchen.
10. Automatisieren Sie die Pipeline. Verankern Sie diese Kontrollpunkte in der CI/CD, damit der sichere Weg der einzige Weg ist und nicht eine Checkliste, die jemand überspringen könnte.

Dieser letzte Punkt ist der Unterschied zwischen einmal tun und jeden Tag tun. Nach unserer Erfahrung liefern Teams, die Promotion und Rollback automatisieren, weitaus häufiger mit weitaus weniger Zwischenfällen aus, weil die Disziplin in der Pipeline lebt statt im Gedächtnis von jemandem um 2 Uhr morgens.

Wie Innovation T helfen kann

Deployment ohne Ausfallzeit ist eine Fähigkeit, die Sie aufbauen, kein Schalter, den Sie umlegen. Es berührt Ihre Architektur, Ihre Datenbankgewohnheiten, Ihre CI/CD-Pipeline und Ihren Observability-Stack, und die Teile müssen zusammenpassen. Genau diese Art von Arbeit leistet unser Team jede Woche.

Bei Innovation T helfen wir Teams, Deployment-Pipelines zu entwerfen, die sicher und häufig ausliefern: Blue-Green- und Canary-Rollouts, Expand-and-Contract-Migrationsstrategien, Feature-Flag-Infrastruktur sowie die Health Checks und das Monitoring, die das Ganze vertrauenswürdig machen. Falls Ihre Dienste noch eng gekoppelt sind, zeigt unser Leitfaden zum Umstieg von einem Monolithen auf Microservices die Grundlagen, die unabhängige Releases ohne Ausfallzeit überhaupt erst möglich machen.

Wenn ein Deployment für Sie noch eine Wartungsseite oder angehaltenen Atem bedeutet, lassen Sie uns das ändern. Entdecken Sie unsere Leistungen oder nehmen Sie Kontakt auf, und wir helfen Ihnen, einen Release-Prozess aufzubauen, den Ihre Nutzer nie bemerken.