Rollback

GitOps (ArgoCD): Wenn du ArgoCD nutzt, drückst du im UI auf "Rollback" (oder revertierst den Git Commit git revert HEAD). ArgoCD merkt: "Ah, das Image soll wieder v1.9 sein". Es ändert das ReplicaSet, killt die v2.0 Pods und startet v1.9 Pods.

Datenbanken (Das Problem): Code Rollback ist einfach (Stateless). Datenbank Rollback ist schwer (Stateful). Wenn v2.0 die Datenbank-Struktur geändert hat (Spalte gelöscht), kann v1.9 nicht mehr lesen! Regel: Datenbank-Änderungen müssen abwärtskompatibel sein. (Erst Spalte hinzufügen, dann Code deployen, dann alte Spalte löschen).

1. Automated Rollback

Warum warten, bis der Kunde anruft? Moderne Deployments (Progressive Delivery) messen während des Updates Metriken (Error Rate). Wenn Error Rate > 1% -> Automatischer Rollback. Tools: Argo Rollouts, Flagger. Der Mensch muss gar nichts tun. Das System heilt sich selbst.

2. The "Point of No Return"

Manchmal ist ein Rollback unmöglich. Beispiel: Du hast Daten verschlüsselt mit einem neuen Key, den die alte Version nicht kennt. Oder du hast eine API migriert, die externe Clients nutzen. Hier hilft nur "Roll Forward" (Fix deployen). Das ist stressig. Vermeide Breaking Changes um jeden Preis!

3. Feature Flags als Alternative

Statt Deployment Rollback (ganze App neustarten): Feature Flag. Du hast den neuen Checkput-Button hinter einem Schalter (if flags.newCheckout == true). Wenn es knallt, legst du den Schalter im Dashboard um (LaunchDarkly). Dauer: Millisekunden. Kein Neustart nötig. Das ist der "Granulare Rollback".

1. Revision History in Kubernetes (Etcd Storage)

Ein Befehl wie kubectl rollout undo impliziert, dass Kubernetes Backups deiner Container-Images hortet. Das ist physikalisch falsch. Was im Hintergrund passiert: Kubernetes verwaltet ReplicaSets (RS). Wenn das Deployment myapp-v1 aktiv ist, liegt dahinter RS-1 (Replicas=3). Beim Update auf v2 schraubt das Deployment RS-1 auf Replicas=0 herunter und skaliert ein feines, brandneues RS-2 auf Replicas=3 hoch (Rolling Update). RS-1 wird nicht gelöscht! Es modert passiv in der Etcd-Key-Value-Tabelle herum (default: die letzten 10 Revisionen). Ein Rollback-Kommando schiebt einfach nur RS-2 auf 0 und knipst RS-1 wieder auf 3 hoch. Das Etcd Manifest referenziert dabei das alte Docker-Image, weshalb der Node das alte Image startet. Kubernetes weiß nicht, was im Image steckt – es manipuliert nur Replica-Drehknöpfchen.

2. Expand and Contract Pattern (Stateful Databases)

Wie rollt man eine PostgreSQL Backend-Spalte risikofrei zurück, ohne Kunden-Logs zu löschen? Mit dem Expand and Contract Pattern (Parallel Change). Phase 1 (Expand): Die DB erhält Spalte Name_Neu. Der alte Code schreibt in Name_Alt, der Trigger kopiert asynchron zu Name_Neu. Ein Rollback des Codes ist 100% sicher. Phase 2 (Migrate): Neuer Code liest primär Name_Neu. Ein Rollback ist weiterhin sicher, da die alte Spalte passiv gepflegt wird. Phase 3 (Contract): Nach 14 Tagen Fehlerfreiheit dropt der DBA endgültig die Spalte Name_Alt. Erst jetzt ist ein Code-Rollback ausgeschlossen (Point of no return).

3. Kafka / Event-Store Re-Replaying

Wie repariert man korrupte Daten, die von einem Bug (v2.0) versehentlich mit -1 Werten in die Datenbank gemergt wurden? Datenbank-Restores (Full Dumps) dauern 18 Stunden. In modernen Event-Sourcing (Kafka, RabbitMQ) Infrastrukturen gibt es kein DB-Restoring. Die Source-of-Truth ist der immutable Kafka-Log ("Event A passierte", "Event B passierte"). Der Rollback Prozess: 1. Man fixt den Code auf v2.1. 2. Man leert brutal die fehlerhafte "Read Model" SQL-Datenbank (TRUNCATE). 3. Man weist Kafka an: "Spiele alle Events der letzten 72 Stunden im Zeitraffer (Re-Stream) durch den neuen, gefixten Code (v2.1) erneut ab." Die Datenbank baut ihren konsistenten Zustand innerhalb weniger Minuten (oder Stunden) selbst auf – State Reconstruction.