Planul de recuperare în caz de dezastre

1) Scop, domeniu de aplicare și principii

Scopul: de a asigura recuperarea la timp a platformei IT după dezastre (cele, cibernetice, furnizoare, geopolitice) fără a încălca cerințele de reglementare, contractele și așteptările jucătorilor.
Zona: medii productive (circuit de jocuri, plăți, KYC/AML, antifraudă, storefronturi DWH/BI), integrări (PSP, KYC, CDN, studiouri/agregatoare), infrastructură (cloud/K8s, rețele, secrete/chei), date (baze de date, fișiere, jurnale).
Principii: safety-first, RTO/RPO minimizare, automatizare și reproductibilitate (IaC), „provability by default”, exerciții regulate.

2) Clasificarea sistemului și obiectivele de recuperare

2. 1 Niveluri critice

Nivelul 1 (vital): plăți/încasări, jocuri de bază, autentificare/autentificare, ICC/sancțiuni.
Tier-2: analiză în timp real, marketing/CRM, raportare DWH.
Tier-3: portaluri interne, servicii auxiliare.

2. 2 Obiective

RTO - Obiectivul timpului de recuperare

Recovery Point Obiectiv (RPO) - pierdere de timp permisă a datelor.
RTA (Timpul de recuperare Real )/RPA (Punct de recuperare Real) - valorile reale sunt înregistrate în rapoarte.
MTO/MBCO: downtime maxim tolerat/nivel minim de serviciu acceptabil (mod degradat).

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

3) DR Strategii și arhitectură

3. 1 Topologii

Activ-activ (multi-regiune): RTO/RPO minim, necesită consecvență și rezolvarea conflictelor.
Active-Standby (cald/cald/rece): echilibru cost/viteză.
Geo-separarea datelor și cheilor: KMS/HSM pe regiune, BYOK, căi independente de replicare.

3. 2 Date și copii de rezervă

PITR (point-in-time recovery): jurnale de tranzacții, intervale de arhivare ≤ 5-15 minute pentru Tier-1.
Instantanee/backup complet: zilnic/oră, stocare în conformitate cu schema 3-2-1 (3 copii, 2 medii, 1 offline/offsite).
Imutabilitate: încuietori WORM/obiect, lanțuri semnătură/hash de artefacte.
Catalog de recuperare: inventar de rezervă, integritate, data expirării, decriptări de testare.

3. 3 Aplicații și integrări

Servicii Statles - Implementare rapidă prin IaC/CI

Componente statefull: instantanee consistente, orchestrarea secvenței de lansare.
Integrări (PSP/KYC/agregatoare): credite duble, puncte finale de rezervă, cărți web semnate, control re-livrare (idempotență).

4) Ordinea de recuperare (runbook general)

1. Declararea unui script DR → atribuirea DR Incident Commander (DR-IC), lansarea unui război-cameră.
2. Evaluarea daunelor: regiunile/subsistemele afectate, actualele RTA/RPA, decizia de activare a feilover-ului.
3. Izolare/izolare: blocarea cauzelor originale (ACL-uri de rețea, secrete, deconectarea furnizorului).

• rețea/secrete/KMS →
• DB/Vault/memorie cache →
• API/servicii → integrări frontale/CDN → externe.
• 5. Verificare integritate: contra. cantități, cereri „uscate”, mostre de sănătate.
• 6. Reconcilierea finanțelor/jocurilor: reconcilierea plăților, pariurilor, soldurilor, repetarea idempotentă a tranzacțiilor.
• 7. Comunicaţii: status page, jucători/parteneri/autorităţi de reglementare; actualizați cronologia.
• 8. Observarea și stabilizarea: dezactivarea degradării pe măsură ce normalizarea are loc.
• 9. Post-mortem: RCA, CAPA, actualizare DRP.

5) Runbooks de specialitate (fragmente)

5. 1 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 Corupția DB/Recuperarea de la 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 degradare în modul 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) Integritatea datelor și reconcilierea

Finanțe: reconcilierea depozitelor/plăților/comisioanelor, re-trimiterea notificărilor și a cărților web cu eliminarea duplicatelor (chei de idempotență).
Conturul jocului: recuperarea stărilor rotunde, repetarea așezărilor, dacă este necesar, protecția împotriva dublei taxe/taxe.
Jurnale/audituri: înainte/după maparea jurnalului WORM, semnături/hash-uri, rapoarte de consistență.
DPO/Raport de conformitate: În caz de impact PII, scala de captare, cronologie și notificări.

7) DR pentru tehnologii cheie (exemple)

