Rollback-Strategien
Egal wie sorgfältig getestet wird – jedes Deployment kann theoretisch schiefgehen. Production-Bugs, Performance-Probleme, Inkompatibilitäten mit der Infrastruktur. Die Frage ist nicht „ob", sondern „wann". Daher braucht jedes ernsthafte Deployment einen Rollback-Plan: was tun wir, wenn's kracht?
Diese Lektion zeigt verschiedene Rollback-Arten, das berüchtigte Datenbank-Rollback-Problem, wie Versionierung den Rollback einfacher macht, und welche Best Practices in der Branche etabliert sind. Pflicht-Wissen für jeden der Deployments verantwortet.
1) Was bedeutet Rollback überhaupt?
Ein Rollback ist die Rückkehr von einer neuen Version auf eine vorherige funktionierende Version. Der Begriff stammt aus dem englischen „to roll back" – zurückrollen. Klingt einfach – ist es aber nicht immer.
Der Wunsch beim Rollback: schnell zurück zum funktionierenden Zustand. In der Praxis hängt es von vielen Faktoren ab, wie schnell und sauber das geht:
- Wurde nur Code geändert, oder auch Datenbank-Schema?
- Welche Deployment-Strategie wurde genutzt?
- Gibt es eine Backup-Version irgendwo bereit?
- Sind Konfigurationsänderungen rückgängig zu machen?
- Wie viele Server müssen umgestellt werden?
Rollback ist Risikomanagement: hoffen dass es nie nötig ist, aber bereit sein wenn doch.
2) Drei Hauptarten von Rollback
Es gibt grundsätzlich drei Wege auf ein Production-Problem zu reagieren. Welcher Weg passt, hängt von der Situation ab:
3) Wann Rollback, wann Forward Fix?
Die Entscheidung kann schwierig sein, vor allem unter Stress. Hier eine Entscheidungshilfe als Decision Tree:
4) Rollback bei verschiedenen Deployment-Strategien
Die Geschwindigkeit und Sauberkeit eines Rollbacks hängt stark davon ab, welche Deployment-Strategie du nutzt:
| Strategie | Rollback-Speed | Wie? |
|---|---|---|
| Big Bang | Langsam (Minuten) | Alte Version wieder neu ausrollen → Downtime! |
| Rolling Update | Mittel (Minuten) | Rolling zurück zur alten Version |
| Blue-Green | Sofort (Sekunden) | Load Balancer zurück auf alte Umgebung switchen |
| Canary | Sofort (Sekunden) | Traffic-Anteil auf neue Version → 0% setzen |
| Feature Flags | Sofort (Sekunden) | Flag deaktivieren, Code bleibt deployed |
Genau deshalb sind Blue-Green und Canary bei kritischen Systemen so beliebt: der Rollback ist trivial. Bei einem Big-Bang-Deploy ist Rollback dagegen fast so aufwändig wie das ursprüngliche Deploy – und braucht wieder Downtime.
5) Das Datenbank-Rollback-Problem
Der Albtraum jedes Sysadmins: Datenbank-Migrationen. Während Code-Rollback meist trivial ist (alte Datei wieder hin), ist DB-Rollback oft unmöglich oder destruktiv:
6) Expand-and-Contract: Das Pattern für sichere DB-Migrationen
Die Lösung für das DB-Rollback-Problem heißt Expand and Contract – wir haben es kurz in L2 erwähnt. Hier konkret:
- EXPAND-Phase: Schema wird erweitert ohne Bestehendes zu ändern. Neue Spalten oder Tabellen werden hinzugefügt. Alte bleiben unverändert. Beide App-Versionen können arbeiten.
- Migrations-Phase: Daten werden in die neuen Strukturen kopiert. Hintergrund-Job, ohne Downtime.
- Deploy: App wird auf die neue Version umgestellt. Sie nutzt die neuen Strukturen. Rollback ist hier noch trivial, weil alte Strukturen noch da sind.
- Beobachten: einige Tage bis Wochen warten. Alles stabil? Bestätigt?
- CONTRACT-Phase: alte Strukturen jetzt sicher entfernen. Ab hier ist Rollback nicht mehr möglich, aber das System läuft bereits seit Tagen stabil.
Vorteil: jederzeit Rollback möglich während der kritischen Phase. Nachteil: komplexer und langsamer. Lohnt sich aber bei Production-DBs mit echten Nutzern.
7) Versions-Tagging und Image-Registry
Für sauberen Rollback brauchst du klare Versionierung. Jede Version muss eindeutig identifizierbar und abrufbar sein:
kubectl set image deployment/app app=registry/app:v2.3.5 – fertig. Wichtig: Image-Registry alle alten Versionen aufbewahren. Nicht aggressiv aufräumen. Speicherplatz ist billig im Vergleich zu „Rollback nicht möglich weil Image weg".Best Practice: Semantic Versioning (semver) – `MAJOR.MINOR.PATCH`. Beispiel: `v2.4.0` → `v2.4.1` (Bugfix), `v2.5.0` (Feature), `v3.0.0` (Breaking Change). Plus Git-Commit-SHA als alternativer Tag für genaue Nachverfolgbarkeit (app:abc123def).
8) Rollback in der Praxis: ein typisches Szenario
Schauen wir uns konkret an, wie ein Rollback im Alltag abläuft. Mittwoch nachmittag, neue Version v2.4.0 wurde vor 10 Minuten deployed:
kubectl rollout undo deployment/app – oder beim Blue-Green ein Klick im Load Balancer.9) Automatischer Rollback bei Problemen
Moderne Pipelines können automatisch zurückrollen, wenn Health-Checks fehlschlagen. Das verkürzt die MTTR drastisch – kein Mensch muss reagieren:
Tools die das unterstützen: Argo Rollouts (Kubernetes), Flagger (Istio/K8s), Spinnaker (Netflix). Sie überwachen nach dem Deploy automatisch Metriken und rollen zurück bei Anomalien.
10) Konfiguration und Feature Flags als Rollback-Helfer
Eine elegante Variante: Feature Flags machen Rollback trivial, ohne Code zurückrollen zu müssen:
- Neuer Code wird deployed, aber Feature ist hinter einem Flag versteckt
- Bei Problemen: Flag deaktivieren – Sekundenarbeit, kein Deploy nötig
- Code bleibt live, das Feature ist einfach aus
- Fix entwickeln, Flag wieder aktivieren
Tools wie LaunchDarkly, Unleash, Flagsmith, ConfigCat machen das einfach. In modernen Teams Standard. Code wird ständig deployed, Features werden bewusst aktiviert.
11) Best Practices für Rollbacks
Aus der Praxis – die wichtigsten Punkte:
12) Was Rollback NICHT sein darf
Es gibt einige Anti-Patterns, die du vermeiden solltest:
- „Wir rollen einfach zurück" als Standard-Antwort: dann lernt das Team nichts. Nach Rollback immer Postmortem.
- Rollback ohne Plan: einfach drauflos zurückrollen kann Datenkorruption verursachen. Erst überlegen.
- Rollback bei DB-Migrations ohne Backup: wenn die Migration nicht rückwärtskompatibel war, kann Rollback Daten zerstören.
- Lange Diskussionen: bei Production-Incident nicht 30 Min diskutieren. Klare Roles: einer entscheidet, der Rest unterstützt.
- Rollback in Production ohne Test: zumindest in Staging einmal getestet haben.
- Vergessen, Monitoring nach Rollback zu prüfen: ist das Problem wirklich weg?
13) Disaster Recovery vs. Rollback
Eine wichtige Unterscheidung:
- Rollback: ein gewünschtes Deployment war fehlerhaft, zurück zur vorherigen Version. Minuten.
- Disaster Recovery: katastrophaler Ausfall (Datenbank kaputt, Cloud-Region down, Datenverlust). Stunden bis Tage.
Für DR brauchst du Backups, Snapshots, Multi-Region-Setup. Das ist ein eigenes Thema – siehe K58 Backup und K59 Hochverfügbarkeit. Rollback ist nur ein kleiner Bestandteil davon.
Zusammenfassung
Rollback = Rückkehr zu vorheriger funktionierender Version bei Problemen. Drei Arten: sofort (Sekunden, bei kritischen Fehlern), verzögert (nach Analyse), Forward Fix (Hotfix statt zurück). Decision Tree: bei DB-Migrationen vorsichtig, bei Unsicherheit zurück. Deployment-Strategien: Blue-Green und Canary erlauben Sekunden-Rollback, Big Bang dauert Minuten mit Downtime. DB-Rollback-Problem: oft unmöglich/destruktiv – Lösung ist Expand-and-Contract-Pattern. Versions-Tagging mit Semver + Git-SHA, alte Versionen aufbewahren. Auto-Rollback bei kritischen Metriken (Error-Rate, Latency) durch Tools wie Argo Rollouts, Flagger. Feature Flags als elegante Rollback-Alternative – Code bleibt deployed, Feature wird einfach ausgeschaltet. Best Practices: Plan vor Deploy, Versionierung, regelmäßiges Testen, blameless Postmortem. Rollback ≠ Disaster Recovery.