Script di disaster recovery

1) A che serve DR e quale scopo

Disaster Recovery (DR) è un insieme di architetture, processi e allenamenti per il ripristino dei servizi in caso di disastri (guasto del datacentro/regione, perdita dei dati, errori di configurazione di massa). L'obiettivo del DR è quello di eseguire RTO/RPO mirati a costi e rischi controllati, mantenendo la fiducia dei clienti e la conformità alla regolazione.

RTO (Recovery Time Objective) - Tempo di inattività consentito.
RPO (Recovery Point Objective) - Perdita di dati consentita (tempo dall'ultimo punto consistenziale).
RLO (Recovery Level Objective) è il livello di funzionalità che deve essere restituito per primo (servizio minimamente sostenibile).

2) Classificazione dei sistemi per criticità

Tier 0 (vitale): pagamenti, login, KYC, core transazioni - RTO da 15 min, RPO da 1 a 5 min.

Tier 1 (alto): pannelli operativi, report D-1 - RTO di 1 ora, RPO di 15-60 minuti

Tier 2 (media): back office, analista near-real-time - RTO 4-8 ore, RPO 4-8 ore

Tier 3 (basso): non critici - RTO 24-72 ore, RPO-24 ore

Assegnare a ciascun servizio Tier + RTO/RPO mirati nella directory dei servizi; le soluzioni e i budget sono quelli con cui confrontarsi.

3) Modello di minacce e script

Tecnologia: guasto AZ/regione/provider, degrado della rete/DNS, guasto del database/storage, guasto di massa.
Fattore umano: configi/IaC errati, rimozione dei dati, compromissione delle chiavi.
Naturale/esterno: incendio/inondazione, interruzioni di energia, blocchi legali.
Per ciascuno, valutare la probabilità/impatto, associarlo allo script DR e alla playbook.

4) Modelli di architettura DR

1. Active-Active (Multi-Region) - Entrambe le regioni gestiscono il traffico.

Pro: RTO/RPO minimi, alta stabilità.
Contro: complessità dei dati/consistenza, prezzo elevato.
Dove: carichi di lavoro pesanti, memorizzati nella cache, servizi stateless, multi-master DB (regole di conflitto rigorose).

2. Active-Passive (Hot Standby) - Un passivo caldo mantiene una copia completamente riscaldata.

RTO: minuti; RPO: minuti. Richiede failover automatizzato e replica.

3. Parte delle risorse di riscaldamento, ridimensionamento in caso di incidente.

RTO: decine di minuti; RPO: 15-60 min Più economico, ma più lungo.

4. Pilot Light: scintilla minima (metadati/immagini/script) + ruota rapida.

RTO: orologio; Orologio RPO. Economico, adatto per Tier 2-3.

5. Backup & Restore: backup offline + riscaldamento manuale.

RTO/RPO ore/ore. Solo per bassa criticità e archivi.

5) Dati e coerenza

• Sincrona è quasi zero RPO, ma ↑latentnost/stoimost.
• Asincrona: prestazioni migliori, RPO> 0 (coda dei registri).
• Coerenza: seleziona il modello (strong/avvenual/causal). Per i pagamenti - rigorosamente, per gli analisti - avvenual.
• Tagli (snapshots) - Crea regolarmente punti consistenti + memorizza i registri (WAL/redo).
• Transazioni cross-regionali: evitare 2PC; utilizzare le operazioni di idoneità, delhi-e-ripetizione (retry con deduplicazione), event surcing.
• Code/pneumatici: replica/mirroring, DLQ, ordinazione e idimpotenza dei consumer.

6) Rete, traffico e DNS

GSLB/Anycast/DNS: criteri failover/failback, TTL bassi (ma non troppo), health-checks da più regioni.
L7-Routing: mappe regionali, flag flag (limitazione delle funzioni).
Private-links/VPN: canali di backup ai provider (PSP/KYC/CDN).
Rate limiting - Protezione contro la tempesta durante il ripristino.

7) Stateful vs Stateless

Stateless viene spostato da script/scale automatico; stateful richiede una strategia coerente dei dati (replica, snapshot, promozioni di replica, quorum).
Cache/sessione: esterna (Redis/Memcached) con replica crociata o re-seed per registro; tenere le sessioni in token (JWT) o in un archivio condiviso.

8) Trigger e automazione DR

GARDREL e quorum delle sonde → region-failover runbook automatico.
Cambio freeze in caso di incidente - Blocca i rilasci/migrazioni non rilevanti.
Infrastruttura as Code: espansione dello stand-buy per manifesto, verifica della deriva.
Ruoli promozionali: battute automatiche promote database + allacciamento writers/segreti.

