DR-Stratégies et RTO/RPO

1) Principes de base

1. Les objectifs sont avant les fonds. D'abord, nous formulons RTO/RPO et les scénarios critiques, puis nous choisissons la technologie.
2. Segmentation par importance. Tous les services ne nécessitent pas de « l'or » ; diviser par criticité d'entreprise.
3. Les données sont le noyau DR. La consistance, la réplication, la détection des dommages et le point de récupération sont plus importants que le « fer ».
4. Automatisation et vérifiabilité. Le DR n'a aucun sens sans l'IaC, les tests de régression de récupération et la télémétrie.
5. Enseignements et preuves. Un plan sans « jour de jeu » régulier est une illusion de préparation.
6. Sécurité et conformité. Cryptage, isolation, WORM/immutable-backaps, DPA/juridictions.

2) Termes et correspondances

RTO - le temps entre le moment de l'événement et la restauration du service « normal ».
RPO est l'âge du dernier point de données sain lors de la récupération.
RLO (Recovery Level Objective) est un niveau de fonctionnalité qui doit être rétabli (service minimum viable).
MTD (Maximum Tolerable Downtime) est un seuil au-delà duquel une entreprise subit des dommages inacceptables.
RTA/RPA (Actual) - temps réel/point de récupération à partir des pratiques.

Communication : RTO ≤ MTD ; RPA ≤ RPO. L'écart entre les objectifs et les faits est un sujet de post-mortem et d'amélioration.

3) Classes de stratégies DR (niveaux de préparation)

4) Scénarios contre lesquels nous nous défendons

Perte de région/cloud/centre de données (électricité, réseau, fournisseur).
Corruption de données/erreur d'opérateur (suppression, répliques « battues », corruption logique).
Malware/ransomware (ransomware).
Défaut de sortie/configuration (outage de masse).
L'effondrement de la dépendance (KMS, DNS, secrets, fournisseur de paiement).
Événements juridiques (blocage, interdiction de l'exportation des données de la juridiction).

Pour chaque scénario, indiquez le RTO/RPO, le niveau DR, le pleybuc responsable.

5) Stratégies de données (clé du RPO)

5. 1 Becaps

Journaux de transactions complets + incrémentiels + (pour les bases de données).
Stockage immuable/WORM et copie hors ligne (« air-gapped »).
Catalogue de backaps avec métadonnées et sous-écritures cryptées ; récupération de test programmée.

5. 2 Réplication

Synchrone (faible RPO, ↑latentnost, risque de propagation de la détérioration).
Asynchrone (faible effet sur la perf, RPO> 0 ; combiner avec le bébé de la corruption).
CDC (Change Data Capture) pour la réplication en continu et la reconstruction d'état.

5. 3 Protection contre la détérioration logique

Versioning/ » point dans le temps » (PITR) avec fenêtre de ≥ N jours.
Les signatures des invariants (bilans, montants, chexummes) sont un détail précoce des données « battues ».
Canaux de réplication « lents » (delay 15-60 min) comme un tampon contre la détérioration instantanée.

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) Application, état, cache

Couche Statless - Nous mettons à l'échelle et redémarrons dans n'importe quelle région (image/tableau/manifeste dans Git).
État (OBD/cache/kew) : la source de la vérité est l'une des OBD ; les caches et les indices sont transgénériques.
Idempotence et re-drive - la remise répétée des événements est autorisée ; utilisez outbox/inbox, dedup et versions.

7) Réseau et point d'entrée

Failover GSLB/DNS : latency/health-based, court TTL par la fenêtre d'accident.
Anycast/L7-proxy : IP unique, routage sur la santé des régions.
Domaines régionaux et politiques des juridictions (geo-pinning pour PII).
Faiseur de certificats/KMS : chaînes de rechange, double clé.

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) Modèle d'exploitation et automatisation

IaC/GitOps : infrastructure de la deuxième région = code, déploiement « à un seul bouton ».
Policy as Code : gate « Pas de manifeste DR/backup/alert - pas de sortie ».
Runbooks : instructions étape par étape et « bouton rouge », identiques aux deux régions.
Secrets : crédits à court terme, fédération OIDC, plan de compromission/révocation.

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) Exercices et tests (Game Days)

