Disaster Recovery-Szenarien

1) Warum brauchen Sie DR und was ist der Zweck

Disaster Recovery (DR) ist eine Sammlung von Architekturen, Prozessen und Schulungen zur Wiederherstellung von Diensten nach Katastrophen (Ausfall eines Rechenzentrums/einer Region, Datenverlust, massive Konfigurationsfehler). Das Ziel von DR ist es, gezielte RTOs/RPOs zu kontrollierten Kosten und Risiken durchzuführen und gleichzeitig das Vertrauen der Kunden und die Compliance zu wahren.

RTO (Recovery Time Objective): Zulässige Ausfallzeit.
RPO (Recovery Point Objective): zulässiger Datenverlust (Zeit seit dem letzten konsistenten Punkt).
RLO (Recovery Level Objective): Die Ebene der Funktionalität, die zuerst zurückgegeben werden muss (Minimum Viable Service).

2) Klassifizierung von Systemen nach Kritikalität

Stufe 0 (lebenswichtig): Zahlungen, Login, KYC, Transaktionskern - RTO ≤ 15 min, RPO ≤ 1-5 min.
Tier 1 (hoch): Bedienfelder, Berichte D-1 - RTO ≤ 1 h, RPO ≤ 15-60 min.

Stufe 2 (Durchschnitt): Back-Office, Near-Real-Time Analytics - RTO ≤ 4-8 Stunden, RPO ≤ 4-8 Stunden

Stufe 3 (niedrig): nicht kritische Hilfsstoffe - RTO ≤ 24-72 Stunden, RPO ≤ 24 Stunden

Weisen Sie jedem Dienst Tier + die Ziel-RTOs/RPOs im Servicekatalog zu; Entscheidungen und Budgets mit ihnen zu vergleichen.

3) Bedrohungsmodell und Szenarien

Technogen: AZ/Region/Provider-Ausfall, Netzwerk/DNS-Degradation, DB/Storage-Ausfall, massiver Release-Bug.
Menschlicher Faktor: Fehlerhafte Configs/IaC, Datenlöschung, Schlüsselkompromittierung.
Natürlich/extern: Feuer/Überschwemmung, Energieausfälle, rechtliche Blockaden.
Für jeden - bewerten Sie die Wahrscheinlichkeit/Impact, binden Sie an das DR-Skript und das Playbook.

4) Muster der DR-Architektur

1. Aktiv-Aktiv (Multi-Region): Beide Regionen dienen dem Verkehr.

Vorteile: minimale RTO/RPO, hohe Stabilität.
Nachteile: Komplexität der Daten/Konsistenz, hoher Preis.
Wo: Lese-schwere, zwischengespeicherte Lasten, stateless-Dienste, Multi-Master-DB (strenge Regeln für Konflikte).

2. Aktiv-Passiv (Hot Standby): Ein „heißer“ Passiv hält eine vollständig aufgewärmte Kopie.

RTO: Minuten; RPO: Minuten. Erfordert automatisierten Failover und Replikation.

3. Warm Standby: Teil der Ressourcen aufgewärmt, Skalierung bei einem Unfall.

RTO: Dutzende von Minuten; RPO: 15-60 min. Sparsamer, aber länger.

4. Pilot Light: minimaler „Funke“ (Metadaten/Bilder/Skripte) + schnelle Umkehrung.

RTO: Uhr; RPO: Uhr. Günstig, geeignet für Tier 2-3.

5. Backup & Restore: Offline-Backups + manuelles Aufwärmen.

RTO/RPO: Stunden-Tag. Nur für geringe Kritikalität und Archive.

5) Daten und Konsistenz

• Synchron - fast null RPO, aber ↑latentnost/stoimost.
• Asynchron - bessere Leistung, RPO> 0 (Protokollschwanz).
• Konsistenz: Wählen Sie ein Modell (strong/eventual/causal). Bei Zahlungen streng, bei Analysen eventual.
• Slices (Snapshots): Erstellen Sie regelmäßig konsistente Punkte + speichern Sie Protokolle (WAL/redo).
• Cross-regionale Transaktionen: Vermeiden Sie 2PC; Verwenden Sie idempotente Operationen, Delhi-and-Repeat (Retry mit Deduplizierung), Event-Sourcing.
• Warteschlangen/Busse: Replikation/Spiegelung, DLQ, Order und Consumer Idempotence.

6) Netzwerk, Verkehr und DNS

GSLB/Anycast/DNS: Failover/Failback-Richtlinien, niedrige TTLs (aber nicht zu viel), Gesundheitschecks aus mehreren Regionen.
L7-Routing: regionale Karten, Ficha-Flags der Degradation (Funktionseinschränkung).
Private-Links/VPN: redundante Kanäle zu den Anbietern (PSP/KYC/CDN).
Rate limiting: Sturmschutz bei Bergung.

7) Stateful vs Stateless

Stateless wird vom Skript/AutoScale übertragen; stateful erfordert eine konsistente Datenstrategie (Replikation, Snapshots, Replikatwerbung, Quorum).
Cache/Sitzungen: extern (Redis/Memcached) mit überregionaler Replikation oder Re-Seed durch Protokolle; Sitzungen in Token (JWT) oder gemeinsam genutztem Speicher speichern.

8) Trigger und Automatisierung DR

SLO-Gardrails und Quorum-Sonden → ein automatisches Region-Failover-Runbook.
Wechsel-Freeze bei Crash: Wir blockieren irrelevante Releases/Migrationen.
Infrastruktur als Code: Bereitstellung von Stand-by durch Manifeste, Drift-Check.
Rollenpromotion: Automatische Promotion von DB-Repliken + Writers/Secrets Dressing.

