Ein Deployment geht schief. Die Frage ist dann nicht, ob es einen Rückweg gibt, sondern ob ihn jemand kennt und ob er unter Druck funktioniert. In vielen Teams ist die Antwort auf beides unklar, und das fällt genau in dem Moment auf, in dem es teuer wird.
Der Rückweg steht im Runbook und wurde nie gegangen
Fast jedes Team hat einen Rollback-Plan. Deutlich weniger Teams haben ihn in den letzten Monaten tatsächlich ausgeführt. Der Plan besteht oft aus einem Satz: im Fehlerfall die vorherige Version erneut deployen. Das klingt ausreichend, bis der Fehlerfall eintritt und jemand feststellt, dass das Artefakt der vorherigen Version nicht mehr in der Registry liegt, weil die Aufbewahrungsregel auf sieben Tage steht. Oder dass der Deployment-Job gar keinen Versionsparameter kennt, sondern immer den aktuellen Stand eines Branches ausrollt.
Ein Rückweg, den niemand gegangen ist, ist kein Rückweg. Er ist eine Annahme.
Der Code ist selten das Problem
Die alte Anwendungsversion zurückzuspielen ist der einfache Teil. Schwierig wird es an den Stellen, an denen ein Deployment mehr verändert hat als den Anwendungscode.
- Datenbank-Migrationen. Eine Spalte, die im neuen Release umbenannt oder entfernt wurde, kommt nicht dadurch zurück, dass die alte Version wieder läuft. Rückwärtskompatible Migrationen sind Arbeit, die vor dem Rollback anfällt, nicht danach.
- Konfiguration. Wenn die neue Version einen zusätzlichen Parameter erwartet und die Konfiguration außerhalb des Repos gepflegt wird, passt der Stand nach dem Zurückrollen nicht mehr zusammen.
- Queues und Nachrichtenformate. Nachrichten, die im neuen Format bereits in einer Warteschlange liegen, versteht die alte Version nicht mehr.
- Downstream-Systeme. Wer bereits gegen die neue Schnittstellenversion integriert hat, bricht beim Rollback mit.
Die brauchbare Frage lautet deshalb nicht „können wir zurück“, sondern „was genau hat dieses Deployment verändert, und was davon lässt sich rückgängig machen“.
Drei Rückwege, die man auseinanderhalten sollte
Rollback im engen Sinn. Die vorherige Artefaktversion wird erneut ausgerollt. Schnell, solange das Artefakt noch existiert und keine irreversiblen Zustandsänderungen dazwischenliegen.
Roll-forward. Der Fehler wird mit einem neuen Release behoben. Bei nicht umkehrbaren Migrationen oft der einzige realistische Weg, dauert aber so lange wie ein regulärer Build samt Review.
Abschalten statt zurückdrehen. Die neue Funktion liegt hinter einem Schalter und wird deaktiviert, während die Version live bleibt. Der schnellste Weg, aber nur verfügbar, wenn die Funktion vorher so gebaut wurde.
Ein Team, das nur eine dieser Optionen kennt, hat im Ernstfall keine Wahl, sondern eine Hoffnung.
Was ein Rückweg praktisch braucht
- Das vorherige Artefakt muss noch verfügbar sein. Die Aufbewahrungsfristen der Registry gehören gegen die eigene Rollback-Erwartung geprüft, nicht umgekehrt.
- Der Deployment-Job muss eine bestimmte Version ausrollen können und nicht nur den jeweils neuesten Stand.
- Migrationen brauchen eine Regel: hinzufügende Änderungen zuerst, entfernende erst ein Release später.
- Es muss geklärt sein, wer den Rückweg auslösen darf, ohne vorher eine Freigabekette zu durchlaufen, die nachts um zwei niemanden erreicht.
- Der Rückweg selbst gehört protokolliert. Ein Rollback ist eine Änderung an der Produktion und gehört in dieselbe Nachweiskette wie jedes andere Deployment.
Der letzte Punkt wird regelmäßig übersehen. Nach einem hektischen Abend ist häufig nicht mehr rekonstruierbar, welcher Stand seit wann läuft und wer ihn ausgelöst hat. Genau diese Frage stellt später jemand, und dann ist der Vorfall längst vorbei.
Üben statt dokumentieren
Ein Rückweg wird nicht dadurch belastbar, dass er aufgeschrieben ist. Er wird belastbar, wenn ihn jemand ausgeführt hat, der das Runbook nicht selbst geschrieben hat.
Ein pragmatischer Turnus: einmal im Quartal auf einer produktionsnahen Umgebung die letzte Version zurückrollen, mit Stoppuhr, ohne Vorbereitung, ausgeführt von einer Person aus der Bereitschaft. Gemessen wird nicht, ob es grundsätzlich geht. Gemessen wird, wie lange es dauert und an welcher Stelle jemand nachfragen muss. Beides sind die eigentlichen Ergebnisse der Übung, und beide stehen in keinem Runbook.
Als grobe Messlatte: wenn der Rückweg länger dauert als die Diskussion darüber, ob man ihn gehen soll, wird er im Ernstfall nicht gewählt.
Woran man merkt, dass der Rückweg fehlt
Es gibt ein ziemlich zuverlässiges Signal. In der Diskussion während eines Vorfalls fällt der Satz „zurück ist riskanter als vorwärts“. Manchmal stimmt das und ist eine bewusste Entscheidung. Meistens heißt es, dass niemand genau weiß, was ein Rollback in diesem System auslöst. Der Unterschied zwischen beidem ist die Übung.
Wir arbeiten an drei Feldern: dem Aufbau von Nachweis- und Freigabeketten in Build und Deployment, der Frage, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen, und dem Übergabeproblem nach dem Go-Live, also der Frage, wem ein System eigentlich gehört, wenn das Projekt vorbei ist. Ein festes Angebot daraus entsteht erst, wenn klar ist, was der Kunde wirklich braucht. Kontakt: mm@mhm-dl.de.
Dein Blog zum Thema digitales Business 