Disaster Recovery Plan

1) Assegnazione, ambito e principi

Obiettivo: garantire il ripristino tempestivo della piattaforma IT dopo i disastri (quelli cyber, vendor, geopolitici) senza violare i requisiti di regolamentazione, i contratti e le aspettative degli attori.

Area: ambienti produttivi (circuito di gioco, pagamenti, KYC/AML, antifrode, vetrine DWH/BI), integrazione (PSP, KYC, CDN, studi/aggregatori), infrastruttura (cloud/K8s, reti, segreti/chiavi), dati (database, file, logi)

Principi: safety-first, minimizzazione RTO/RPO, automazione e riproduzione (IaC), «prova predefinita», esercizio regolare.

2) Classificazione dei sistemi e obiettivi di ripristino

2. 1 Livelli di criticità

Tier-1 (essenziale): pagamenti/cassauti, core-games, login/autenticazione, CUS/sanzioni.
Tier-2: analisi in tempo reale, marketing/CRM, report DWH.
Tier-3: portali interni, servizi di supporto.

2. 2 Target

RTO (Recovery Time Objective) - Tempo fino al ripristino del servizio.
RPO (Recovery Point Objective) - Perdita di dati in base al tempo consentita.
RTA (Recovery Time Action )/RPA (Recovery Point Actual) - I valori effettivi vengono registrati nei report.
MTO/MBCO: tempo massimo di inattività/livello minimo accettabile del servizio (degraded mode).

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

3) Strategie DR e architettura

3. 1 Topologia

Active-Active (regione multi-t) - RTO/RPO minimo, richiede consistenza e conflitto-resola.
Active-Standby (caldo/caldo/freddo) - bilancia costi/velocità.
Separazione geo tra dati e chiavi: KMS/HSM per-region, BYOK, percorsi di replica indipendenti.

3. 2 Dati e bacap

PITR (point-in-time recovery) - Registri transazioni, intervalli di archiviazione 5-15 min per Tier-1.
Snappshot/full-backap: giornaliero/orologio, storage 3-2-1 (3 copie, 2 supporti, 1 off/off).
Immutabilità: WORM/oggetto, firma/hash chain di manufatti.
Catalogo di recupero: inventario dei backup, integrità, data di scadenza, decrittazione dei test.

3. 3 Applicazioni e integrazioni

Servizi Statles: implementazione rapida attraverso il IaC/CI.
Componenti statful: snap coerente, orchestrazione sequenza di avvio.
Integrazioni (PSP/KYC/aggregatori) - Doppi credency, fallback-endpoint, webhoot firmati, controllo di ricambio (idampotenza).

4) Ordine di ripristino (runbook generale)

1. L'annuncio di uno script DR indica l'assegnazione di un DR-IC (DR-IC) alla war-room.
2. Valutazione danni: regioni/sottosistemi colpiti, aggiornamenti RTA/RPA, decisione di attivazione del feelover.
3. Isolamento/contenitore - Blocca le cause originali (ACL di rete, segreti, disattivazione del provider).

• rete/segreti/KMS
• Database/deposito/cache
• API/servizi fronte/CDN per le integrazioni esterne.
• 5. Controllo integrità contro. importi, richieste «asciutte», provini health.
• 6. Ricomposizione finanziaria/giochi: accoppiamento dei pagamenti, delle scommesse, dei bilanci, riassorbimento idipotente delle transazioni.
• 7. Comunicazioni: status page, giocatori/partner/regolatori; timeline degli aggiornamenti.
• 8. Osservazione e stabilizzazione: disattivazione del degrado alla normalizzazione.
• 9. Post mortem: RCA, CAPE, aggiornamento DRP.

5) Runbooks specializzati (sezioni)

5. 1 Perdita della regione principale (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 Corruzione database/recupero da 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 degrado in modalità 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) Integrità dei dati e recordation

Finanza: controlli di depositi/pagamenti/commissioni, invio ripetuto di notifiche e siti web con deduplicazione (idempotency-keys).
Tracciato di gioco: ripristino degli stati dei round, ripetizione dei calcoli se necessario, protezione da doppi prelievi/addebiti.
Log/verifiche: mappatura dei loghi WORM prima/dopo, firme/hash, report di coerenza.
Rapporto DPO/Compilation: in caso di esposizione al PII, fissa scala, timeline e notifiche.

7) DR per tecnologie chiave (esempi)

