Ein Rollback ist die gezielte Rückkehr eines Systems, Workflows, einer Konfiguration oder eines Datenbankzustands zu einer früheren, stabilen Version – nach einem fehlerhaften Update, einer problematischen Änderung oder einem Systemfehler. Der Rollback macht die zuletzt vorgenommene Änderung rückgängig und stellt den Zustand wieder her, der vor dieser Änderung bestanden hat.
Rollback ist ein zentrales Sicherheitsnetz im Software- und Automatisierungsbetrieb: Er begrenzt den Schaden, den fehlerhafte Änderungen anrichten können, indem er eine definierte Ausstiegsoption bereitstellt. Die Fähigkeit zum schnellen Rollback ist ein direktes Maß für die operative Reife einer Automatisierungsumgebung.
Wann wird ein Rollback ausgelöst?
- Fehlerquote steigt nach einem Update: Eine neue Version eines Workflows oder einer Konfiguration produziert deutlich mehr Fehler als erwartet
- Unerwartetes Verhalten: Der Prozess verhält sich nach der Änderung anders als spezifiziert – auch wenn keine technischen Fehler auftreten
- Performance-Einbruch: Die neue Version ist deutlich langsamer als die vorherige und erfüllt keine SLA-Anforderungen mehr
- Kompatibilitätsproblem: Die neue Version ist mit einem abhängigen System inkompatibel, das noch nicht aktualisiert wurde
- Datenproblem: Die neue Version hat Daten falsch verarbeitet – ein Rollback der Software, kombiniert mit einem Datenbank-Rollback, stellt den korrekten Zustand wieder her
Arten von Rollbacks
- Anwendungs-Rollback: Die vorherige Version einer Anwendung, eines Workflows oder eines Bots wird reaktiviert – technisch durch Versionsverwaltung ermöglicht
- Konfigurationsrollback: Eine frühere Konfigurationsversion wird wiederhergestellt – z. B. wenn eine geänderte Regelkonfiguration unerwünschte Auswirkungen hat
- Datenbankrollback: Datenbankänderungen einer fehlerhaften Transaktion werden rückgängig gemacht – technisch durch Transaktionen und Datenbank-Backups ermöglicht
- Infrastruktur-Rollback: Die Systemkonfiguration (Server, Netzwerk, Cloud-Ressourcen) wird auf einen früheren Stand zurückgesetzt
Rollback-Strategie: Entscheidung, nicht Notfall
Ein Rollback sollte keine Notfallmaßnahme sein, die unter Panik durchgeführt wird, sondern eine vorher geplante, definierte Reaktion auf bestimmte Fehlerzustände. Gute Deployments beinhalten immer eine Rollback-Definition: Unter welchen Bedingungen wird zurückgesetzt? Wer entscheidet? Wie lange dauert der Rollback? Was passiert mit zwischenzeitlich eingebrachten Daten? Diese Fragen vor dem Deployment zu beantworten verhindert hektische Entscheidungen im Ernstfall.
Praxisbeispiel
Ein Unternehmen deployed am Freitagnachmittag eine neue Version seines Auftragsworkflows. Bis 17:00 Uhr verarbeitet er korrekt. Ab 17:30 Uhr steigt die Fehlerrate auf 8 Prozent – ein Schwellenwert, der gemäß Deployment-Protokoll automatisch einen WARNING-Alert auslöst. Das On-Call-Team prüft die Logs: Ein Sonderzeichen in Bestellnummern internationaler Kunden verursacht einen Parsing-Fehler in der neuen Version. Entscheidung: Rollback auf Version 2.2.1. Durchführung: 4 Minuten. Um 17:45 Uhr läuft der Workflow stabil auf 2.2.1. Die Fehler der 15 betroffenen Aufträge werden aus dem Fehler-Log manuell nachverarbeitet. Der Rollback hat eine Eskalation verhindert, die sonst das Wochenende bestimmt hätte.
