Plan naprawy klęsk żywiołowych

1) Cel, zakres i zasady

Cel: zapewnienie terminowego odzyskiwania platformy informatycznej po klęskach żywiołowych (tych, cybernetycznych, sprzedawców, geopolitycznych) bez naruszania wymogów regulacyjnych, umów i oczekiwań graczy.
Obszar: środowiska produkcyjne (obwód gier, płatności, KYC/AML, zwalczanie nadużyć finansowych, sklepy DWH/BI), integracje (PSP, KYC, CDN, studia/agregatory), infrastruktura (cloud/K8s, sieci, sekrety/klucze), dane (bazy danych, pliki, dzienniki).
Zasady: bezpieczeństwo-first, minimalizacja RTO/RPO, automatyzacja i odtwarzalność (IaC), „domyślna sprawdzalność”, regularne ćwiczenia.

2) Cele klasyfikacji i odzyskiwania systemów

2. 1 Poziomy krytyczności

Tier-1 (istotne): płatności/gotówki, gry podstawowe, logowanie/uwierzytelnianie, ICC/sankcje.
Tier-2: analityka w czasie rzeczywistym, marketing/CRM, raportowanie DWH.
Tier-3: portale wewnętrzne, usługi pomocnicze.

2. 2 Cele

RTO - Cel dotyczący czasu odzysku

Cel punktu odzysku (RPO) - dopuszczalna utrata danych w czasie.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual) - rzeczywiste wartości są rejestrowane w raportach.
MTO/MBCO: maksymalny tolerowany czas przestoju/minimalny dopuszczalny poziom obsługi (tryb awaryjny).

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

3) Strategie i architektura DR

3. 1 Topologie

Active-Active (multi-region): minimalny RTO/RPO, wymaga spójności i rozwiązywania konfliktów.
Active-Standby (gorący/ciepły/zimny): bilans kosztów/prędkości.
Georozdzielanie danych i klawiszy: KMS/HSM na region, BYOK, niezależne ścieżki replikacji.

3. 2 Dane i kopie zapasowe

PITR (odzyskiwanie w czasie): dzienniki transakcji, okresy archiwizacji ≤ 5-15 minut dla poziomu 1.
Migawki/pełne kopie zapasowe: codziennie/co godzinę, przechowywanie zgodnie z schematem 3-2-1 (3 kopie, 2 media, 1 offline/offsite).
Immutability: zamki WORM/obiektu, łańcuchy podpisu/hash artefaktów.
Katalog odzyskiwania: zapasy zapasowe, integralność, data wygaśnięcia, odszyfrowanie testów.

3. 3 Aplikacje i integracje

Usługi Statles - Szybkie wdrożenie za pośrednictwem IaC/CI

Komponenty Statefull: spójne migawki, orkiestra sekwencji startowej.
Integracje (PSP/KYC/agregatory): podwójne kredyty, punkty końcowe awaryjne, podpisane haki internetowe, kontrola ponownego dostarczenia (idempotencja).

4) Nakaz odzyskania (ogólna książka startowa)

1. Ogłoszenie scenariusza DR → przypisanie DR Incydent Commander (DR-IC), uruchomienie pokoju wojennego.
2. Ocena szkód: dotknięte regiony/podsystemy, obecna RTA/RPA, decyzja o aktywacji feilovera.
3. Izolacja/przechowywanie: blokowanie pierwotnych przyczyn (sieci ACL, tajemnice, odłączenie dostawcy).

• sieć/sekrety/KMS →
• DB/Vault/Cache →
• API/usługi → front/CDN → integracje zewnętrzne.
• 5. Kontrola integralności: licznik. ilości, „suche” żądania, próbki zdrowotne.
• 6. Uzgodnienie finansów/gier: uzgodnienie płatności, zakładów, sald, idempotentne powtarzanie transakcji.
• 7. Komunikacja: strona statusu, gracze/partnerzy/regulatorzy; zaktualizować linię czasu.
• 8. Obserwacja i stabilizacja: dezaktywacja degradacji w wyniku normalizacji.
• 9. Pośmiertnie: RCA, CAPA, aktualizacja DRP.

5) Specjalistyczne książki startowe (snippets)

5. 1 Aktywna gotowość → Czuwanie

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 Korupcja DB/Odzyskanie z 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 degradacja PSP w trybie DR

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) Integralność i pojednanie danych

Finanse: uzgodnienia depozytów/płatności/prowizji, ponowne wysyłanie powiadomień i haków internetowych z deduplikacją (klucze idempotencji).
Kontur gry: odzyskiwanie okrągłych stanów, powtarzanie rozliczeń w razie potrzeby, ochrona przed podwójnymi opłatami/opłatami.
Dzienniki/audyty: przed/po odwzorowaniu dziennika WORM, podpisy/hasła, raporty dotyczące spójności.
IOD/raport zgodności: W przypadku uderzenia PII skala wychwytywania, linia czasowa i powiadomienia.

7) DR dotyczące kluczowych technologii (przykłady)

