Disaster Recovery Plan

1) Zweck, Bereich und Grundsätze

Das Ziel: eine zeitnahe Wiederherstellung der IT-Plattform nach Katastrophen (Cyber, Vendor, geopolitisch) zu gewährleisten, ohne die regulatorischen Anforderungen, Verträge und Erwartungen der Spieler zu verletzen.
Bereich: produktive Umgebungen (Spielkontur, Zahlungen, KYC/AML, Betrugsbekämpfung, DWH/BI-Schaufenster), Integrationen (PSP, KYC, CDN, Studios/Aggregatoren), Infrastruktur (Cloud/K8s, Netzwerke, Geheimnisse/Schlüssel), Daten (DB, Dateien, Protokolle).
Prinzipien: Safety-First, RTO/RPO-Minimierung, Automatisierung und Reproduzierbarkeit (IaC), „Default-Nachweisbarkeit“, regelmäßige Übungen.

2) Systemklassifizierung und Wiederherstellungsziele

2. 1 Kritikalitätsstufen

Tier-1 (lebenswichtig): Zahlungen/Kassaaus, Kernspiele, Login/Authentifizierung, CUS/Sanktionen.
Tier-2: Echtzeitanalyse, Marketing/CRM, DWH-Reporting.
Tier-3: interne Portale, Unterstützungsdienste.

2. 2 Ziele

RTO (Recovery Time Objective): Zeit bis zur Wiederherstellung des Dienstes.
RPO (Recovery Point Objective): zulässiger Datenverlust nach Zeit.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual): Die tatsächlichen Werte werden in Berichten erfasst.
MTO/MBCO: maximal übertragbare Ausfallzeit/minimal akzeptables Serviceniveau (degradierter Modus).

• Tier-1 - RTO ≤ 30-60 min, RPO ≤ 15 min; Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч; Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.

3) DR-Strategien und Architektur

3. 1 Topologien

Active-Active (Multi-Region): minimale RTO/RPO, erfordert Konsistenz und Konflikt-Resolve.
Active-Standby (warm/warm/kalt): Kosten-/Geschwindigkeitsbilanz.
Geo-Trennung von Daten und Schlüsseln: KMS/HSM per-region, BYOK, unabhängige Replikationspfade.

3. 2 Daten und Backups

PITR (Point-in-Time Recovery): Transaktionsprotokolle, Archivierungsintervalle ≤ 5-15 Minuten für Tier-1.
Snepshots/Full-Backups: täglich/stündlich, 3-2-1-Speicherung (3 Kopien, 2 Medien, 1 Offline/Offsite).
Immutabilität: WORM/Objekt-Loks, Signatur/Hash-Ketten von Artefakten.
Wiederherstellungsverzeichnis: Backup-Inventar, Integrität, Ablaufdatum, Testtranskriptionen.

3. 3 Anwendungen und Integrationen

Steitles Services: Schnelle Bereitstellung über IaC/CI.
Stateful-Komponenten: abgestimmte Schnappschüsse, Orchestrierung der Startsequenz.
Integrationen (PSP/KYC/Aggregatoren): doppelte Credits, Fallback-Endpoints, signierte Webhooks, Re-Delivery Control (Idempotenz).

4) Wiederherstellungsreihenfolge (allgemeines Runbook)

1. Ankündigung des DR-Skripts → Ernennung von DR Incident Commander (DR-IC), Start des Kriegszimmers.
2. Schadensbeurteilung: betroffene Regionen/Subsysteme, aktuelle RTA/RPA, Failover-Aktivierungsentscheidung.
3. Isolation/Container: Blockierung der ursprünglichen Ursachen (Netzwerk-ACLs, Geheimnisse, Anbieterabschaltung).

• Netzwerk/KMS →
• Datenbank/Speicher/Cache →
• API/Dienste → Front/CDN → externe Integrationen.
• 5. Integritätsprüfung: Konter. Summen, „trockene“ Anfragen, Gesundheitstests.
• 6. Reconciliation Finanzen/Spiele: Abgleich von Zahlungen, Wetten, Salden, idempotente Wiederholung von Operationen.
• 7. Kommunikation: Status-Seite, Spieler/Partner/Regulierungsbehörden; Aktualisierungszeitleiste.
• 8. Beobachtung und Stabilisierung: Deaktivierung von Degradationen im Zuge der Normalisierung.
• 9. Post-mortem: RCA, CAPA, DRP-Update.

5) Spezialisierte Runbooks (Fragmente)

5. 1 Verlust der Kernregion (Active-Standby → Standby)

yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"

5. 2 DB Korruption/Erholung von PITR

yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]

5. 3 PSP Degradation im DR-Modus

yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation

6) Datenintegrität und -wiederherstellung

Finanzen: Abgleich von Einzahlungen/Auszahlungen/Provisionen, erneute Versendung von Benachrichtigungen und Webhooks mit Deduplizierung (idempotency-keys).
Spielkontur: Wiederherstellung der Zustände der Runden, Wiederholung der Berechnungen bei Bedarf, Schutz vor doppelten Abschreibungen/Gebühren.
Logs/Audit: Zuordnung von WORM-Logs „vorher/nachher“, Signaturen/Hashes, Konsistenzberichte.
DSB/Compliance-Bericht: im Falle einer Exposition gegenüber PII - Festlegung des Maßstabs, der Zeitlinie und der Benachrichtigungen.

7) DR für Schlüsseltechnologien (Beispiele)

