Wenn ein Rollback die Lage verschlimmert (und was stattdessen zu tun ist)

Sie haben gerade eine neue Version deployed. Die Pipeline ist grün. Health Checks bestehen. CPU und Speicher sehen normal aus. Aber Ihr Telefon vibriert ununterbrochen wegen Nachrichten von Benutzern. Eine Funktion, die gestern noch funktioniert hat, ist jetzt kaputt. Die Daten, die in die Datenbank geschrieben werden, sehen falsch aus. Und die Fehlerlogs? Nichts Ungewöhnliches.

Das ist der Moment, in dem die meisten Teams denken: „Machen wir einfach ein Rollback.“ Es klingt einfach. Tauschen Sie die neue Version gegen die alte aus. Problem gelöst. Aber in der Praxis kann ein Rollback aus einem beherrschbaren Problem eine Katastrophe machen. Die alte Version versteht die Daten nicht, die die neue Version bereits geschrieben hat. Das Datenbankschema wurde möglicherweise geändert. Oder das Rollback selbst dauert so lange, dass während des Übergangs noch mehr Benutzer betroffen sind.

Ein Rollback ist kein Knopf, den man drückt. Es ist eine Entscheidung, die man unter Druck trifft, mit unvollständigen Informationen und mit Konsequenzen, die durch das gesamte System wirken. Zu verstehen, wann und wie man ein Rollback durchführt – und wann nicht – ist das, was Teams, die sich schnell erholen, von Teams unterscheidet, die die Sache noch schlimmer machen.

Das eigentliche Signal für ein Rollback

Die meisten Teams verlassen sich auf Health Checks, um zu entscheiden, ob ein Deployment gesund ist. Aber Health Checks sagen Ihnen nur, ob die Anwendung technisch läuft. Sie sagen Ihnen nicht, ob die Anwendung das Richtige tut.

Betrachten Sie dieses Szenario: Ihre neue Version schreibt erfolgreich Kundenbestellungen in die Datenbank. Keine Fehler. Keine Abstürze. Aber die Bestelldaten werden mit dem falschen Währungsformat gespeichert. Die Anwendung ist technisch gesund, aber funktional kaputt. Health Checks werden das nicht erkennen. Ihr Monitoring wird das wahrscheinlich auch nicht erkennen, es sei denn, Sie haben spezifische Metriken auf Geschäftsebene eingerichtet.

Die Entscheidung für ein Rollback ergibt sich normalerweise aus einer Kombination von Signalen:

• Health Checks, die fehlschlagen
• Fehlerraten, die in die Höhe schnellen
• Benutzermeldungen, die ein Verhalten beschreiben, das nicht den Erwartungen entspricht
• Geschäftsmetriken, die von normalen Mustern abweichen

Aber es gibt einen weiteren Faktor, den Teams oft übersehen: die Zeit. Wie lange warten Sie, bevor Sie sich für ein Rollback entscheiden? Fünf Minuten? Dreißig Minuten? Bis sich jemand beschwert? Je länger Sie warten, desto mehr Daten werden von der neuen Version geschrieben. Und je mehr Daten geschrieben werden, desto schwieriger wird das Rollback.

Legen Sie vor jedem Deployment ein klares Beobachtungsfenster fest. Entscheiden Sie im Voraus: Wenn wir in den ersten 15 Minuten keine Probleme sehen, betrachten wir es als stabil. Wenn wir innerhalb dieses Fensters Probleme sehen, machen wir sofort ein Rollback. Das beseitigt das Zögern, das schlechte Situationen noch verschlimmert.

Warum zustandslos und zustandsbehaftet nicht dasselbe sind

Die Leichtigkeit eines Rollbacks hängt fast vollständig davon ab, ob Ihre Anwendung einen Zustand (State) hält.

Bei zustandslosen Anwendungen ist ein Rollback unkompliziert. Sie leiten den Datenverkehr zurück zur alten Version. Keine Daten, die wiederhergestellt werden müssen. Kein Schema, das abgeglichen werden muss. Die alte Version macht dort weiter, wo sie aufgehört hat, weil sie nie von einem Zustand der neuen Version abhängig war. Deshalb sind zustandslose Dienste oft die ersten Kandidaten für aggressive Rollback-Strategien.

