Scenarii de recuperare în caz de dezastru

1) De ce este nevoie de DR și care este scopul

Disaster Recovery (DR) este un set de arhitecturi, procese și instruire pentru recuperarea serviciilor după dezastre (eșec centru de date/regiune, pierderi de date, erori de configurare în masă). Scopul DR este de a îndeplini ținta RTO/RPO la costuri și riscuri controlate, menținând în același timp încrederea clienților și respectarea reglementărilor.

Timp de recuperare Obiectiv (RTO) -Allowed downtime.
Obiectiv punct de recuperare (RPO) - pierdere de date admisibilă (timp de la ultimul punct consistent).
RLO (Recovery Level Obiectiv): nivelul de funcționalitate care ar trebui să revină mai întâi (serviciu minim viabil).

2) Clasificarea sistemelor după critică

Nivelul 0 (vital): plăți, autentificare, KYC, tranzacții de bază - RTO ≤ 15 min, RPO ≤ 1-5 min.
Nivelul 1 (ridicat): panouri de operare, rapoarte D-1 - RTO ≤ 1 h, RPO ≤ 15-60 min.
Nivelul 2 (medie): back-office, analiză în timp real - RTO ≤ 4-8 ore, RPO ≤ 4-8 ore.
Nivelul 3 (scăzut): auxiliar non-critic - RTO ≤ 24-72 ore, RPO ≤ 24 ore.

Atribuiți RTO/RPO-uri de nivel + țintă fiecărui serviciu din catalogul de servicii; deciziile și bugetele ar trebui verificate împotriva acestora.

3) Model de amenințare și scenarii

Man-made: eșecul AZ/regiune/furnizor, degradarea rețelei/DNS, baza de date/eșec de stocare, bug-ul de eliberare în masă.
Factor uman: configurații/IaC eronate, ștergerea datelor, compromisuri cheie.
Natural/extern: incendiu/inundații, întreruperi de curent, blocaje legale.
Pentru fiecare - evaluarea probabilității/impactului, legătura cu scenariul DR și playbook.

4) modele de arhitectură DR

1. Active-Active (Multi-Regiune): Ambele regiuni deservesc traficul.

Pro: RTO/RPO minim, stabilitate ridicată.
Dezavantaje: complexitatea/consistența datelor, prețul ridicat.
Unde: încărcături citite, cache, servicii apatride, multi-master DB (reguli stricte de conflict).

2. Activ-pasiv (Hot Standby): O pasivă fierbinte deține o copie complet încălzită.

RTO: minute; RPO: Minute. Necesită eșec automat și replicare.

3. Warm Standby: o parte din resurse sunt încălzite, scalarea în caz de accident.

RTO: zeci de minute; RPO: 15-60 minute. Mai economic, dar mai lung.

4. Lumina pilot: „scânteie” minimă (metadate/imagini/scripturi) + răspândire rapidă.

RTO: ore; RPO: ore. Ieftin, potrivit pentru nivelul 2-3.

5. Backup și restaurare: backup offline + încălzire manuală.

RTO/RPO: ore/zi. Numai pentru critică scăzută și arhive.

5) Date și consecvență

• Sincron - aproape zero RPO, dar ↑latentnost/stoimost.
• Asincron - performanță mai bună, RPO> 0 (coada jurnalelor).
• Consistență: Alegeți un model (puternic/eventual/cauzal). Pentru plăți - strict, pentru analize - eventual.
• Instantanee: Creați puncte consecvente în mod regulat + jurnalele magazinului (WAL/redo).
• Tranzacții transregionale: evitați 2PC; utilizați operațiuni idempotente, deli-și-repeat (încercați din nou cu eliminarea duplicatelor), surse de evenimente.
• Cozi/autobuze: replicare/oglindire, DLQ, comanda și idempotența consumatorilor.

6) Rețea, trafic și DNS

GSLB/Anycast/DNS: politici de eșec/eșec, TTL scăzut (dar nu prea mult), controale de sănătate din mai multe regiuni.
Rutare L7: hărți regionale, steaguri de degradare (restricție de funcție).
Legături private/VPN: canale de backup pentru furnizori (PSP/KYC/CDN).
Limitarea ratei: protecția împotriva furtunii în timpul recuperării.

7) Apatrizi vs apatrizi

Apatridul este transportat prin script/autoscale; statful necesită o strategie de date consistentă (replicare, instantanee, promovare replica, cvorum).
Cache/sesiuni: externe (Redis/Memcached) cu replicare cross-region sau re-semințe de jurnale; țineți sesiuni în token-uri (JWT) sau stocare partajată.

8) DR declanșează și automatizare

Gardrails SLO și sonde cvorum → un runbook automat region-failover.
Schimbarea înghețării în caz de accident: blocați eliberările/migrațiile irelevante.
Infrastructura ca cod: implementarea manifestelor stand-by, verificarea derivei.
Promovarea rolului: automată promova replica DB + scriitori/secretele dressing.