DBMS (relational): synchrone/asynchrone Replikation, WAL-Steckplätze, Fast-Promote, Hot-Standbays.
NoSQL/Caches: Multicluster, TTL-Behinderung, Kaltbefüllung, Verzicht auf Cross-Region-Write ohne Konflikt-Resolve.
Warteschlangen/Streams: gespiegelte Topics/Cluster, Kontrolle von Offsets, Deduplizierung von Verbrauchern.
Objektspeicher: Versionierung, Replikation in „Bunker“, Objektbestand und Retention-Richtlinien.
CI/CD/Artefakte: Repliken von Registern, Signaturen von Artefakten, Offline-Kopien kritischer Container.
Geheimnisse/Schlüssel: KMS per-region, unabhängige Wurzelschlüssel, break-glass mit logging und TTL.

8) Sicherheit und Datenschutz bei DR

Prinzip der kleinsten Rechte: DR-Zugriffe durch einzelne Rollen/Profile (JIT/PAM).
Immutable Backups: Offline/Offsite, Wiederherstellungs- und Entschlüsselungstest.
Regulatorische Fenster: Erfassung von Ereignissen und Entscheidung über Benachrichtigungen (Regulierungsbehörde/Bank/PSP/Benutzer) zusammen mit Legal/DPO.
Traceability: vollständiges Aktivitätsprotokoll des DR-Teams, Zeitliniensignatur.

9) Übungen und Arten von Tests

Walkthrough/Review: Überprüfung des Dokuments/der Rollen/Kontakte (vierteljährlich).
Tabletop: Ausführen von Szenarien auf „trocken“ mit Konfliktlösung.
Technisch partiell: Wiederherstellung eines einzelnen Dienstes/DB.
Full failover/switch-over: Übertragung von Datenverkehr und Daten in die Backup-Region.
Chaos-Tage (kontrolliert): Fehlerinjektionen zur Überprüfung der Automatik.

Jeder Test → einen Bericht mit RTA/RPA, Abweichungsliste, CAPA und DRP-Update.

10) Metriken (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1): ≥ 95% Übereinstimmungen.
DR Test Coverage: ≥ 2 komplette DR-Tests/Jahr + regelmäßige Teiltests.
Time-to-First-Status: ≤ 15 Minuten nach der Ankündigung von DR.
Reconciliation Zero-Diff: alle Geld- und Spielabgleiche ohne Diskrepanzen.
Backup Integrity: 100% der selektiven Wiederherstellungen sind in einem Quartal erfolgreich.
Config Drift: 0 Drift zwischen primary/secondary (IaC-Vergleich).
Sicherheit im DR: 100% DR-Aktivitäten mit Protokoll und Bestätigung.

11) RACI (vergrößert)

12) Checklisten

12. 1 Bereitschaft zur DR

• DR-Team/Vendor/Regulator-Kontakte aktualisiert
• Grüne Replikation, PITR aktiviert, Test-Entschlüsselung von Backups
• JIT/PAM-Zugänge, „break-glass“ geprüft
• Failover-Playbooks und Umgebungsvariablen sind gültig
• Doppelte Credits/Webhooks PSP/KYC, alternative Routen
• Status-Seite/Nachrichtenvorlagen bereit

12. 2 Während der DR

• DR-IC zugewiesen, offener Kriegsraum, Zeitleiste für Veranstaltungen
• Ursache isolieren, Szenario auswählen, Runbooks starten
• Integritätsprüfungen, Gesundheitstests, Rauchtests
• Erstes öffentliches Update ≤ 15 min; Benachrichtigungen an SLA-Partner/Aufsichtsbehörden
• Erfassung von Artefakten zur Untersuchung

12. 3 Nach DR

• Vollständige Abstimmung von Geld/Spielen und Zeitschriften
• Post-Mortem, RCA, CAPA mit Daten und Eigentümern
• Update DRP/BIA/Pins/IaC
• Plan zur erneuten Prüfung der Fixes

13) Muster (Fragmente)

13. 1 Servicekarte (DR-Pass)

yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]

13. 2 DR-Prüfbericht (Auszug)

yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"

13. 3 Statusnachrichtenvorlage

[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.

14) Umsetzungsfahrplan (6-8 Wochen)

Wochen 1-2: Bestandsaufnahme der Dienste und Abhängigkeiten, Tier-Klassifizierung, RTO/RPO-Ziele, Auswahl der Topologien, DR-Pässe.
Woche 3-4: Implementierung von Backups/PITR/Immutability, Secret Replication/KMS, Vorbereitung von Runbooks und Status.
Wochen 5-6: partielle Tech-Tests (DB/Cache/Warteschlangen), Tabletop nach PSP/KYC/Region-Szenarien.
Woche 7-8: Vollständiger Switch-over (wenn möglich), Bericht mit RTA/RPA, CAPA, DRP-Update und Plan für regelmäßige Tests.

15) Integration mit anderen Wiki-Bereichen

Im Zusammenhang mit: BCP, Risikoregister, Incident Management, Log Policy (WORM), TPRM und SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilege, Passwortrichtlinie und MFA, Change/Release Management.

TL; DR

Funktionierendes DRP = klare RTOs/RPOs nach Tier → Active-Active/Standby-Architektur + immutable Backups/PITRs → reproduzierbare Runbooks und Failover → Geld/Spiel-Reconciliation → regelmäßige Übungen und CAPAs. Dann wird jeder größere Ausfall zu einem überschaubaren Verfahren mit vorhersehbaren Wiederherstellungszeiten und null Überraschungen für Aufsichtsbehörden und Spieler.