Die Deployment-Strategie bestimmt, wie schwer die Wiederherstellung wird

Die meisten Teams kümmern sich erst um die Wiederherstellung, wenn etwas kaputtgeht. Sie schreiben ein Rollback-Skript, heben ein Backup des alten Artefakts auf und hoffen, dass sie es nie brauchen. Aber die Wahrheit ist: Der schwierigste Teil der Wiederherstellung ist nicht das Rollback selbst. Es ist die Situation, in der du steckst, wenn du erkennst, dass du wegen der ursprünglichen Deployment-Methode kein sauberes Rollback durchführen kannst.

Stell dir folgendes Szenario vor. Dein Team bringt eine neue Version in die Produktion. Alle Server werden auf einmal ersetzt. Die alte Version geht runter, die neue kommt hoch, jeder Nutzer ist jetzt auf dem neuen Code. Dann schlagen die Monitoring-Alarme an. Etwas stimmt nicht. Deine einzige Option ist ein vollständiges Rollback. Jeder Server, jeder Nutzer, jede Verbindung. Es gibt keine Mitte. Du bist entweder komplett auf der kaputten Version oder komplett auf der alten. Und während du das Rollback durchführst, hat jeder Nutzer das Problem.

Vergleiche das mit einem Team, das Blue-Green-Deployment verwendet. Sie haben zwei identische Umgebungen. Eine ist live und bedient die Nutzer. Die andere hat die neue Version bereit. Wenn es Zeit für das Release ist, leiten sie einfach den Traffic von der blauen Umgebung auf die grüne um. Wenn etwas schiefgeht, leiten sie den Traffic zurück. Die alte Umgebung läuft noch. Das Rollback dauert Sekunden. Keine Code-Änderungen, keine Konfigurationsänderungen, kein Warten auf eine Pipeline.

Der Unterschied liegt nicht in einem besseren Rollback-Skript. Der Unterschied liegt in der Wahl einer Deployment-Strategie, die den Schadensradius begrenzt, bevor etwas schiefgeht.

Blue-Green-Deployment macht die Wiederherstellung nahezu sofort

Blue-Green-Deployment ist nicht nur ein ausgefallenes Muster für Releases ohne Ausfallzeiten. Es ist ein Wiederherstellungsmechanismus, der als Deployment-Strategie getarnt ist. Der entscheidende Punkt ist, dass du die alte Umgebung so lange laufen lässt, bis du sicher bist, dass die neue funktioniert. Wenn die neue Version fehlschlägt, musst du nichts neu aufbauen. Du leitest den Traffic einfach zurück zur alten Umgebung.

Das funktioniert gut für zustandslose Anwendungen, bei denen die Umgebung nur aus Compute und Konfiguration besteht. Aber es wird kniffliger, wenn du Datenbankschema-Änderungen hast. Wenn die neue Version eine Migration ausführt, die die Datenbankstruktur ändert, könnte die alte Version mit dem neuen Schema nicht funktionieren. In diesem Fall reicht es nicht, den Traffic zurückzuleiten. Du musst auch die Datenbankmigration rückgängig machen, was Zeit kostet und eigene Risiken birgt.

Hier ist eine minimale Kubernetes-Service-Konfiguration, die den Wechsel ermöglicht. Der Selektor zeigt auf die aktive Umgebung, und wenn du ihn von blue auf green (oder zurück) änderst, wird der gesamte Traffic sofort umgeleitet.

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    environment: blue   # auf 'green' umstellen für Rollback
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Wenn die neue Version fehlschlägt, aktualisierst du den Selektor auf environment: green und wendest die Änderung an. Kein Neubau, kein Warten auf die Pipeline – nur eine einzige Feldaktualisierung.

Die praktische Erkenntnis ist, dass Blue-Green-Deployment einen schnellen Rollback-Pfad bietet, aber nur, wenn du die alte Umgebung kompatibel mit dem aktuellen Datenbankzustand hältst. Wenn du das nicht garantieren kannst, ist dein Rollback nicht sofort. Es ist nur schneller als ein Neuaufbau von Grund auf.

Canary-Deployment begrenzt die Anzahl betroffener Nutzer

Canary-Deployment verfolgt einen anderen Ansatz. Anstatt den gesamten Traffic auf einmal umzuleiten, sendest du einen kleinen Prozentsatz der Nutzer an die neue Version. Vielleicht fünf Prozent. Wenn diese Gruppe keine Probleme zeigt, erhöhst du den Prozentsatz schrittweise, bis alle Nutzer auf der neuen Version sind.

Der Wiederherstellungsvorteil liegt hier auf der Hand. Wenn die neue Version ein Problem hat, sind nur fünf Prozent der Nutzer betroffen. Du kannst den Canary stoppen, diese Nutzer zurück zur alten Version schicken und das Problem untersuchen, ohne sofort alles reparieren zu müssen. Der Schadensradius ist von Natur aus klein.

Canary-Deployment funktioniert gut, wenn du genügend Traffic hast, um Probleme in der kleinen Gruppe zu erkennen, und wenn deine Infrastruktur zwei Versionen parallel betreiben kann. Es erfordert auch eine gute Beobachtbarkeit. Du musst Fehlerraten, Latenz und Nutzerverhalten zwischen der Canary-Gruppe und der Kontrollgruppe vergleichen. Ohne das rätst du nur, ob die neue Version sicher weiter ausgerollt werden kann.

Der Nachteil ist die Komplexität. Du brauchst Traffic-Routing-Logik, ein Monitoring, das Gruppen vergleichen kann, und einen Prozess, um zu entscheiden, wann der Canary-Prozentsatz erhöht wird. Aber für Teams, die häufig ausliefern und sich keine vollständigen Rollbacks leisten können, ist die Komplexität es wert.

