Jeder Pilot übt Durchstarts. Man steigt wieder auf eine sichere Höhe, fliegt die Platzrunde noch einmal und landet, wenn der Anflug stabil ist. Passagiere glauben manchmal, es sei etwas Schlimmes passiert. Fluglehrer sehen darin die richtige Entscheidung, wenn die Bahn belegt war, die Windshear-Warnung losging oder sich der Anflug einfach falsch anfühlte.
Foto von Pixabay auf Pexels
Deploys brauchen dieselbe kulturelle Erlaubnis. Einen Release zu stoppen oder zurückzurollen ist kein moralisches Versagen. Es ist ein Steuereingriff, wenn die Anzeichen sagen: Der Anflug ist instabil.
Warum man zögert
Teams feiern Auslieferung. Metriken belohnen Häufigkeit. Rollback-Buttons existieren, fühlen sich aber oft an, als läge eine Portion Scham daneben. Ich kenne das selbst: Wir haben es schon angekündigt, das Ticket ist „fertig”, die Demo ist morgen.
Die Luftfahrt hat hier einen Vorteil: Durchstarts werden bewertet, nicht zerredet. Man bespricht Fakten. In der Software wird ein abgebrochener Deploy oft zur Geschichte darüber, wer angeblich nervös wurde — selbst wenn das System eindeutig falsch lief.
Ich habe keine perfekte Lösung für Kultur. Ich habe nur Gewohnheiten, die den technischen Teil so langweilig machen, dass der soziale Druck kleiner wird.
Wie ein instabiler Anflug in Produktion aussieht
Nicht jeder Ausschlag bedeutet Stopp. Sonst bekommt man nervöse Rollbacks. Ich suche nach Mustern, die zu dem passen, was wir vor dem Deploy als wichtig festgehalten haben:
Fehlerrate oder Latenz überschreiten vereinbarte Schwellen. Wenn wir SLOs im Change-Ticket notiert haben, nutzen wir sie. Wenn wir nichts notiert haben, raten wir unter Stress — und dann werden Vermutungen laut.
Health Checks schlagen auf neuen Replikas fehl, während alte in Ordnung sind. Kubernetes versucht es weiter. Das ist keine Güte, sondern Beharrlichkeit. Ein Deployment, das mit CrashLoopBackOff im neuen ReplicaSet hängen bleibt, ist eine blinkende Durchstart-Lampe.
Für Kunden sichtbare Symptome im Änderungsfenster. Support-Tickets, Zahlungsfehler, leere Warenkörbe. Korrelation ist keine Kausalität, aber Korrelation direkt nach Image-Tag v2.3.1 verdient Aufmerksamkeit.
Unerwartete Alarme bei Abhängigkeiten. Manchmal ist die Anwendung in Ordnung und die Datenbankmigration nicht. Manchmal hat die Ingress-Änderung Session Affinity kaputt gemacht. Der Deploy ist ein Hebel, aber der Wirkungsradius ist größer.
Bauchgefühl von jemandem, der das System kennt. Ich verehre Intuition nicht, aber ich höre zu, wenn der On-Call-Engineer, der diesen Service seit drei Jahren betreut, sagt: „Das riecht falsch.” Man kann diesen Eindruck mit einer weiteren Prüfung testen, bevor man sich für den vollständigen Rollback entscheidet.
Wenn nichts davon zutrifft: ruhig bleiben, beobachten, keine Heldentaten im Editor. Wenn mehrere Punkte zutreffen: Stoppen ist billiger als Erklären.
Technische Durchstarts in Kubernetes
Die Mechanik hängt davon ab, wie man ausrollt. Die Philosophie ist dieselbe: zu einem bekannt guten Zustand zurück, ohne zwölf Änderungen gleichzeitig zu improvisieren.
Rolling Deployment hängt mitten im Rollout. kubectl rollout undo deployment/<name> ist der sauberste Weg zurück zum vorherigen ReplicaSet, wenn die Controller-Historie intakt ist. Ich prüfe mit kubectl rollout status und sehe nach, ob die alten Pods bereit sind, bevor ich jemandem sage, dass wir wieder stabil sind.
Helm Release, der nie hätte rausgehen sollen. helm rollback <release> <revision>, wenn die Chart-Historie zuverlässig ist. Ich habe Teams gesehen, die keine saubere Revisionsdisziplin hatten und dann Rollback-Punkte suchten, die nie existierten. Das ist ein Prozessproblem mit technischer Maske.
GitOps-Drift. Wenn Argo CD oder Flux einen schlechten Commit synchronisiert hat: Commit zurücknehmen und den Controller wieder abgleichen lassen. Von Hand gegen den Cluster zu kämpfen, während GitOps den schlechten Desired State immer wieder anwendet, macht auf eine ganz eigene Art müde.
Feature Flags versus Image-Deploys. Wenn die Änderung nur über ein Flag kam: Flag aus. Das ist schneller, als die Welt neu zu bauen. Ich halte es trotzdem in der Incident-Timeline fest, denn „wir haben es umgeschaltet” ohne Dokumentation wird schnell Mythologie.
Datenbankmigrationen. Das ist die schwierige Spur. Manche Migrationen gehen nur vorwärts. Ein Durchstart kann bedeuten, die Anwendung zurückzurollen, während das Schema neu bleibt. Dafür braucht man geplante Kompatibilität oder muss den Schmerz akzeptieren. Ich behaupte nicht, dass sich jeder Deploy per Knopfdruck rückgängig machen lässt. Ich sage nur: Man sollte vor dem Ausrollen wissen, in welcher Kategorie man ist, nicht danach.
Blue-Green oder Canary. Abbrechen heißt oft „Datenverkehr zurück” oder „die stabile Farbe wieder aktivieren”. Der Gewinn: Die alte Spur war noch warm. Der Verlust: Niemand hat Abbruchpfade getestet und die Green-Umgebung war schon abgebaut.
Welches Werkzeug auch immer zum Einsatz kommt: Ich sage laut, was ich tue. „Rollback Deployment X auf Revision Y.” Bridges werden ruhiger, wenn Befehle geteilt und nicht heimlich ausgeführt werden.
Das Briefing, bevor man das Manöver braucht
Durchstarts funktionieren, weil Piloten sie vor dem Start besprochen haben. Für Deploys klingt mein Mindestbriefing fast zu klein, um wichtig zu sein:
Was sich ändert, in einem Satz, den ein Mensch wiederholen kann.
Welche Signale wir beobachten, mit Zahlen wenn möglich.
Wer Stopp rufen darf, ohne Komitee.
Wie Rollback aussieht — wer es ausführt und wie wir wissen, dass es funktioniert hat.
Was wir in den ersten zehn Minuten nicht beheben (Begrenzung des Umfangs).
Ich schreibe das ins Change-Ticket, auch wenn niemand es liest, bis etwas wackelt. Gerade dann.
Während des Abbruchs: Disziplin statt Drama
Wenn wir durchstarten, versuche ich, mich so zu verhalten, als hätte die Checkliste das letzte Wort:
Rollout stoppen oder über den vorbereiteten Pfad zurückgehen. Der Versuchung widerstehen, zufällige Umgebungsvariablen „nur zum Test” zu ändern.
Andere Änderungen einfrieren. Deploy-Abbruch plus Secret-Rotation plus Cache-Flush sind drei Variablen. Danach weiß man nicht, welche davon geholfen hat.
Eine Person mitschreiben lassen. Zeitstempel, Befehl, Beobachtung. Das zukünftige Ich ist ein müdes Ich.
Nach Plan kommunizieren. „Wir haben zurückgerollt, die Fehlerrate fällt, Ursache wird untersucht, nächstes Update in fünfzehn Minuten” ist besser als Stille oder eine Nachrichtenflut.
Keine Schuld zuweisen, während sich die Metriken noch bewegen. Verantwortung kann später mit Daten besprochen werden. In den ersten fünf Minuten hilft sie selten.
Ich habe unter Druck jede dieser Regeln gebrochen. Die Regeln helfen trotzdem, wenn ich mich daran erinnere.
Danach: Nachbesprechung ohne Theater
Eine gute Nachbesprechung nach einem Durchstart ist kurz und freundlich:
Was haben wir gesehen, das die Entscheidung auslöste?
War der Auslöser richtig?
Hat der Rollback so funktioniert wie geübt?
Was hätte Abbrechen schneller oder sicherer gemacht?
Was ändern wir vor dem nächsten Versuch?
Ich suche keine Root-Cause-Saga im Bridge-Call. Ich will ein oder zwei Korrekturmaßnahmen mit Verantwortlichen. Vielleicht hat die Readiness-Probe gelogen. Vielleicht war das neue Timeout einer Abhängigkeit zu aggressiv. Vielleicht brauchten wir einen Canary und haben direkt an alle ausgerollt, weil wir es eilig hatten.
Passagiere erinnern sich an sanfte Landungen nach einem Durchstart. Nutzer erinnern sich an Ehrlichkeit und Stabilität. „Wir haben die Änderung zurückgenommen und der Service hat sich erholt” ist ein vollständiger Satz, den viele Teams unterschätzen.
Wenn Abbrechen die falsche Entscheidung ist
Rollback ist nicht gratis. Man kann Inkonsistenzen erzeugen, teilweise Migrationen stranden lassen oder ein Problem verdecken, das beim nächsten Ausrollen wiederkommt. Manchmal ist die richtige Entscheidung eine Korrektur nach vorn mit Feature Flag oder ein Hotfix, den man in Staging getestet hat.
Ich breche ab, wenn die Auswirkungen auf Kunden klar sind und wachsen, wenn der Rollback geübt oder risikoarm ist oder wenn wir den Fehlermodus nicht schnell genug verstehen, um sicher nach vorn zu gehen.
Ich halte die Lage und diagnostiziere weiter, wenn Metriken laut, aber stabil sind, wenn ein Rollback mehr Schaden anrichten könnte als Warten oder wenn das Problem eindeutig unabhängig ist und wir das schnell belegen können.
Dabei falsch zu liegen gehört zum Job. Ziel ist, Fehler reversibel und sichtbar zu machen, nicht heldenhaft.
Persönliche Notiz
Fliegen hat mich gelehrt, dass sich ein Anflug gut anfühlen kann, bis er es nicht mehr tut. DevOps hat mich gelehrt, dass Graphen gut aussehen können, bis jemand hineinzoomt. Ich drücke immer noch ungern auf Rollback. Ausfälle Kunden zu erklären hasse ich mehr.
Wenn das Team Abbrechen als Peinlichkeit behandelt: Einen Deploy in diesem Monat auswählen und die Schritte zum Rückgängigmachen in Staging durchgehen. Festlegen, wer Stopp sagen darf. Einmal üben, damit sich der echte Fall wie Training anfühlt, nicht wie Improvisation.
Ein Durchstart ist kein gescheiterter Flug. Es ist ein Flug, der sich geweigert hat, ein Unfall zu werden. Deploys verdienen dieselbe Würde.
