Rollback: Wenn Zurückgehen nicht so einfach ist, wie es klingt

Du hast gerade eine neue Version deiner Anwendung deployed. Fünf Minuten später tauchen Fehler im Monitoring-Dashboard auf. Nutzer melden Probleme. Dein erster Impuls ist klar: die alte Version wiederherstellen. Das ist Rollback in seiner einfachsten Form – zurück zum letzten bekannten stabilen Zustand, um Zeit zu gewinnen und herauszufinden, was schiefgelaufen ist.

Für viele Teams ist Rollback die Standard-Wiederherstellungsstrategie. Es klingt intuitiv: Wenn die neue Version etwas kaputt gemacht hat, hat die alte Version funktioniert. Einfach zurücktauschen. Aber die Realität ist komplizierter. Rollback funktioniert unterschiedlich, je nachdem, was zurückgesetzt wird: Anwendungscode, Datenbankschema oder Infrastrukturkonfiguration. Jedes hat seine eigene Mechanik, Risiken und Grenzen.

Application-Rollback: Der relativ einfache Fall

Das Zurücksetzen von Anwendungscode ist der unkomplizierteste Fall. Du hast eine laufende Instanz deiner Anwendung und ersetzt die neue Version durch die alte. Wie das gemacht wird, hängt von der Deployment-Strategie ab.

Bei Blue-Green-Deployment bedeutet Rollback, den Traffic zurück zur Umgebung zu leiten, die noch die alte Version ausführt. Die grüne Umgebung wird wieder aktiv, die blaue aus dem Verkehr gezogen. Dieser Wechsel kann in Sekunden erfolgen, da beide Umgebungen bereits laufen und bereit sind.

Bei Canary-Releases bedeutet Rollback, den Traffic zur neuen Version zu stoppen und alles zurück zur vorherigen Version zu leiten. Der Canary wird beendet, und die stabile Version übernimmt wieder alle Anfragen.

Bei einfachen Rolling Updates bedeutet Rollback, das vorherige Artefakt erneut auf denselben Servern oder Containern zu deployen. Das dauert länger, weil jede Instanz einzeln aktualisiert werden muss, aber der Prozess bleibt vorhersagbar.

Wenn du Kubernetes verwendest, genügt ein einziger Befehl, um ein Deployment auf die vorherige Revision zurückzusetzen:

kubectl rollout undo deployment/my-app -n production

Dieser Befehl weist Kubernetes an, die neuen Pods herunterzuskalieren und die alten hochzuskalieren – das Rolling Update wird effektiv rückgängig gemacht. Du kannst auch eine bestimmte Revision angeben, wenn du weiter als einen Schritt zurückgehen musst:

kubectl rollout undo deployment/my-app -n production --to-revision=3

Um den Verlauf der Revisionen vor dem Rollback anzuzeigen:

kubectl rollout history deployment/my-app -n production

Der entscheidende Vorteil des Application-Rollbacks ist, dass es keine Daten verändert. Es wird nur geändert, welcher Code eingehende Anfragen bearbeitet. Die Datenbank bleibt unberührt, und keine Benutzerdaten gehen verloren oder werden transformiert. Das macht Application-Rollback relativ sicher und schnell.

Das folgende Flussdiagramm zeigt die Entscheidungspfade für jeden in diesem Abschnitt besprochenen Rollback-Typ.

flowchart TD A[Welche Art von Rollback?] --> B[Application] A --> C[Datenbank] A --> D[Infrastruktur] B --> B1[Blue-Green: Traffic umleiten] B --> B2[Canary: Canary-Traffic stoppen] B --> B3[Rolling: altes Artefakt erneut deployen] C --> C1[Schema geändert?] C1 -- Ja --> C2[Down-Migration ausführen] C1 -- Nein --> C3[Kein DB-Eingriff nötig] C2 --> C4[Datenverlustrisiko?] C4 -- Ja --> C5[Aus Backup wiederherstellen] C4 -- Nein --> C6[Schema zurückgesetzt] D --> D1[Konfigurationsdateien zurücksetzen] D1 --> D2[Abhängigkeiten prüfen] D2 --> D3[Vorherigen Zustand anwenden]

Datenbank-Rollback: Wo es richtig kompliziert wird

Datenbank-Rollback ist eine ganz andere Herausforderung. Datenbanken speichern Zustände, die sich ständig ändern. Wenn eine neue Anwendungsversion das Datenbankschema ändert – eine Spalte hinzufügt, eine Tabelle umbenennt, einen Datentyp ändert – reicht es nicht, nur den Anwendungscode zurückzusetzen. Du musst auch die Datenbankstruktur in den vorherigen Zustand versetzen.

Hier wird die Komplexität richtig groß. Betrachten wir ein einfaches Szenario: Deine neue Version fügt eine Spalte namens phone_number zur Tabelle users hinzu. Die Anwendung beginnt, Telefonnummern in diese Spalte zu schreiben. Nach einer Stunde entdeckst du einen kritischen Fehler und entscheidest dich für einen Rollback. Du deployst den alten Anwendungscode, aber der alte Code weiß nichts von der phone_number-Spalte. Noch wichtiger: Die bereits in diese Spalte geschriebenen Daten müssen behandelt werden. Löschst du sie? Verschiebst du sie woanders hin? Lässt du sie einfach stehen und hoffst, dass der alte Code sie ignoriert?