DATABASE (relazionale): replica sincrona/asincrona, slot WAL, fast-promote, stand hot.
NoSQL/cache: multiclaster, disabilità TTL, riempimento freddo, abbandono cross-region write senza conflitto-risolte.
Code/striam: mirroring/cluster, controllo degli spostamenti, deduplicazione dei consumatori.
Archivio oggetti: versioning, replica in bunker, inventario degli oggetti e regole di retention.
CI/CD/manufatti - repliche di registri, firma di manufatti, copie off-line di contenitori critici.
Segreti/chiavi: KMS per-region, chiavi radici indipendenti, break-glass con registro e TTL.

8) Sicurezza e privacy in DR

Diritti minimi: Accesso DR da ruoli/profili separati (JIT/PAM).
Backap immutabili: offline/off, test di recupero e decrittazione.
Finestre di regolazione: fissazione degli eventi e risoluzione delle notifiche (regolatore/banca/PSP/utenti) con Legale/DPO.
Tracciabilità: registro completo delle azioni del comando DR, firma timeline.

9) Esercitazioni e tipi di test

Controllo documento/ruoli/contatti (trimestrale)

Tabletop: esegue lo script a secco con la risoluzione dei conflitti.
Technical partial: ripristino di un singolo servizio/database.
Full failover/switch-over - Trasferimento di traffico e dati in una regione di riserva.
Chaos-giorni (controllata): iniezioni di guasti/guasti per la convalida automatica.

Ogni test contiene un rapporto RTA/RPA, un elenco di anomalie, una CAPE e un aggiornamento DRP.

10) Metriche (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1): ≥ 95% delle corrispondenze.
DR Test Coverage: 2 test DR completi/anno + parziali regolari.
Time-to-First-Status: 15 minuti dopo l'annuncio del DR.
Ricomposizione Zero-Different - Tutte le scorciatoie in denaro e gioco senza discrepanze.
Backup Integrity: il 100% dei ripristini selettivi hanno successo nel trimestre.
Config Draft: 0 deriva tra primary/secondary (IaC-confronto).
Sicurezza in DR: 100% azioni DR con registro e conferma.

11) RACI (ingrandito)

12) Assegno fogli

12. 1 Pronto per DR

• Aggiornati contatti DR-team/venditori/regolatori
• Replica verde, PITR abilitato, decrittazione test Becap
• Accesso JIT/PAM, «break-glass» convalidato
• I feelover e le variabili dell'ambiente sono validi
• Doppi crediti/webhoop PSP/KYC, percorsi alternativi
• Stato pagina/modelli di messaggio pronti

12. 2 Durante il DR

• Assegnato DR-IC, aperto war-room, timeline eventi
• Isolamento causa, selezione script, avvio runbooks
• Test di integrità, health-test, smoke-test
• Il primo apdate pubblico è di 15 minuti; notifiche SLA ai partner/regolatori
• Cattura di manufatti per l'indagine

12. 3 Dopo DR

• Accoppiamento completo di denaro/giochi e riviste
• Post mortem, RCA, CAPE con date e proprietari
• Aggiornamento DRP/BIA/contatti/IaC
• Piano di ripetizione dei record

13) Modelli (sezioni)

13. 1 Scheda di servizio (DR-passaporto)

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 Rapporto di prova DR (estratto)

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 Modello di messaggio di stato

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

14) Road map di implementazione (6-8 settimane)

Settimane 1-2: inventario dei servizi e delle dipendenze, classificazione Tier, obiettivi RTO/RPO, scelta delle topologie, passaporto DR.
Settimane 3-4: implementazione di backup/PITR/immutabilità, replica di segreti/KMS, preparazione di runbooks e stato.
Settimane 5-6: dati di prova parziale (database/cache/code), tavoletop su script PSP/KYC/regione.
Settimane 7-8: full switch-over (se possibile), report con RTA/RPA, CAPE, aggiornamento DRP e piano di test regolari.

15) Integrazione con altre sezioni wiki

Collega a: BCP, Registro dei rischi, Gestione incidenti, Politica dei loghi (WORM), TPRM e SLA, ISO 27001/27701, SOC2, PCI DSS, RBAC/Least Privilege, Parol e MFA, Gestione delle modifiche/Gestione delle modifiche con i comunicati.

TL; DR

Il DRP di lavoro = RTO/RPO chiaro su Tier → l'architettura Active-Active/Standby + backup/PITR → riproducibili runbooks e il feelover → → di denaro/giochi, esercitazioni regolari e CAPE. Qualsiasi guasto importante diventa una procedura gestita con tempi prevedibili di recupero e zero sorprese per i regolatori e gli attori.