9) Kommunikation und Compliance

War-room: IC/TL/Comms/Scribe; Aktualisierungsintervalle nach SEV.
Status-Seite: Geographie des Einflusses, ETA, Workarounds.
Regulatorisch: Kündigungsfristen, Datensicherheit, unveränderliche Speicherung von evidence.
Partner/Anbieter: bestätigte Kontakte, dedizierter Kanal.

10) DR-Tests und Übungen

Tabletop: Wir diskutieren das Szenario und die Lösungen.
Game Day (Stage/Prod-Light): AZ/Regionen-Ausfall simulieren, Provider abschalten, DNS zurücksetzen.
Restore-Tests: Wir stellen Backups in regelmäßigen Abständen isoliert wieder her und validieren die Integrität.
Chaos/Failure injection: Überwachte Netzwerk-/Knoten-/Abhängigkeitsausfälle.
Übung KPIs: RTO/RPO erreicht, Playbook Defekte, CAPAs.

11) Finanzen und Strategieauswahl (FinOps)

Zählen Sie $ für einen reduzierten RPO/RTO: je niedriger das Ziel - desto teurer sind die Kanäle, Lizenzen, Reserven.
Hybrid: Tier 0 - aktiv-aktiv/heiß; Tier 1 — warm; Tier 2–3 — pilot/backup.
Daten sind teuer: Verwenden Sie kalte Schichten (Archiv/S3/GLACIER), inkrementelle Snapshots, Deduplizierung.
Regelmäßige Überprüfung der Kosten und Zertifikate/Lizenzen von DR-infra.

12) DR Reifegradmetriken

RTO (Fakt) und RPO (Fakt) für jedes Tier.
DR Coverage:% der Dienste mit einem gestalteten Skript/Playbook/Test.
Backup Success & Restore Erfolg: Der tägliche Erfolg von Backups und bewährten Wiederherstellungen.
Time-to-Declare Disaster: Geschwindigkeit der Failover-Entscheidung.
Failback Time: Rückkehr zur normalen Topologie.
Defect Rate Lehren: gefundene Lücken/Lehren.
Compliance Evidence Completeness: Vollständigkeit der Artefakte.

13) Checklisten

Vor der Einführung von DR

• Der Service-Katalog enthält Tier, RTO/RPO, Abhängigkeiten und Besitzer.
• Muster (AA/AP/WS/PL/BR) nach Tier und Budget ausgewählt.
• Konsistenz- und Replikationskonventionen werden dokumentiert.
• GSLB/DNS/Routing und Health-Checks sind eingerichtet und getestet.
• Backups, Snapshots, Änderungsprotokolle - enthalten, auf Restore geprüft.
• DR-Playbooks und Anbieterkontakte in aktueller Form.

Während eines Unfalls (kurz)

• SEV ankündigen und Kriegsraum zusammenstellen; Freigaben einfrieren.
• Überprüfen Sie das Quorum der Sonden; Impact/Geographie aufzeichnen.
• Failover Runbook ausführen: Verkehr, DB-Promotion, Warteschlangen, Cache.
• degrade-UX/Limits aktivieren; Veröffentlichung von Updates per SLA.
• Sammeln Sie evidence (Zeitleiste, Diagramme, Protokolle, Befehle).

Nach einem Unfall

• SLO N-Intervalle beobachten; Failback wie geplant durchführen.
• Durchführung der AAR/RCA; Erstellen Sie eine CAPA.
• Aktualisierung von Playbooks, Alert-Katalysatoren, DR-Testfällen.
• Melden Sie sich bei Stakeholdern/Aufsichtsbehörden (falls erforderlich).

14) Vorlagen

14. 1 DR-Skriptkarte (Beispiel)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook „DB-Repliken fördern“ (Ausschnitt)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 Übungsplan DR (kurz)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) Anti-Muster

„Es gibt Backups“ ohne regelmäßige Restore-Tests.
Secrets/Endpoints werden nicht automatisch umgeschaltet.
Keine Idempotenz → Duplikate/verlorene Transaktionen bei Neulieferung.
Gleiche Configs für Regionen ohne Ficha-Fahnen der Degradation.
Langes Time-to-Declare aus Angst vor „Fehlalarm“.
Monoregionale Anbieter (PSP/KYC) ohne Alternative.
Es gibt keinen Plan für einen Fehlschlag - wir leben in einer Notfall-Topologie „für immer“.

16) Umsetzungsfahrplan (6-10 Wochen)

1. Ned. 1-2: Klassifizierung der Dienste nach Tier, Einstellung der Ziel-RTOs/RPOs, Auswahl der DR-Muster.
2. Ned. 3-4: Konfiguration von Replikationen/Backups, GSLB/DNS, Promotion-Verfahren; Playbooks und Runbooks.
3. Ned. 5-6: erste DR-Übungen (tabletop→stage), Fixierung von Metriken und CAPA.
4. Ned. 7-8: Prod-Light-Übungen mit eingeschränktem Verkehr; Failover-Automatisierung.
5. Ned. 9-10: Kostenoptimierung (FinOps), Übertragung von Tier 0 auf hot/AA, Vorschriften für vierteljährliche Übungen und Berichterstattung.

17) Das Ergebnis

Bei einer effizienten DR geht es nicht nur um Backups. Dies sind eine konsistente Architektur, Failover/Failback-Automatisierung, Datendisziplin (Idempotenz/Replikation), Training und transparente Kommunikation. Wenn RTOs/RPOs real sind, die Playbooks ausgearbeitet sind und die Übungen regelmäßig sind, wird die Katastrophe zu einem überschaubaren Ereignis, nach dem die Dienste schnell und vorhersehbar zur Normalität zurückkehren.