Bei zustandsbehafteten Anwendungen ist ein Rollback ein anderes Spiel. Stellen Sie sich vor, Ihre neue Version hat 10.000 Datensätze mit einem neuen Feld in die Datenbank geschrieben, von dem die alte Version nichts weiß. Wenn Sie das Rollback der Anwendung durchführen, versucht die alte Version, diese Datensätze zu lesen. Sie stürzt ab, weil das Datenformat nicht dem entspricht, was sie erwartet. Oder noch schlimmer: Die neue Version hat eine Datenbanktabellenstruktur geändert. Jetzt kann die alte Anwendung nicht einmal mehr starten, weil das Schema inkompatibel ist.

Das ist die Falle: ein Rollback der Anwendung durchzuführen, ohne ein Rollback der Daten zu machen. Wenn Ihr Deployment das Datenbankschema geändert oder Daten in einem neuen Format geschrieben hat, reicht ein Rollback des Codes allein nicht aus. Sie müssen entweder:

• Die Datenbank auf einen Zeitpunkt vor dem Deployment zurücksetzen
• Migrationsskripte schreiben, die die Schemaänderungen rückgängig machen
• Akzeptieren, dass einige Daten verloren gehen oder beschädigt werden

Jede dieser Optionen hat ihre eigenen Kosten und Risiken. Das Zurücksetzen der Datenbank braucht Zeit und könnte legitime Daten verlieren, die andere Teile des Systems während des Fensters geschrieben haben. Reverse-Migrationen müssen vor dem Deployment getestet und bereit sein, nicht erst unter Druck geschrieben werden.

Drei Strategien, die tatsächlich funktionieren

Verschiedene Situationen erfordern unterschiedliche Rollback-Ansätze. Hier sind drei, die Teams in der Praxis verwenden.

Der folgende Entscheidungsbaum kann Ihnen bei der Wahl helfen:

Forward-Fix

Anstatt zur alten Version zurückzukehren, bauen Sie eine neue Version, die das Problem behebt, und deployen diese. Dies ist oft die sicherste Option für zustandsbehaftete Anwendungen, da Sie Datenänderungen nicht rückgängig machen müssen. Sie müssen sie nur korrigieren.

Ein Forward-Fix funktioniert gut, wenn:

• Der Fehler isoliert ist und schnell behoben werden kann
• Ihre Pipeline eine neue Version in Minuten ausliefern kann
• Die von der defekten Version geschriebenen Daten wiederherstellbar oder migrierbar sind

Das Risiko ist die Zeit. Wenn der Fehler schwerwiegend ist und die Behebung Stunden dauert, sind die Benutzer während Ihrer Arbeit weiterhin dem Problem ausgesetzt. Ein Forward-Fix erfordert Vertrauen in die Fähigkeit Ihres Teams, Probleme schnell zu diagnostizieren und zu beheben.

Traffic-Shift

Wenn Sie Canary- oder Blue-Green-Deployment verwenden, ist ein Rollback so einfach wie das Zurückleiten des Datenverkehrs zur alten Version. Die alte Version läuft noch und ist bereit, Datenverkehr anzunehmen. Es gibt keinen Deployment-Prozess, auf den Sie warten müssen. Keine Übergangsphase, in der einige Benutzer die alte und andere die neue Version treffen.

Dies ist die schnellste Rollback-Methode. Aber sie funktioniert nur, wenn Sie Ihre Deployment-Strategie mit diesem Gedanken entworfen haben. Wenn Sie Rolling Updates verwenden, haben Sie keine bereitstehende alte Version. Ein Rollback bedeutet, den gesamten Deployment-Prozess mit dem alten Artefakt erneut durchzuführen. Das braucht Zeit und setzt Benutzer während des Übergangs Fehlern aus.