9) Comunicazioni e compliance

War-room: IC/TL/Comms/Scribe; intervalli di update per SEC.
Stato pagina - Geografia dell'influenza, ETA, percorsi di aggiramento.
Regolazione: data di notifica, protezione dei dati, invariato evidence.
Partner/provider: contatti confermati, canale dedicato.

10) Test e esercitazioni DR

Tavoletop: discussione su script e soluzioni.
Game Day - Simula il guasto AZ/regioni, disattiva il provider, ripristina il DNS.
Test di restore: ripristiniamo periodicamente i backap in isolamento e valutiamo l'integrità.
Chaos/Failure injection: guasti di rete/nodi/dipendenze controllati.
Esercitazioni KPI: RTO/RPO raggiunti, difetti playbook, CAPA.

11) Finanza e strategia (FinOps)

Contate dollari per RPO/RTO ridotto: più basso è l'obiettivo - più costoso sono i canali, le licenze, le riserve.
Ibrido: Tier 0 - active-active/hot; Tier 1 — warm; Tier 2–3 — pilot/backup.
I dati sono costosi: utilizzare livelli freddi (archivio/S3/GLACIER), snapshot incrementali, deduplicazione.
Ruota periodicamente costi e certificati/licenze DR-infra.

12) Metriche di maturità DR

RTO e RPO per ogni Tier.
DR Coverage:% di servizi con script/playbook/test.
Backup Success & Restore Success: successo quotidiano di backup e ripristini collaudati.
Time-to-Declare Disaster - Velocità di decisione della failover.
Failback Time - Torna alla topologia normale.
Defect Rate Esercitazioni - Spazi/insegnamenti trovati.
Compliance Evidence Completeness: completezza dei manufatti.

13) Assegno fogli

Prima di implementare DR

• La directory dei servizi contiene Tier, RTO/RPO, dipendenze e proprietari.
• È stato selezionato un pattern (AA/AP/WS/PL/BR) per Tier e budget.
• Gli accordi di consistenza e replica sono documentati.
• GSLB/DNS/routing e health-checks sono stati configurati e testati.
• Backup, snapshot, registri delle modifiche - inclusi, verificati su restore.
• Playbook DR e contatti provider aggiornati.

In caso di incidente (brevemente)

• Dichiarare la SEV e assemblare la war-room congelare i comunicati.
• Controllare il quorum delle sonde; fissa l'impatto/geografia.
• Esegui Failover Runbook: traffico, promozione database, code, cache.
• Abilita degrade-UX/limiti; pubblicare update SLA.
• Raccogli evidence (timeline, grafici, logi, comandi).

Dopo l'incidente

• Osservare SLO n intervalli; esegue il failback secondo il piano.
• Eseguire AAR/RCA; formalizzare la CAPA.
• Aggiorna playbook, catalizzatori di alert, valigette di prova DR.
• Riferire agli stakeholder/regolatori (se necessario).

14) Modelli

14. 1 Scheda script DR (esempio)

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 «Promote repliche database» (frammento)

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 Piano di esercitazione DR (breve)

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-pattern

«Ci sono bacapi» senza test di restore regolari.
I segreti/endpoint non cambiano automaticamente.
Nessuna idipotenza di duplicati/transazioni perse durante la ricomposizione.
Confighi identici per le regioni senza flag fiech degrado.
Tempo-to-Declare lungo a causa della paura di «falso allarme».
Provider monoregionali (PSP/KYC) senza alternative.
Nessun piano failback. Viviamo in topologia di emergenza per sempre.

16) Road map di implementazione (6-10 settimane)

1. Ned. 1-2: classificazione dei servizi Tier, installazione di target RTO/RPO, selezione dei pattern DR.
2. Ned. 3-4: configurazione di repliche/backup, GSLB/DNS, promozioni playbook e runbook '.
3. Ned. 5-6: primi esercizi DR (tabletop→stage), fissazione delle metriche e CAPA.
4. Ned. 7-8: esercitazioni prod light con traffico limitato; automazione failover.
5. Ned. 9-10: ottimizzazione dei costi (FinOps), trasferimento di Tier 0 in hot/AA, regolamenti degli esercizi trimestrali e dei rapporti.

17) Totale

Un DOTTOR efficace non è solo un backap. Si tratta di architettura coerente, automazione failover/failback, disciplina dei dati (idampotenza/replica), allenamento e comunicazioni trasparenti. Quando RTO/RPO è reale, le playbook sono lavorate e le esercitazioni sono regolari, il disastro si trasforma in un evento gestito, dopo il quale i servizi tornano alla normalità in modo rapido e prevedibile.