9) Comunicații și conformitate

Cameră de război: IC/TL/Comms/Scribe; Intervale de actualizare SEV.
Status page: geografie de influenţă, ETA, soluţii.
Reglementare: termene de notificare, securitatea datelor, stocarea probelor neschimbabile.
Parteneri/furnizori: contacte confirmate, canal dedicat.

10) Testele și exercițiile DR

Tabletop: Discutarea scenariului și a soluțiilor.
Ziua jocului (etapa/prod-light): simularea eșecului AZ/regiuni, închiderea furnizorului, resetarea DNS.
Restaurați testele: restaurați periodic backup-urile izolate și validați integritatea.
Haos/injecție eșuată: eșecuri controlate de rețea/nod/dependență.
Exercițiu KPI: realizat RTO/RPO, defecte de playbook, CAPA.

11) Selecția finanțelor și strategiei (FinOps)

Numărați $ pentru RPO/RTO redus: cu cât sunt mai mici obiectivele, cu atât sunt mai scumpe canalele, licențele, rezervele.
Hibrid: Tier 0 - activ-activ/fierbinte; Nivelul 1 - cald; Nivelul 2-3 - pilot/rezervă.
Date scumpe: utilizați straturi reci (arhivă/S3/GHEȚAR), instantanee incrementale, duplicare.
Revizuirea periodică a costurilor și certificatelor/licențelor DR-infra.

12) Măsurători de maturitate DR

RTO (real) și RPO (real) pentru fiecare nivel.
Acoperire DR:% din servicii cu un script/playbook/test proiectat.
Succes de backup și restabilirea succesului: succesul zilnic al backup-urilor și restaurărilor dovedite.
Timp-a-declara dezastru: Viteza de decizie failover.
Timpul de întoarcere revine la topologia normală.
Exerciții pentru rata defectelor: au fost găsite lacune/învățături.
Dovezi de conformitate Completitudinea.

13) Liste de verificare

Înainte de implementarea DR

• Directorul de servicii conține Tier, RTO/RPO, dependențe și proprietari.
• Model selectat (AA/AP/WS/PL/BR) de nivel și buget.
• Acordurile de coerență și replicare sunt documentate.
• GSLB/DNS/rutare și controale de sănătate configurate și testate.
• Backup-uri, instantanee, busteni schimbare - activat, verificat pentru restaurare.
• DR playbook-uri și contacte furnizor sunt actualizate.

În timpul accidentului (pe scurt)

• Declarați un SUV și asamblați o cameră de război; congela eliberări.
• Verificați cvorumul sondelor; înregistrează impactul/geografia.
• Executați Failover Runbook: Trafic, Promovare DB, Cozi, Cache.
• Activați degrade-UX/limite; publică actualizări despre SLA.
• Colecta dovezi (cronologie, grafice, busteni, comenzi).

După accident

• Observați SLO din intervalele N; executa eșecul așa cum a fost planificat.
• Conduita AAR/RCA; eliberarea unui CAPA.
• Actualizați cărți de redare, catalizatori de alertă, cazuri de testare DR.
• Raportați părților interesate/autorităților de reglementare (dacă este necesar).

14) Șabloane

14. 1 carte de script DR (exemplu)

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 „Promovarea bazei de date replica” (fragment)

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 Planul de exercitii DR (scurt)

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

„Există copii de rezervă” fără teste regulate de restaurare.
Secretele/criteriile finale nu sunt comutate automat.
Fără idempotență → tranzacții duplicate/pierdute pe redelivery.
Configuraţii identice pentru regiunile fără degradare.
Long-Time-to-Declare de teama de „alarmă falsă”.
Furnizori monoregionali (PSP/KYC) fără alternativă.
Nu există nici un plan de eșec - trăim într-o topologie de urgență „pentru totdeauna”.

16) Foaie de parcurs de implementare (6-10 săptămâni)

1. Ned. 1-2: clasificarea serviciilor pe niveluri, setarea țintă RTO/RPO, alegerea modelelor DR.
2. Ned. 3-4: configurarea replicării/backup-urilor, GSLB/DNS, proceduri de promovare; playbooks și runbooks' și.
3. Ned. 5-6: primele exerciții DR (tabletop→stage), măsurători de fixare și CAPA.
4. Ned. 7-8: Trafic-restricționat exercițiu Prod-Light; automatizare failover.
5. Ned. 9-10: optimizarea costurilor (FinOps), transferul nivelului 0 la cald/AA, exercitarea trimestrială și reglementările de raportare.

17) Linia de jos

DR eficiente nu este doar despre backup-uri. Acestea sunt arhitectura consistentă, automatizarea failover/failback, disciplina datelor (idempotency/replication), instruirea și comunicarea transparentă. Când RTO/RPO-urile sunt reale, cărțile de redare sunt elaborate și exercițiile sunt regulate, dezastrul se transformă într-un eveniment controlat, după care serviciile revin rapid și previzibil la normal.