Scénarios de reprise après sinistre

1) Pourquoi le DR est-il nécessaire et quel est le but

Disaster Recovery (DR) est un ensemble d'architectures, de processus et d'entraînements pour restaurer les services après les catastrophes (échec du centre de données/région, perte de données, erreurs massives de configuration). L'objectif du DR est d'atteindre les objectifs de RTO/RPO à un coût et un risque contrôlés, tout en maintenant la confiance des clients et la conformité à la réglementation.

RTO (Recovery Time Objective) : temps d'inactivité autorisé.
RPO (Recovery Point Objective) : perte de données autorisée (temps depuis le dernier point de cohérence).
RLO (Recovery Level Objective) : niveau de fonctionnalité qui doit revenir en premier (service minimum viable).

2) Classification des systèmes par criticité

Tier 0 (vital) : paiements, login, KYC, noyau des transactions - RTO ≤ 15 min, RPO ≤ 1-5 min.
Tier 1 (haut) : panneaux d'exploitation, rapports D-1 - RTO ≤ 1 h, RPO ≤ 15-60 min.

Tier 2 (moyen) : back-office, analyste proche-temps - RTO ≤ 4-8 h, RPO ≤ 4-8 h

Tier 3 (bas) : auxiliaires non critiques - RTO ≤ 24-72 h, RPO ≤ 24 h.

Attribuer des RTO/RPO cibles à chaque service dans le répertoire de services ; les décisions et les budgets sont exactement avec eux.

3) Modèle de menace et scénarios

Technologique : défaillance AZ/région/fournisseur, dégradation réseau/DNS, défaillance OBD/stockage, bogue de sortie massif.
Facteur humain : configi/IaC erroné, suppression de données, compromission de clés.
Naturel/extérieur : incendie/inondation, coupures d'énergie, blocages légaux.
Pour chacun - évaluer la probabilité/impact, lier au scénario DR et pleybuk.

4) Modèles d'architecture DR

1. Active-Active (Multi-Région) : les deux régions desservent le trafic.

Avantages : Minimum RTO/RPO, haute résilience.
Inconvénients : complexité des données/cohérence, prix élevé.
Où : lecture lourde, charges cachées, services de stateless, DB multi-master (règles strictes de conflit).

2. Active-Passive (Hot Standby) : Le « chaud » passe garde une copie complètement chauffée.

RTO : minutes ; RPO : minutes. Nécessite un failover et une réplication automatisés.

3. Warm Standby : une partie des ressources est échauffée, mise à l'échelle en cas d'accident.

RTO : des dizaines de minutes ; RPO : 15-60 min Plus économique, mais plus long.

4. Pilot Light : « étincelle » minimale (métadonnées/images/scripts) + inversion rapide.

RTO : horloge ; RPO : horloge. Bon marché, convient pour le Tier 2-3.

5. Backup & Restore : backup offline + échauffement manuel.

RTO/RPO : heures-24 heures. Seulement pour la faible criticité et les archives.

5) Données et cohérence

• Synchrone - presque zéro RPO, mais ↑latentnost/stoimost.
• Asynchrone - meilleures performances, RPO> 0 (queue des journaux).
• Cohérence : choisissez un modèle (strong/eventual/causal). Pour les paiements - strictement, pour les analystes - eventual.
• Tranches (snapshots) : créez régulièrement des points constants + stockez des journaux (WAL/redo).
• Transactions transrégionales : éviter les 2PC ; utilisez les opérations idempotentes, deli et répétition (retry avec déduplication), event sourcing.
• Files d'attente/bus : réplication/miroir, DLQ, commande et idempotence des consumers.

6) Réseau, trafic et DNS

GSLB/Anycast/DNS : politiques de failover/failback, TTL bas (mais pas trop), chèques santé de plusieurs régions.
L7-routage : cartes régionales, drapeaux de dégradation ficha (limitation des fonctions).
Liens privés/VPN : canaux de secours vers les fournisseurs (PSP/KYC/CDN).
Limitation des taux : protection contre les tempêtes lors de la récupération.

7) Stateful vs Stateless

Stateless est transporté par le script/auto-skate ; stateful nécessite une stratégie de données cohérente (réplication, snapshots, répliques promotionnelles, quorum).
Cache/sessions : Externe (Redis/Memcached) avec réplication croisée ou re-seed par journal ; les sessions sont conservées en tokens (JWT) ou en stockage commun.

8) Déclencheurs et automatisation DR

Les gardes SLO et le quorum des sondes ont → un runbook de région automatique.
Changer freeze en cas d'accident : nous bloquons les sorties/migrations non pertinentes.
Infrastructure as Code : déploiement de stand-bye par manifeste, vérification de la dérive.
Promotion du rôle : promotion automatique des répliques OBD + pansement writers/secrets.

