Strategii DR și RTO/RPO

1) Principii de bază

1. Obiective înainte de mijloace. În primul rând, vom formula RTO/RPO și scenarii critice, apoi selectați tehnologia.
2. Segmentarea după importanţă. Nu toate serviciile necesită „aur”; împărțiți după critica afacerilor.
3. Datele sunt nucleul DR. consistența, replicarea, detectarea corupției, și punctul de recuperare sunt mai importante decât hardware.
4. Automatizare și verificabilitate. DR este lipsit de sens fără IaC, teste de regresie de recuperare, și telemetrie.
5. Învăţături şi dovezi. Un plan fără „zi de joc” regulat este o iluzie de pregătire.
6. Siguranţă şi conformitate. Criptare, izolare, WORM/copii de rezervă imuabile, DPA/jurisdicții.

2) Termeni și corespondențe

RTO - timp din momentul evenimentului până la restabilirea serviciului „normal”.
RPO este „vârsta” ultimului punct de date sănătos la recuperare.
RLO (Recovery Level Obiectiv) - nivelul de funcționalitate care trebuie restabilit (serviciu minim viabil).
MTD (Maxim Tolerable Downtime) - pragul după care afacerea suferă daune inacceptabile.
RTA/RPA (Actual) - timp efectiv/punct de recuperare din practici.

Comunicare: RTO ≤ MTD; RPA ≤ RPO. Diferența dintre obiective și fapt este subiectul post-mortem și îmbunătățire.

3) cursuri de strategie DR (niveluri de pregătire)

4) Scenarii împotriva cărora ne apărăm

Pierderea regiunii/cloud/centru de date (electrice, rețea, furnizor).
Corupția datelor/eroarea operatorului (ștergere, replici rupte, corupție logică).
Malware/ransomware.
Defect de eliberare/configurare (întrerupere în masă).
Colapsul dependenței (KMS, DNS, secrete, furnizor de plăți).
Evenimente juridice (blocarea, interzicerea exportului de date din jurisdicție).

Pentru fiecare scenariu, specificați RTO/RPO, nivelul DR, playbook, persoane responsabile.

5) Strategii de date (cheie pentru RPO)

5. 1 Copii de rezervă

Jurnale complete + incrementale + tranzacții (pentru DB).
Depozite imuabile/WORM și copii offline („gapped aer”).
Catalog de copii de rezervă cu metadate și semnături cripto; testul programat restabilește.

5. 2 Replicare

Sincron (RPO scăzut, ↑latentnost, risc de propagare a stricului).
Asincron (impact scăzut asupra perf, RPO> 0; se combină cu copilul răsfățat).
CDC (Change Data Capture) pentru replicarea în streaming și reconstrucția stării.

5. 3 Protecția împotriva corupției logice

Versioning/” puncte în timp” (PITR) cu o fereastră ≥ zile N.
Semnăturile invariante (solduri, sume, chexuri) sunt o detectare timpurie a datelor „rupte”.
„Lent” canale de replicare (întârziere 15-60 minute) ca un tampon împotriva corupției instantanee.

python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)

6) Aplicarea, starea, memoria cache

Strat apatrid - scalați și reporniți în orice regiune (imagine/diagramă/manifeste în Git).
Status (DB/caches/kew): sursa adevărului este una dintre DB-uri; cache-urile şi indicii sunt generabili.
Idempotența și re-drive-ul - re-livrarea evenimentelor este permisă; utilizați outbox/inbox, dedup și versiuni.

7) Punctul de rețea și de intrare

GSLB/DNS-feilover: latență/bazate pe sănătate, scurt TTL la fereastra de accident.
proxy Anycast/L7: IP unic, rutare regională a sănătății.
Domenii regionale și politici jurisdicționale (geo-pinning pentru PII).
Fișier certificat/KMS: lanțuri de rezervă, cheie dublă.

python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()

8) Model de operare și automatizare

IaC/GitOps: a doua infrastructură regională = cod, implementare „singur buton”.
Policy as Code: gate „no DR manifest/backup/alerts - no release”.
Runbooks: instrucțiuni pas cu pas și un „buton roșu” identic cu ambele regiuni.
Secrete: credite de scurtă durată, federația OIDC, plan de compromis/rechemare.

rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}

