Case: Platform Disaster Recovery

Lernziele

Nach dieser Lektion kannst du den DR-Case „RTO 1 Stunde, RPO 15 Minuten, Failover von EU nach US” im Interview sauber lösen: Du übersetzt RTO und RPO in konkrete Architekturentscheidungen, kannst Warm Standby gegen Active-Active und Cold Standby abgrenzen, weißt, warum GitOps das DR-Konzept radikal vereinfacht — und warum die Datenbank-Replikation trotzdem der schwerste Teil bleibt. Außerdem kannst du erklären, warum ein ungetesteter DR-Plan keiner ist.

Das Szenario: Frankfurt fällt aus

Die Aufgabe: „Designe Disaster Recovery für unsere Kubernetes-Plattform. Primärregion ist EU (Frankfurt), DR-Region US (Virginia). RTO 1 Stunde, RPO 15 Minuten.”

Erster Schritt im Interview: die beiden Kennzahlen übersetzen, denn sie diktieren die gesamte Architektur. RTO (Recovery Time Objective) = 1 Stunde heißt: Eine Stunde nach Ausrufung des Desasters muss die Plattform in Virginia produktiv sein. RPO (Recovery Point Objective) = 15 Minuten heißt: Maximal die letzten 15 Minuten an Daten dürfen verloren gehen. Daraus folgt unmittelbar: Backups, die täglich laufen, verfehlen das RPO um Größenordnungen — du brauchst kontinuierliche oder mindestens viertelstündliche Replikation. Und ein Cluster, der im Notfall erst provisioniert wird, frisst dein RTO womöglich komplett auf.

Anforderungen klären: Was genau muss überleben?

Die Klärungsfragen, die diesen Case strukturieren:

1. Wogegen schützen wir uns? Regionsausfall ist das Szenario — aber gilt der Plan auch für schleichende Ausfälle (Region degradiert, fällt aber nicht komplett aus)? Die Entscheidung „Failover ja/nein” ist bei Grauzonen-Ausfällen das eigentlich Schwere.
2. Was gehört alles zur Plattform? Cluster, GitOps-State, Secrets, Container-Registry, Monitoring, DNS. Wer nur an die Cluster denkt, steht in Virginia mit leeren Händen da: keine Images, keine Secrets, keine Deployment-Definitionen.
3. Wie viele Anwendungen haben State? Im Szenario: Stateless-Apps unkritisch, fünf Stateful-Apps mit Datenbanken. Diese fünf sind 80 % der Arbeit.
4. Gelten RTO/RPO für alles gleich? Fast nie. Frage nach Tiering: Vielleicht brauchen zwei kritische Apps die 1h/15min, der Rest darf 4h/1h. Das spart erheblich Geld.
5. Wer entscheidet den Failover? Automatisch oder per Mensch? Bei einem so drastischen Schritt (Region wechseln, Datenverlust akzeptieren) ist eine dokumentierte menschliche Entscheidung mit klaren Kriterien meist die richtige Antwort — automatisiert wird die Durchführung, nicht die Entscheidung.

Architektur: Warm Standby mit GitOps als Wahrheitsquelle

Standby-Modell. Drei Optionen mit klarem Trade-off zwischen Kosten und RTO: Cold Standby (nichts läuft, alles wird im Notfall provisioniert) ist billig, aber Cluster-Provisionierung, Bootstrapping und App-Sync sprengen eine 1-Stunden-RTO zu leicht. Active-Active (beide Regionen bedienen Traffic) liefert RTO nahe null, verdoppelt aber laufende Kosten und zwingt dich bei den Datenbanken in Multi-Region-Schreibkonflikte. Warm Standby ist der Sweet Spot für 1h/15min: In Virginia läuft ein kleiner, fertig gebootstrappter Cluster mit synchronisierter Konfiguration, der im Notfall hochskaliert wird. Diese Begründung über die Zahlen — nicht über Bauchgefühl — ist der Kern der Interview-Antwort.

GitOps als DR-Fundament. Wenn der gesamte Soll-Zustand der Plattform — Apps, Konfiguration, Policies — in Git liegt und Argo CD oder Flux ihn anwenden, ist die Wiederherstellung der Workload-Definitionen trivial: Der DR-Cluster zeigt auf dieselben Repos. Git selbst muss natürlich regionsausfallsicher sein (gehostete Anbieter wie GitHub sind es; selbst gehostetes GitLab braucht eigene Geo-Replikation). Damit schrumpft das DR-Problem auf das, was nicht in Git liegt: Daten, Secrets, Images.

Die vier Zustandsspeicher einzeln:

• Persistente Daten: Für die fünf Stateful-Apps native Datenbank-Replikation (z. B. PostgreSQL Streaming Replication oder die Cross-Region-Replikation eines Managed Service) — asynchron, was bei 15 Minuten RPO in Ordnung ist. Velero ergänzt als Backup für PersistentVolumes und Cluster-Ressourcen in einen S3-Bucket mit Cross-Region-Replikation — als zweite Verteidigungslinie, nicht als primärer RPO-Mechanismus.
• Secrets: Vault mit Replikation in die DR-Region (Replikation ist ein Vault-Enterprise-Feature — im Interview erwähnen, das zeigt Praxiserfahrung). Alternative ohne Enterprise: Secrets via External Secrets Operator aus einem regionsübergreifend replizierten Cloud-Secret-Store beziehen.
• Images: Registry mit Cross-Region-Replikation (ECR-Replikationsregeln oder Harbor-Replikation). Ein Failover, bei dem kein Image gezogen werden kann, scheitert in Minute fünf.
• Traffic: DNS-Failover via Route 53 mit Health Checks — niedrige TTL (z. B. 60 Sekunden) vorher setzen, sonst kleben Clients an Frankfurt.