Hier ist ein konkretes Beispiel mit Kubernetes, um den Datenverkehr während eines Canary-Deployments zurück zur alten Version zu leiten:

# Aktuelle Traffic-Aufteilung prüfen (Annahme: ein Service mit zwei Selektoren)
kubectl get virtualservice my-app -o jsonpath='{.spec.http[0].route[*].weight}'

# 100% des Traffics zur alten Version (v1) leiten
kubectl patch virtualservice my-app --type='json' -p='[
  {"op": "replace", "path": "/spec/http/0/route/0/weight", "value": 100},
  {"op": "replace", "path": "/spec/http/0/route/1/weight", "value": 0}
]'

# Änderung überprüfen
kubectl get virtualservice my-app -o yaml | grep -A5 "route:"

Dieser Ansatz setzt voraus, dass Sie ein Service Mesh oder einen Ingress-Controller (wie Istio oder Traefik) haben, der gewichtetes Routing unterstützt. Für einfachere Setups können Sie dasselbe erreichen, indem Sie den Service-Selektor aktualisieren, sodass er ausschließlich auf die Pods der alten Version zeigt.

Akzeptieren und Patchen

Manchmal ist die beste Entscheidung, die neue Version laufen zu lassen und das Problem direkt zu beheben. Das klingt kontraintuitiv, aber bedenken Sie: Wenn die neue Version bereits Daten geschrieben hat, die die alte Version nicht lesen kann, führt ein Rollback garantiert zu Ausfallzeiten. Die neue Version weiterlaufen zu lassen, bedeutet, dass Benutzer das System weiterhin nutzen können, während Sie an einem Fix arbeiten.

Dieser Ansatz funktioniert, wenn:

• Das Problem nicht kritisch ist (geringfügiger Anzeigefehler, nicht blockierender Bug)
• Die von der neuen Version geschriebenen Daten wertvoll sind und bei einem Rollback verloren gehen würden
• Das Team einen Patch in angemessener Zeit ausliefern kann

Der Schlüssel ist zu wissen, wann man akzeptiert und wann man handelt. Wenn das Problem die Kernfunktionalität beeinträchtigt oder Daten beschädigt, ist „Akzeptieren und Patchen“ nicht die richtige Wahl.

Eine praktische Checkliste vor Ihrem nächsten Deployment

Bevor Sie deployen, gehen Sie diese Fragen mit Ihrem Team durch:

• Welche Signale lösen eine Rollback-Entscheidung aus? (Health, Fehler, Benutzermeldungen, Geschäftsmetriken)
• Wie lange werden wir beobachten, bevor wir eine Entscheidung treffen? (5 Minuten, 15 Minuten, 30 Minuten)
• Ändert dieses Deployment das Datenbankschema oder das Datenformat?
• Wenn ja, haben wir einen getesteten Reverse-Migrations- oder Wiederherstellungsplan?
• Läuft die alte Version noch und ist bereit, Datenverkehr anzunehmen?
• Können wir einen Forward-Fix schneller bereitstellen als ein Rollback?

Schreiben Sie die Antworten auf. Teilen Sie sie mit dem Team. Die Zeit, ein Rollback zu planen, ist vor dem Deployment, nicht während des Vorfalls.

Das Fazit

Ein Rollback ist kein universelles Sicherheitsnetz. Für zustandslose Anwendungen ist es eine zuverlässige Notluke. Für zustandsbehaftete Anwendungen kann es eine Falle sein, die die Sache verschlimmert. Die Entscheidung für ein Rollback hängt davon ab, wie viele Daten betroffen sind, wie schnell Sie einen Forward-Fix bereitstellen können und ob die alte Version noch mit dem aktuellen Zustand Ihres Systems arbeiten kann.

Planen Sie Ihren Rollback-Pfad vor jedem Deployment. Kennen Sie Ihre Signale. Legen Sie Ihr Beobachtungsfenster fest. Und denken Sie daran: Manchmal ist die beste Wiederherstellung nicht der Rückwärtsgang, sondern der Vorwärtsgang.