Tableau de script : perte OBD, données « battues », échec KMS, chute de la région, limite egress soudaine.
Fréquence : trimestrielle pour les missions critiques ; une fois tous les six mois - pour les autres.
Exercices métriques : objectifs RTA/RPA vs, proportion d'étapes automatiques, nombre d'interventions manuelles, erreurs de playbook.
Chaos-smoke dans les communiqués : la dégradation des dépendances ne devrait pas « casser » le chemin du 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) Pleybooks (modèle canonique)

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étriques d'observabilité DR

Replica lag (sec.), RPO-drift (différence entre le RPO cible et le RPO réel).
Restore SLI : temps de récupération froid/chaud autour de l'environnement.
Coverage :% des services avec playbacks/backaps/PITR ≥ N jours.
Drill score : proportion d'étapes automatiques, distribution RTA, taux d'erreur.
Immutabilité :% backaps dans WORM/air-gapped.
Métriques d'événement : longueur des files d'attente/vitesse re-drive après le feelover.

12) Coût et compromis

CapEx/OpEx : le stand chaud est moins cher que l'Active/Active, mais plus cher que le Pilot Light.
Egress : la réplication interrégionale/intercalaire coûte de l'argent ; cache/compression/unités locales.
RTO/RPO vs $ : chaque « neuf » de disponibilité et une seconde de RPO coûtent plusieurs fois plus cher - d'accord avec l'entreprise.
Fenêtres vertes : réplication batch - dans une horloge « verte » bon marché.

13) Sécurité et conformité

Cryptage « au repos » et « en transit », domaines KMS séparés par région.
Immutable-backups, protection ransomware : « 3-2-1 » (3 copies, 2 supports, 1 hors ligne), MFA-delete.
Juridictions : géo-pinning pour PII, localisation des backups, Legal Hold sur TTL.
Accès dans le temps : rôles temporaires pour les opérations de DR, journal d'audit.

14) Anti-modèles

« Écrivons un plan plus tard » - DR sans exercice.
Réplication sans protection contre les dommages logiques : Multiplie l'erreur de façon migratoire.
Une région KMS/secrets - pas de faussaire possible.
Backaps sans restaurations régulières - DR « Schredinger ».
Les transactions synchrones étroitement liées entre les régions sont la latence/chute en cascade.
Pas de hiérarchisation : même niveau DR pour tout (cher et inutile).

15) Chèque de l'architecte

1. Les RTO/RPO/RLO par service et par scénario ont-ils été déterminés ?
2. Données classées : source de vérité, PITR/fenêtre, WORM/immutable ?
3. Le niveau DR (Backup/Restore, Pilot, Warm, A/P, A/A) par service est-il sélectionné ?
4. Réseau : GSLB/Anycast, certificats/clés avec stock, drapeaux « read-only » ?
5. Application : idempotence, outbox/inbox compensant les transactions ?
6. IaC/GitOps/Policy as Code : un clic sur le déroulement de la deuxième région ?
7. Exercices : calendrier, KPI RTA/RPA, actions post-formation ?
8. Monitoring : lag, RPO-drift, restore-SLI, drill-score, backups immutables ?
9. Sécurité/conformité : Domaines KMS, juridictions, Legal Hold ?
10. Coût : budget egress, fenêtres « vertes », niveau économiquement raisonnable ?

16) Mini recettes et sketches

16. 1 PITR pour Postgres (idée) :

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 Protection contre la détérioration logique (réplique retardée) :

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

16. 3 Changement de trafic (pseudo-API GSLB) :

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

16. 4 Vérification des invariants après le faucher (pseudo-code) :

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

Conclusion

Le DR est la capacité de prendre des décisions techniques et organisationnelles plus rapidement que les dommages croissants. Définissez des RTO/RPO réalistes, choisissez un niveau de préparation suffisant, automatisez l'infrastructure et les vérifications, entraînez-vous régulièrement et mesurez les RTA/RPA réels. L'accident ne deviendra alors pas une catastrophe, mais un incident géré avec un résultat prévisible.