DBMS (relațional): replicare sincronă/asincronă, sloturi WAL, promova rapid, standbys fierbinte.
NoSQL/caches: multicluster, TTL-handicap, umplere la rece, respingerea transversală scrie fără conflict-rezoluție.
Cozi/fluxuri: topicaluri/clustere în oglindă, control offset, eliminarea duplicatelor consumatorilor.
Stocarea obiectelor: versioning, replicarea buncărului, inventarul obiectelor și politicile de păstrare.
CI/CD/artefacte: replici ale registrelor, semnătura artefactelor, copii offline ale containerelor critice.
Secrete/chei: KMS pe regiune, taste independente rădăcină, sparge-sticlă cu logare și TTL.

8) Securitate și confidențialitate în DR

Principiul celor mai puține drepturi: DR-accesează prin roluri/profiluri individuale (JIT/PAM).
Backup imuabil: offline/offsite, test de recuperare și decriptare.
Ferestre de reglementare: decizia de captare și notificare a evenimentelor (regulator/bancă/PSP/utilizatori) împreună cu Legal/DPO.
Trasabilitate: jurnal complet de activitate comandă DR, semnătură cronologie.

9) Exerciții și tipuri de teste

Walkthrough/Review: Document/Rol/Contact Review (trimestrial).
Tabletop: rulați scenarii pe „uscat” cu rezolvarea conflictelor.
Parțial tehnic: recuperarea unui singur serviciu/bază de date.
Failover/switch-over complet - transferul de trafic și date în regiunea de rezervă.
Haos-zile (controlat): injectarea de eșecuri/eșecuri pentru a verifica automatica.

Fiecare test → un raport cu o RTA/RPA, lista de abateri, CAPA și actualizarea DRP.

10) Valori (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1): 95% meci ≥.
Acoperire de testare DR: ≥ 2 teste DR complete/an + parțială regulată.
Time-to-First-Status: ≤ 15 min după anunțul DR.
Reconcilierea Zero-Diff: toate reconcilierile cash și joc fără discrepanțe.
Integritate de rezervă: 100% din restaurările spot au succes într-un sfert.
Config Drift: 0 derivă între primar/secundar (comparație IaC).
Securitate în DR: 100% activități DR cu jurnal și confirmare.

11) RACI (mărită)

12) Liste de verificare

12. 1 Pregătirea DR

• Contactele echipei DR/Furnizor/Regulator actualizate
• Verde replicare, PITR activat, test de decriptare de backup-uri
• Accesorii JIT/PAM, verificate prin spargere
• Cărțile de redare false și variabilele de mediu sunt valide
• PSP/KYC Dual Credits/Webhooks, Rute alternative
• Pagina de stare/Șabloane de mesaje gata

12. 2 În timpul DR

• DR-IC atribuit, cameră de război deschis, cronologie eveniment
• Provoca izolarea, scripting, rularea runbooks
• Controale de integritate, teste de sănătate, teste de fum
• Prima actualizare publică ≤ 15 min; notificări către parteneri/autorități de reglementare privind SLA
• Capturarea artefactelor pentru investigare

12. 3 După DR

• Reconcilierea completă a banilor/jocurilor și revistelor
• Post-mortem, RCA, CAPA cu date și proprietari
• DRP/BIA/Contact/IaC Actualizare
• Remediază planul de retestare

13) Șabloane (fragmente)

13. 1 Card de serviciu (pașaport 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 raport de testare DR (expunere)

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 Șablonul mesajului de stare

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

14) Foaie de parcurs de implementare (6-8 săptămâni)

Săptămânile 1-2: inventarul serviciilor și dependențelor, clasificarea nivelului, obiectivele RTO/RPO, selecția topologiei, pașapoartele DR.
Săptămânile 3-4: implementarea de backup-uri/PITR/imutabilitate, replicare secretă/KMS, pregătirea runbooks și starea.
Săptămânile 5-6: teste tehnice parțiale (baze de date/cache/cozi), tabletop conform scenariilor PSP/KYC/regiune.
Săptămânile 7-8: comutare completă (dacă este posibil), raport cu RTA/RPA, CAPA, actualizare DRP și plan de testare regulat.

15) Integrarea cu alte secțiuni wiki

Link către: BCP, Registrul riscurilor, Managementul incidentelor, Politica de jurnal (WORM), TPRM și SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Cel mai mic privilegiu, Politica de parole și MFA, Schimbare/Release Management.

TL; DR

Lucru DRP = clar RTO/RPO de nivel → Active-Active/Standby arhitectura + backup-uri imuabile/PIT → runbooks redate și feilover → reconcilierea banilor/jocuri → exerciții regulate și CAPA-uri. Apoi, orice eșec major se transformă într-o procedură ușor de gestionat cu timpi de recuperare previzibile și surprize zero pentru autoritățile de reglementare și jucători.