9) Communications et conformité

War-room: IC/TL/Comms/Scribe; intervalles d'update sur SEV.
Status page : géographie de l'influence, ETA, solutions de contournement.
Réglementation : délais de notification, sécurité des données, stockage inaltérable de l'evidence.
Partenaires/fournisseurs : contacts confirmés, canal dédié.

10) Tests et exercices DR

Tabletop : nous discutons du scénario et des solutions.
Game Day (stead/prod-light) : simulation de panne AZ/régions, désactivation du fournisseur, réinitialisation du DNS.
Tests de restauration : nous restaurons périodiquement les backups en isolement et validons l'intégrité.
Chaos/Failure injection : pannes de réseau/nœuds/dépendances contrôlées.
Exercices KPI : RTO/RPO réalisés, défauts de playbooks, CAPA.

11) Finances et choix stratégiques (FinOps)

Comptez $ par RPO/RTO réduit : plus les objectifs sont bas - plus les canaux, les licences, les réserves sont chers.
Hybride : Tier 0 - active-active/hot ; Tier 1 — warm; Tier 2–3 — pilot/backup.
Les données sont chères : utilisez les couches froides (archive/S3/GLACIER), les snapshots incrémentaux, la déduplication.
Revalorisation périodique des coûts et certificats/licences DR-infra.

12) Mesures de maturité DR

RTO (fait) et RPO (fait) pour chaque Tier.
DR Coverage :% des services avec script/playbook/test.
Backup Success & Restore Success : le succès quotidien des backups et des restaurations éprouvées.
Time-to-Declare Disaster : la vitesse de prise de décision sur l'échec.
Failback Time : retour à une topologie normale.
Defect Rate Enseignements : lacunes/enseignements trouvés.
Compliance Evidence Completeness : l'exhaustivité des artefacts.

13) Chèques-feuilles

Avant la mise en œuvre du DR

• L'annuaire de services contient Tier, RTO/RPO, dépendances et propriétaires.
• Modèle choisi (AA/AP/WS/PL/BR) par Tier et budget.
• Les accords de cohérence et de réplication sont documentés.
• GSLB/DNS/routage et checks de santé configurés et testés.
• Backups, snapshots, journaux de changement - activés, vérifiés sur restore.
• Pleybooks DR et contacts des fournisseurs à jour.

Pendant l'accident (brièvement)

• Déclarer SEV et assembler la salle de guerre ; geler les rejets.
• Vérifier le quorum des sondes ; enregistrer l'impact/la géographie.
• Failover Runbook : trafic, promotion OBD, files d'attente, cache.
• Inclure les degrade-UX/limites ; publier des updates sur SLA.
• Collecter evidence (temps, graphiques, logs, commandes).

Après l'accident

• Observer SLO N intervalles ; failback comme prévu.
• Réaliser l'AAR/RCA ; formaliser le CAPA.
• Mettre à jour les playbooks, les catalyseurs d'alerts, les tests DR.
• Faire rapport aux stackholders/régulateurs (si nécessaire).

14) Modèles

14. 1 Carte de script DR (exemple)

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 "Promotion des répliques OBD' (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 Plan d'exercice DR (résumé)

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-modèles

« Il y a des backups » sans les tests restore réguliers.
Les secrets/endpoints ne changent pas automatiquement.
L'absence d'idempotence → les transactions en double/perdues lors de la livraison répétée.
Les mêmes configues pour les régions sans drapeaux de dégradation.
Long Time-to-Declare par peur de la « fausse anxiété ».
Fournisseurs monorégionaux (PSP/KYC) sans alternative.
Il n'y a pas de plan d'échec - nous vivons dans une topologie d'urgence « pour toujours ».

16) Feuille de route pour la mise en œuvre (6-10 semaines)

1. Ned. 1-2 : classification des services par Tier, installation des cibles RTO/RPO, sélection des patterns DR.

2. Ned. 3-4 : configuration des réplications/backups, GSLB/DNS, procédures de promotion ; playbooks et runbook 'et

3. Ned. 5-6 : premier exercice DR (tabletop→stage), fixation des métriques et CAPA.
4. Ned. 7-8 : exercice d'entraînement avec trafic limité ; l'automatisation de l'échec.
5. Ned. 9-10 : optimisation des coûts (FinOps), transfert de Tier 0 à hot/AA, règlement sur les exercices trimestriels et les rapports.

17) Résultat

Un DR efficace n'est pas seulement un backup. Il s'agit d'une architecture cohérente, de l'automatisation du failover/failback, de la discipline des données (idempotence/réplication), de la formation et des communications transparentes. Lorsque les RTO/RPO sont réels, que les pleybooks sont travaillés et que les exercices sont réguliers, la catastrophe se transforme en un événement gérable après lequel les services reviennent rapidement et de manière prévisible à la normale.