Feature Flags ermöglichen die Wiederherstellung ohne Deployment

Feature Flags funktionieren anders als die anderen Strategien. Anstatt eine neue Version auszuliefern, um zu steuern, wer sie sieht, lieferst du den neuen Code an alle aus, versteckst ihn aber hinter einem Schalter. Der Code ist bereits in der Produktion. Er ist nur noch nicht für die Nutzer aktiv. Du schaltest den Schalter für eine kleine Gruppe ein, überwachst die Ergebnisse und erweiterst dann schrittweise das Publikum.

Wenn etwas schiefgeht, schaltest du den Schalter aus. Kein Rollback, kein Hotfix, kein Warten auf eine Pipeline. Die Wiederherstellung erfolgt in Sekunden mit einer einzigen Konfigurationsänderung. Dies ist der chirurgischste Ansatz zur Begrenzung des Schadensradius. Du kannst eine Funktion zuerst für interne Nutzer aktivieren, dann für Beta-Nutzer, dann für einen Prozentsatz des Produktionstraffics und schließlich für alle. An jedem Punkt kannst du die Funktion sofort deaktivieren.

Feature Flags sind mächtig, aber sie haben auch ihre Kosten. Du brauchst ein System zur Verwaltung der Flags, einen Prozess zum Bereinigen alter Flags und Disziplin, um eine Flaggenflut zu vermeiden. Jedes Flag in deinem Code fügt bedingte Logik hinzu, die das Testen erschwert. Wenn du Flags nach der Stabilisierung einer Funktion nie entfernst, wird deine Codebasis zu einem Labyrinth toter Zweige.

Der wahre Wert von Feature Flags liegt nicht darin, schneller auszuliefern. Es geht darum, einen Wiederherstellungsmechanismus zu haben, der überhaupt kein Deployment erfordert. Das ändert das Risikoprofil jedes Releases.

Deine Deployment-Strategie ist dein Wiederherstellungsplan

Hier ist die Kernidee, die alles zusammenhält. Du kannst deine Deployment-Strategie nicht von deinem Wiederherstellungsplan trennen. Die Entscheidungen, die du darüber triffst, wie du eine neue Version ausrollst, bestimmen, welche Wiederherstellungsoptionen du hast, wenn etwas schiefgeht.

Das folgende Diagramm zeigt, wie jede Strategie einen Fehler behandelt, von der Erkennung bis zur Wiederherstellung.

flowchart TD A[Neue Version deployen] --> B{Deployment-Strategie?} B -->|Blue-Green| C[Traffic zur neuen Umgebung leiten] C --> D{Neue Version fehlschlägt?} D -->|Ja| E[Traffic zurück zur alten Umgebung leiten] D -->|Nein| F[Neue Umgebung live lassen] B -->|Canary| G[5% Traffic zur neuen Version leiten] G --> H{Fehler im Canary?} H -->|Ja| I[Canary stoppen, Nutzer zurückschicken] H -->|Nein| J[Traffic schrittweise erhöhen] B -->|Feature Flags| K[Code hinter Flag deployen] K --> L[Flag für kleine Gruppe aktivieren] L --> M{Problem erkannt?} M -->|Ja| N[Flag sofort deaktivieren] M -->|Nein| O[Flag-Zielgruppe erweitern]

Wenn du deployst, indem du alle Server auf einmal ersetzt, ist deine einzige Wiederherstellungsoption ein vollständiges Rollback. Wenn du Blue-Green verwendest, hast du eine sofortige Umschaltung. Wenn du Canary verwendest, begrenzt du die Anzahl der betroffenen Nutzer. Wenn du Feature Flags verwendest, kannst du die problematische Funktion deaktivieren, ohne die Deployment-Pipeline zu berühren.

Jede Strategie hat Nachteile. Blue-Green erfordert die doppelte Infrastruktur. Canary erfordert gutes Monitoring und Traffic-Routing. Feature Flags erfordern ein Flag-Management-System und Disziplin bei der Bereinigung. Aber alle sind besser, als keine Strategie zu haben und zu hoffen, dass das Rollback-Skript funktioniert, wenn du es brauchst.

Die Teams, die sich am schnellsten erholen, sind nicht die mit den besten Rollback-Skripten. Sie sind diejenigen, die ihren Deployment-Prozess von Anfang an so gestaltet haben, dass die Wiederherstellung einfach ist.

Kurze Checkliste für dein nächstes Deployment

  • Kannst du ein Rollback durchführen, ohne Code oder Konfiguration zu ändern?
  • Wie viele Nutzer wären betroffen, wenn die neue Version fehlschlägt?
  • Kannst du die neue Version in der Produktion testen, ohne alle Nutzer zu exponieren?
  • Hast du eine Möglichkeit, eine bestimmte Funktion zu deaktivieren, ohne neu zu deployen?
  • Läuft deine alte Umgebung noch und ist sie mit der aktuellen Datenbank kompatibel?

Wenn du die meisten dieser Fragen mit Nein beantwortet hast, wird deine nächste Wiederherstellung schwieriger sein, als sie sein müsste.

Was das für dein Team bedeutet

Wenn du das nächste Mal ein Deployment planst, denke nicht nur darüber nach, wie du die neue Version hochbekommst. Denke darüber nach, wie du sie wieder runterbekommst, wenn etwas schiefgeht. Wähle eine Strategie, die dir Optionen gibt. Dein zukünftiges Ich, das vor einem Dashboard voller roter Alarme steht, wird es dir danken.