9) Exerciții și teste (Zilele Jocului)

Tabel de scenarii: pierderea bazei de date, date „rupte”, eșecul KMS, scăderea regiunii, limita bruscă de ieșire.
Frecvență: trimestrial pentru misiune critică; o dată la șase luni - pentru restul.
Măsurarea exercițiilor: RTA/RPA vs goluri, proporția de pași automați, numărul de intervenții manuale, erori de playbook.
Haos-fum în eliberări: degradarea dependenței nu ar trebui să „rupă” căile DR.

T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements

10) Playbooks (șablon canonic)

yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"

11) măsurători de observabilitate DR

Replica lag (sec), RPO-drift (diferența dintre țintă și RPO real).
Restabili SLI: timp de recuperare rece/cald de mediu.
Acoperire:% din serviciile cu playbook-uri/backup-uri/PITR ≥ zile N.
Scorul burghiului: proporția de pași automați, distribuția RTA, rata de eroare.
Imutabilitate:% din copii de rezervă în WORM/aer-gapped.
Măsurătorile evenimentului: lungimea cozii/viteza re-drive după fals.

12) Costuri și compromisuri

CapEx/OpEx: Suportul cald este mai ieftin decât Active/Active, dar mai scump decât Pilot Light.
Ieșire: replicarea inter-regională/inter-cloud costă bani; cache/compresie/agregate locale.
RTO/RPO vs $: fiecare „nouă” de disponibilitate și o secundă de RPO sunt de mai multe ori mai scumpe - se coordonează cu afacerea.
Ferestre verzi: replicarea loturilor - în ore ieftine/” verzi„.

13) Siguranță și conformitate

Criptarea „în repaus” și „în tranzit”, separarea domeniilor KMS pe regiuni.
Backup-uri imuabile, protecție ransomware: „3-2-1” (3 copii, 2 medii, 1 offline), MFA-delete.
Jurisdicții: geo-pinning pentru PII, localizarea backup-uri, Legal Hold pe partea de sus a TTL.
Accesări în timp: roluri temporare pentru operațiuni DR, jurnal de audit.

14) Anti-modele

„Să scriem un plan mai târziu” - DR fără exerciții.
Replicarea fără protecție împotriva corupției logice - va multiplica instantaneu eroarea.
O regiune KMS/secrete - nu feilover posibil.

Copii de rezervă fără restaurări regulate - „Shredinger” DR

Tranzacțiile sincrone strâns legate între regiuni sunt latență/cădere în cascadă.
Fără prioritizare: același nivel DR pentru tot (scump și inutil).

15) Lista de verificare arhitect

1. Definit RTO/RPO/RLO în funcție de serviciu și scenariu?
2. Date clasificate: sursa adevarului, PITR/fereastra, WORM/imuabil?
3. Este DR (Backup/Restore, Pilot, Warm, A/P, A/A) per serviciu selectat?
4. Rețea: GSLB/Anycast, certificate/chei cu o marjă, steaguri read-only?
5. App: idempotence, outbox/inbox, compensarea tranzacțiilor?
6. IaC/GitOps/Policy as Code: un singur clic pe rularea a doua regiune?
7. Burghiu: Program, KPI RTA/RPA, activități post-formare?
8. Monitorizare: lag, RPO-drift, restore-SLI, drill-score, backup-uri imuabile?
9. Securitate/Conformitate: Domenii KMS, Jurisdicții, Deținere legală?
10. Cost: buget de ieșire, ferestre verzi, nivel de sunet economic?

16) Mini rețete și schițe

16. 1 PITR pentru Postgres (idee):

bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...

16. 2 Protecția împotriva corupției logice (replica întârziată):

yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption

16. 3 Comutarea traficului (GSLB pseudo-API):

bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 100

16. 4 Verificarea invarianţilor după feilover (pseudocod):

python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))

Concluzie

DR este capacitatea de a lua decizii tehnice și organizaționale mai repede decât daunele cresc. Identificați RTO/RPO-uri realiste, selectați disponibilitatea suficientă, automatizați infrastructura și verificările, exercitați în mod regulat și măsurați RTA/RPA-urile reale. Apoi accidentul nu se va transforma într-un dezastru, ci într-un incident controlat cu un rezultat previzibil.