Der Failover-Ablauf als Runbook: Entscheidung treffen → DR-Cluster hochskalieren (Terraform/Autoscaler) → Datenbanken in Virginia zum Primary promoten → Argo CD synct Apps → Smoke-Tests → DNS umschalten. Jeder Schritt mit Verantwortlichem und Zeitbudget; die Summe muss mit Puffer unter 60 Minuten liegen. Grobe Rechnung laut aussprechen: Skalierung 10–15 min, DB-Promotion 5–10 min, Sync 10–15 min, Tests + DNS 10 min ≈ 45 Minuten — knapp, aber machbar, und genau deshalb kein Cold Standby.

Einwände des Interviewers

„Woher weißt du, dass das in einer Stunde klappt?” — Gar nicht, solange es nicht geprobt ist. Quartalsweise Game Days, bei denen der Failover real durchgespielt wird (mindestens gegen Staging, idealerweise mit echtem Produktions-Failover-Test), und die gemessene Zeit als Report. Ein DR-Plan ohne Testtermin ist ein Dokument, kein Plan.

„Was kostet das?” — Warm Standby grob abschätzen: kleiner Standby-Cluster plus Replikationstraffic plus duplizierte Registry/Secrets — als Daumenwert 20–40 % der Primärregion-Computekosten, abhängig davon, wie warm der Standby ist. Dann der Konter: „Wenn das zu teuer ist, verhandeln wir RTO/RPO pro App-Tier neu — DR-Kennzahlen sind eine Business-Entscheidung.”

„Failback?” — Oft vergessen: Nach dem Desaster läuft Produktion in Virginia und Frankfurt muss aus Virginia zurückrepliziert werden, bevor man zurückschwenkt. Failback ist ein zweiter, geplanter Failover — gehört ebenfalls ins Runbook und in den Game Day.

„Was ist mit Split-Brain?” — Wenn Frankfurt nur partiell ausfällt und beide Datenbanken Schreiblast annehmen, hast du divergierende Daten. Deshalb: explizite Promotion mit Fencing (alter Primary wird gestoppt/isoliert, bevor der neue schreibt), keine automatische Doppel-Promotion.

Praxis

45 Minuten, Whiteboard. Diese fünf Punkte müssen vorkommen:

1. RTO/RPO in Architekturkonsequenzen übersetzen (warum Warm Standby, warum keine Tagesbackups)
2. Die vier Zustandsspeicher: Daten, Secrets, Images, DNS — jeder mit Mechanismus
3. GitOps als Wiederherstellungspfad für Workload-Definitionen
4. Failover-Runbook mit Zeitbudget pro Schritt und Gesamtrechnung < 60 min
5. Test-Regime: Game Days mit gemessener Failover-Zeit

Zusatz: Schreibe das Runbook als nummerierte Liste mit realistischen Minutenangaben und prüfe, ob du unter 60 bleibst.

Typische Stolperfallen

Nur Compute denken. Cluster sind ersetzbar; der Wert steckt in Daten, Secrets, Images und DNS. Wer diese vier nicht einzeln adressiert, hat keinen DR-Plan.

Velero als RPO-Lösung verkaufen. Backup-Intervalle und Restore-Dauer passen selten zu 15 Minuten RPO bei Datenbanken — dafür ist Replikation da. Velero ist die zweite Verteidigungslinie (und schützt zusätzlich gegen Fälle, die Replikation nicht abdeckt, etwa versehentliches Löschen, das mitrepliziert würde).

Failover automatisieren, Entscheidung auch. Ein False Positive im Health Check, der automatisch eine Region evakuiert, ist selbst ein Desaster. Durchführung automatisieren, Entscheidung dokumentiert beim Menschen lassen.

Failback und DNS-TTL vergessen. Beides fällt erst im Ernstfall auf — also genau dann, wenn es zu spät ist.

Interview-Vorbereitung

Kernbotschaft: „RTO 1h und RPO 15min erzwingen Warm Standby mit kontinuierlicher Replikation; GitOps reduziert DR auf Daten, Secrets, Images und DNS — und ohne regelmäßige Game Days ist jede RTO-Zusage Fiktion.”

Rechne mit diesen Follow-ups:

• „Warum nicht Active-Active?” — Doppelte Kosten und Multi-Region-Schreibkonflikte bei den Datenbanken; bei 1h RTO nicht nötig. Bei RTO im Minutenbereich würde ich es neu bewerten.
• „Wie kommst du an konsistente Datenbank-Backups?” — Native DB-Mechanismen (Snapshots/WAL-Archivierung) statt Volume-Snapshots unter laufender Last; Restore regelmäßig testen.
• „Was repliziert dein RPO wirklich?” — Asynchrone Replikation heißt: RPO = Replikationslag. Den Lag monitoren und alarmieren, wenn er sich 15 Minuten nähert.
• „Erster Schritt, wenn du morgen anfängst?” — Inventur: Was liegt heute nicht in Git, und welche der fünf Stateful-Apps hat noch keine Replikation? Dann das Runbook schreiben und den ersten Game Day terminieren.

Zusammenfassung

DR-Design beginnt bei den Kennzahlen: 1h/15min bedeutet Warm Standby, kontinuierliche Replikation für die fünf Stateful-Apps, replizierte Registry und Secrets, DNS-Failover mit niedriger TTL — und GitOps macht die Workload-Seite fast trivial. Der Plan steht und fällt mit dem Runbook samt Zeitbudget und mit Game Days, die die RTO real messen. In der nächsten Lektion bleibt die Plattform online, aber das Geld brennt: FinOps für 40 Teams mit dem Ziel 30 % Kostensenkung.