DBMS (relacyjny): replikacja synchroniczna/asynchroniczna, szczeliny WAL, szybka promocja, gorące standbys.
NoSQL/bufory: wielokrotność, niepełnosprawność TTL, napełnianie na zimno, odrzucenie pisania przekrojowego bez rozwiązywania konfliktów.
Kolejki/strumienie: lustrzane tematy/klastry, kontrola offsetowa, deduplikacja konsumentów.
Przechowywanie obiektów: wersioning, replikacja bunkrów, inwentaryzacja obiektów i zasady retencji.
CI/CD/artefakty: repliki rejestrów, podpis artefaktów, kopie kontenerów krytycznych w trybie offline.
Sekrety/klucze: KMS per-region, niezależne klucze korzeniowe, break-glass z rejestrowaniem i TTL.

8) Bezpieczeństwo i prywatność w DR

Zasada najmniejszych praw: dostęp DR do poszczególnych ról/profili (JIT/PAM).
Niezmienne kopie zapasowe: offline/offsite, test odzyskiwania i odszyfrowywania.
Okna regulacyjne: decyzja o przechwytywaniu zdarzeń i powiadamianiu (regulator/bank/PSP/użytkownicy) wraz z Legal/DPO.
Możliwość śledzenia: pełny dziennik działania polecenia DR, podpis linii czasowej.

9) Ćwiczenia i rodzaje badań

Walkthrough/Recenzja: Dokument/Rola/Przegląd kontaktowy (kwartalnik).
Tablop: uruchom scenariusze „suche” z rozwiązywaniem konfliktów.
Techniczne częściowe: odzyskiwanie pojedynczej usługi/bazy danych.
Pełna awaria/przełączanie - transfer ruchu i danych do regionu kopii zapasowej.
Chaos-days (kontrolowane): zastrzyk awarii/awarii w celu sprawdzenia automatyki.

Każdy test → raport z RTA/RPA, lista odchyleń, CAPA i aktualizacja DRP.

10) Mierniki (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1): 95% mecz ≥.
Zakres badań DR: ≥ 2 pełne badania DR/rok + regularne badania częściowe.
Czas do pierwszego stanu: ≤ 15 min po ogłoszeniu DR.
Pojednanie Zero-Diff: wszystkie uzgodnienia pieniężne i gry bez rozbieżności.
Integralność kopii zapasowej: 100% restauracji spotu odnosi sukces w ciągu jednej czwartej.
Config Drift: 0 dryf pomiędzy pierwotnym/wtórnym (porównanie IaC).
Bezpieczeństwo w DR: 100% czynności DR z dziennikiem i potwierdzeniem.

11) RACI (rozszerzony)

12) Listy kontrolne

12. 1 gotowość DR

• DR Team/Vendor/Regulator kontakty zaktualizowane
• Replication green, PITR enabled, test deszyfrowania kopii zapasowych
• Dostęp JIT/PAM, zweryfikowane szkło łamania
• Fałszywe playbooks i zmienne środowiskowe są ważne
• PSP/KYC Dual Credits/Webhooks, Alternate Routes
• Strona stanu/szablony wiadomości gotowe

12. 2 Podczas DR

• Przypisane DR-IC, otwarta sala wojenna, harmonogram wydarzeń
• Powoduj izolację, skryptowanie, uruchomienie książek startowych
• Kontrole integralności, badania zdrowotne, badania dymu
• Pierwsza aktualizacja publiczna ≤ 15 min; powiadomienia partnerów/organów regulacyjnych o SLA
• Wychwytywanie artefaktów do dochodzenia

12. 3 Po DR

• Pełne pojednanie pieniędzy/gier i czasopism
• Pośmiertnie, RCA, CAPA z datami i właścicielami
• Aktualizacja DRP/BIA/Contact/IaC
• Poprawki do planu powtórnego

13) Szablony (fragmenty)

13. 1 Karta serwisowa (paszport DR)

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 sprawozdanie z badań DR (narażenie)

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 Szablon wiadomości statusu

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

14) Plan działania na rzecz realizacji (6-8 tygodni)

Tygodnie 1-2: wykaz usług i zależności, klasyfikacja poziomu, cele RTO/RPO, wybór topologii, paszporty DR.
Tygodnie 3-4: wdrożenie kopii zapasowych/PITR/immutability, sekretna replikacja/KMS, przygotowanie książek startowych i status.
Tygodnie 5-6: częściowe testy techniczne (baza danych/pamięć podręczna/kolejki), tabletop zgodnie ze scenariuszami PSP/KYC/region.
Tygodnie 7-8: pełne przełączanie (jeśli to możliwe), raport z RTA/RPA, CAPA, aktualizacja DRP i regularny plan testów.

15) Integracja z innymi sekcjami wiki

Link do: BCP, rejestr ryzyka, zarządzanie incydentami, polityka dziennika (WORM), TPRM i SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilege, Zasady hasła i MFA, Zmiana/Zarządzanie zwolnieniami.

TL; DR

Working DRP = clear RTO/RPO by Tier → Active-Active/Standby architecture + immutable backups/PITR → playable runbooks and feilover → reconciliation of money/games → regular exercises and CAPA. Następnie każda poważna awaria zamienia się w zarządzalną procedurę z przewidywalnymi czasami odzyskiwania i zerowymi niespodziankami dla regulatorów i graczy.