Der sicherste Ansatz ist, jede Datenbankmigration von Anfang an reversibel zu machen. Das bedeutet, dass jedes Migrationsskript sowohl einen up-Schritt (der die Änderung anwendet) als auch einen down-Schritt (der sie rückgängig macht) enthält. Beim Rollback führst du die down-Migration aus, um das vorherige Schema wiederherzustellen.

Aber nicht alle Änderungen sind wirklich ohne Datenverlust umkehrbar. Wenn deine neue Version eine Spalte gelöscht hat, die noch in Gebrauch war, bedeutet Rollback, diese Spalte neu zu erstellen und ihre Daten aus einem Backup wiederherzustellen. Wenn deine neue Version zwei Tabellen zu einer zusammengeführt hat, bedeutet Rollback, sie wieder zu trennen und herauszufinden, welche Zeilen zu welcher Tabelle gehörten. Diese Operationen sind riskant, zeitaufwändig und erfordern oft manuelle Eingriffe.

Viele Teams akzeptieren diese Realität und vermeiden Datenbank-Rollbacks ganz. Stattdessen investieren sie stark in das Testen von Migrationen vor dem Deployment, indem sie sie gegen Staging-Umgebungen laufen lassen, die die Produktionsdaten so genau wie möglich abbilden. Wenn dann doch etwas schiefgeht, schreiben sie lieber einen Forward-Fix, anstatt einen Rückwärts-Rollback zu versuchen.

Infrastruktur-Rollback: Das versteckte Abhängigkeitsnetz

Infrastruktur-Rollback bedeutet, Änderungen an Servern, Netzwerkregeln, Load-Balancern oder unterstützenden Diensten rückgängig zu machen. Wenn du die Infrastruktur mit Tools wie Terraform, Ansible oder Pulumi verwaltest, bedeutet Rollback in der Regel, eine vorherige Version deiner Konfigurationsdateien anzuwenden.

Die Herausforderung hier ist, dass Infrastrukturänderungen selten nur eine Sache betreffen. Eine Änderung einer Firewall-Regel kann die Datenbankverbindung unterbrechen. Eine Änderung der Load-Balancer-Konfiguration kann das Traffic-Routing für mehrere Dienste beeinflussen. Das Zurücksetzen eines Terraform-State-Files könnte Ressourcen löschen, die die neue Version erstellt hat, was wiederum andere Probleme auslösen kann.

Infrastruktur-Rollback braucht auch Zeit. Das Anwenden einer vorherigen Konfiguration erfordert, dieselben Provisioning-Prozesse auszuführen, die die Infrastruktur ursprünglich erstellt haben. Wenn deine Infrastruktur groß oder komplex ist, kann das Minuten oder sogar Stunden dauern – Zeit, in der deine Nutzer Fehler erleben.

Die Grenzen von Rollback als Strategie

Rollback ist kein universelles Sicherheitsnetz. Es funktioniert nur, wenn drei Bedingungen erfüllt sind:

Erstens: Die alte Version muss noch stabil und mit dem aktuellen Systemzustand kompatibel sein. Wenn deine neue Version stundenlang lief und Benutzer Daten eingegeben haben, die die alte Version nicht lesen kann, führt ein Rollback zu Datenverlust oder -korruption.

Zweitens: Das Problem muss im Code oder in der Konfiguration liegen, nicht in den Daten. Wenn das Problem darin besteht, dass Benutzer eine Funktion falsch nutzen oder die Datenqualität nachgelassen hat, wird ein Rollback des Codes nichts beheben.

Drittens: Der Rollback muss schneller sein als die Zeit, die ein Forward-Fix benötigt. Wenn der Rollback dreißig Minuten dauert, aber ein Hotfix in zehn Minuten geschrieben werden kann, ist der Rollback die langsamere Option.

Es gibt auch ein Verhaltensrisiko. Teams, die sich zu sehr auf Rollback verlassen, können beim Pre-Deployment-Testing nachlässig werden. Die Einstellung wird zu: „Wenn es kaputtgeht, machen wir einfach einen Rollback.“ Das ist gefährlich, weil Rollback echte Kosten verursacht. Benutzer, die Fehler gesehen oder Daten verloren haben, interessiert es nicht, dass du in fünf Minuten wiederhergestellt hast. Ihr Vertrauen ist bereits beschädigt.

Praktische Checkliste vor der Entscheidung für einen Rollback

Bevor du einen Rollback durchführst, stelle dir diese Fragen:

  • Läuft die alte Version noch und ist bereit, Traffic anzunehmen?
  • Hat sich das Datenbankschema so geändert, dass der alte Code inkompatibel ist?
  • Wie lange ist die neue Version bereits live, und wie viele Benutzerdaten wurden eingegeben?
  • Kann die Datenbankmigration ohne Datenverlust rückgängig gemacht werden?
  • Ist der Rollback schneller als das Schreiben eines Forward-Fixes?
  • Hast du den Rollback-Plan mit dem Team und den Stakeholdern kommuniziert?

Wenn die Antwort auf eine dieser Fragen eine rote Flagge aufwirft, ziehe stattdessen einen Roll-Forward in Betracht.

Das Fazit

Rollback ist eine legitime Wiederherstellungsstrategie, aber kein kostenloser „Rückgängig“-Button. Application-Rollback ist relativ sicher und schnell. Datenbank-Rollback ist riskant und oft irreversibel. Infrastruktur-Rollback ist langsam und kann kaskadierende Effekte haben. Bevor du Rollback zu deiner Standardreaktion machst, verstehe, was du zurücksetzt und was die tatsächlichen Kosten sind. Manchmal ist der bessere Weg, einen Forward-Fix zu schreiben – und das sehen wir uns als Nächstes an.