„Im Notfall rollen wir zurück“ klingt beruhigend, ist aber oft kein echter Plan. Sobald Datenbankmigrationen, externe Schnittstellen oder bereits geschriebene Nutzerdaten beteiligt sind, kann ein Rollback deutlich komplizierter sein als ein früheres Deployment erneut zu starten.
Rollback zuerst technisch einordnen
Bei statischen Änderungen ist ein Zurückrollen oft einfach. Bei Datenmodelländerungen, Message-Formaten oder neuen Abhängigkeiten kann es dagegen sein, dass die alte Version mit dem neuen Zustand gar nicht mehr funktioniert. Der Plan muss deshalb zur konkreten Änderung passen.
Abbruchkriterien vor dem Release festlegen
Ein Team sollte nicht erst unter Druck diskutieren, wann zurückgerollt wird. Sinnvoll sind klare Signale: stark erhöhte Fehlerrate, fehlerhafte Zahlungen, Datenverlust, blockierte Kernprozesse oder ein messbarer Performance-Einbruch.
Datenbankmigrationen separat betrachten
Eine Migration, die nur eine neue optionale Spalte ergänzt, ist anders zu bewerten als eine Migration, die Daten transformiert oder entfernt. Rückwärtskompatible Änderungen erleichtern sichere Releases. Destruktive Schritte sollten möglichst erst erfolgen, wenn die neue Version stabil ist und alte Daten nicht mehr benötigt werden.
Feature Flags können Risiko trennen
Wenn neue Logik unabhängig vom Deployment aktiviert werden kann, lässt sich ein Problem häufig entschärfen, ohne die gesamte Version zurückzurollen. Ein Feature Flag ersetzt keinen Plan, kann aber die Reaktionszeit deutlich verkürzen.
Monitoring muss die Entscheidung ermöglichen
Ein Rollback-Plan funktioniert nur, wenn das Team erkennt, dass etwas schiefläuft. Dazu gehören technische Metriken, Logs und fachliche Signale. Ein Release kann technisch „grün“ sein und trotzdem fachlich falsche Ergebnisse produzieren.
Verantwortung festlegen
Wer darf ein Rollback auslösen? Wer beobachtet die ersten Minuten nach dem Deployment? Wer kommuniziert mit Support oder Fachseite? In kleinen Teams können dieselben Personen mehrere Rollen übernehmen – unklar sollten sie trotzdem nicht sein.
Vorwärtsfix oder Rollback?
Nicht jeder Fehler rechtfertigt ein Zurückrollen. Bei einem kleinen, klar isolierten Problem kann ein schneller Fix risikoärmer sein. Bei unbekannter Ursache, Datenrisiko oder einem defekten Kernprozess ist ein Rollback oft die bessere erste Maßnahme.
Ein kompakter Rollback-Plan
Auslöser: Welche Signale führen zum Abbruch?
Verantwortlich: Wer entscheidet und führt aus?
Technischer Weg: Welche Version oder Konfiguration wird wiederhergestellt?
Daten: Sind Migrationen rückwärtskompatibel?
Verifikation: Woran erkennen wir, dass der alte Zustand wieder stabil ist?
Kommunikation: Wer muss informiert werden?
Nach dem Rollback ist die Arbeit nicht vorbei
Der alte Zustand muss erneut geprüft werden. Außerdem sollte dokumentiert werden, warum zurückgerollt wurde, welche Annahme falsch war und was vor dem nächsten Versuch geändert wird. Sonst wird aus dem Rollback nur eine Pause vor demselben Fehler.