Disaster Recovery Plan

1) Destination, domaine et principes

Objectif : assurer la reprise rapide de la plate-forme informatique après les catastrophes (cyber, vendoriennes, géopolitiques) sans violer les exigences réglementaires, les traités et les attentes des acteurs.
Environnement productif (circuit de jeu, paiements, KYC/AML, antifrod, vitrines DWH/BI), intégration (PSP, KYC, CDN, studios/agrégateurs), infrastructure (cloud/K8s, réseaux, secrets/clés), données (OBD, fichiers, logs)).
Principes : safety-first, minimisation RTO/RPO, automatisation et reproductibilité (IaC), « prouvabilité par défaut », exercices réguliers.

2) Classification des systèmes et objectifs de récupération

2. 1 Niveaux de criticité

Tier-1 (vital) : paiements/cassaouts, core-games, login/authentification, CUS/sanctions.
Tier-2 : analyse en temps réel, marketing/CRM, reporting DWH.
Tier-3 : portails internes, services auxiliaires.

2. 2 Objectifs

RTO (Recovery Time Objective) : temps avant la restauration du service.
RPO (Recovery Point Objective) : perte de données en temps valide.
RTA (Recovery Time Actual )/RPA (Recovery Point Actual) : les valeurs réelles sont enregistrées dans les rapports.
MTO/MBCO : temps d'arrêt le plus tolérable possible/niveau de service minimum acceptable (mode dégradé).

• Tier-1 - RTO ≤ 30-60 min, RPO ≤ 15 min ; Tier-2 — RTO ≤ 4 ч, RPO ≤ 1 ч; Tier-3 — RTO ≤ 24 ч, RPO ≤ 24 ч.

3) Stratégies de RD et architecture

3. 1 Topologies

Active-Active (multi-région) : RTO/RPO minimum, nécessite consistance et conflit-résolve.
Active-Standby (chaud/chaud/froid) : équilibre coût/vitesse.
Géo-séparation des données et des clés : KMS/HSM per-region, BYOK, chemins de réplication indépendants.

3. 2 Données et backups

PITR (point-in-time recovery) : journaux de transaction, intervalles d'archivage ≤ 5-15 min pour Tier-1.
Snepshots/full-backup : journaliers/heures, stockage selon le schéma 3-2-1 (3 copies, 2 supports, 1 hors ligne/offsite).
Immutabilité : WORM/objets, signature/hachage des chaînes d'artefacts.
Catalogue de récupération : inventaire des backups, intégrité, date d'expiration, décryptages de test.

3. 3 Applications et intégrations

Services de statles : déploiement rapide via IaC/CI.
Composants Statful : snapshots cohérents, orchestration de séquence de démarrage.
Intégrations (PSP/KYC/agrégateurs) : doubles credenshls, fallback-endpoints, webhooks signés, contrôle de la réadmission (idempotence).

4) Ordre de récupération (runbook général)

1. L'annonce du script DR → l'affectation du DR Incident Commander (DR-IC), le lancement de la salle de guerre.
2. Évaluation des dommages : régions/sous-systèmes touchés, RTA/RPA à jour, décision d'activer le faussaire.
3. Isolation/conteneur : verrouillage des causes originales (ACL réseau, secrets, désactivation du fournisseur).

• réseau/secrets/KMS →
• Bases de données/stockage/cache →
• API/services → front/CDN → intégrations externes.
• 5. Vérification de l'intégrité : contrepoids. montants, demandes « sèches », échantillons de santé.
• 6. Reconciliation des finances/jeux : rapprochement des paiements, des paris, des bilans, récurrence idempotent des opérations.
• 7. Communications : page de statut, acteurs/partenaires/régulateurs ; mise à jour temporelle.
• 8. Observation et stabilisation : désactivation des dégradations au fur et à mesure de la normalisation.
• 9. Post-mortem : RCA, CAPA, mise à jour DRP.

5) Runbooks spécialisés (fragments)

5. 1 Perte de la région principale (Active-Standby → Standby)

yaml trigger: "loss_of_region_primary OR quorum_fail >= 5m"
prechecks:
- "secondary region green"
- "replication_lag <= 15m"
steps:
- DR-IC approves region_failover
- Platform: GSLB switch → secondary
- Data: promote replicas, enable PITR streams
- Apps: redeploy with region vars; warm caches
- QA: smoke tests (login, deposit, bet, payout)
- Comms: status-page + partner notice rollback: "switch-back after 60m stability window"

5. 2 Corruption OBD/Récupération du PITR

yaml trigger: "data_corruption_detected OR accidental_drop"
steps:
- Freeze writes (feature flag), snapshot evidence
- Restore to timestamp T (<= RPO)
- Reindex/consistency checks
- Replay idempotent events from queue (from T)
- Reopen writes in throttle mode validation: ["checksum_ok", "balance_diff=0", "orders_gap=0"]

5. 3 dégradations PSP en mode DR

yaml trigger: "auth_rate_psp1 < baseline-3σ for 15m"
steps:
- Route X%→psp2, cap payouts, enable manual VIP
- Reconciliation plan T+0, alerts Finance
- Notify players in cashier; vendor escalation

6) Intégrité des données et reconnaissance

Finances : rapprochement des dépôts/paiements/commissions, retransmission des notifications et des webhooks avec déduplication (idempotency-keys).
Circuit de jeu : restauration des états de round, répétition des calculs si nécessaire, protection contre les doubles débits/charges.
Journaux/audit : mappage des logs WORM « avant/après », signatures/hachages, rapports de cohérence.
Rapport au DPO/Compliance : en cas d'exposition à l'IPI - fixation de l'échelle, du délai et des notifications.

7) DR pour les technologies clés (exemples)

Bases de données (relationnelles) : réplication synchrone/asynchrone, slots WAL, fast-promote, standbayes chauds.
NoSQL/cache : Multiclaster, TTL-invalidation, remplissage à froid, refus d'écriture cross-région sans conflit-résolve.
Files d'attente/strim : tops/clusters miroirs, contrôle des déplacements, déduplication des consommateurs.
Stockage d'objets : versioning, réplication en « bunker », inventaire d'objets et stratégies de rétention.
CI/CD/artefacts : répliques de registres, signature d'artefacts, copies hors ligne de conteneurs critiques.
Secrets/clés : KMS par région, clés racines indépendantes, break-glass avec journal et TTL.

8) Sécurité et vie privée au DR

Principe des droits les plus faibles : Accès DR par des rôles/profils distincts (JIT/PAM).
Backaps immutables : hors ligne/hors site, test de récupération et de décryptage.
Fenêtres réglementaires : enregistrement des événements et décision de notification (régulateur/banque/PSP/utilisateurs) avec Legal/DPO.
Traçabilité : journal complet des activités de la commande DR, signature temporelle.

9) Exercices et types de tests

Walkthrough/Review : vérification du document/des rôles/des contacts (trimestriel).
Tabletop : lancer des scénarios « à sec » avec la résolution de conflits.
Partie technique : restauration d'un service/OBD séparé.
Full failover/switch-over : transférer le trafic et les données vers la région de secours.
Jours de chaos (contrôlables) : injections de défaillances/pannes pour vérifier les automatismes.

Chaque test → un rapport avec un RTA/RPA, une liste d'anomalies, un CAPA et une mise à jour du DRP.

10) Métriques (KPI/KRI)

RTA/RPA vs RTO/RPO (Tier-1) : ≥ 95 % des correspondances.
DR Test Coverage : ≥ 2 tests DR complets/an + réguliers partiels.
Time-to-First-Status : ≤ 15 min après l'annonce du DR.
Reconciliation Zero-Diff : tous les rapprochements monétaires et de jeu sans divergence.
Backup Integrity : 100 % des récupérations sélectives réussissent par trimestre.
Bou Drift : 0 dérive entre primary/secondaire (comparaison IaC).
Security in DR : 100 % des actions DR avec journal et confirmation.

11) RACI (agrandi)

12) Chèques-feuilles

12. 1 Prêt pour le DR

• Mise à jour des contacts de l'équipe DR/fournisseurs/régulateurs
• Réplication verte, PITR inclus, décodage de test des backups
• Accès JIT/PAM, « break-glass » vérifié
• Feilover-playbooks et variables d'environnement valides
• Double credenshluks/webhooks PSP/KYC, itinéraires alternatifs
• Statut de page/modèles de messages prêts

12. 2 Pendant le DR

• Nommé DR-IC, war-room ouvert, événements temporels
• Isolation de cause, sélection de script, exécution de runbooks
• Contrôles d'intégrité, échantillons de santé, tests de smoke
• Premier Apdate public ≤ 15 min ; notifications aux partenaires/régulateurs de SLA
• Saisie d'artefacts pour enquête

12. 3 Après DR

• Rapprochement complet argent/jeux et magazines
• Post-mortem, RCA, CAPA avec dates et propriétaires
• Mise à jour de DRP/BIA/contacts/IaC
• Plan de test répété des fiches

13) Modèles (fragments)

13. 1 Carte de service (passeport DR)

yaml service: payments-api tier: 1 dependencies: [auth, ledger-db, psp1, psp2, kms-eu]
rto: "45m"
rpo: "15m"
backups: {pitr: true, snapshots: "hourly", immutability: "7d"}
failover: {mode: "active-standby", regions: ["eu1","eu2"]}
runbooks: ["rb_failover_region", "rb_psp_degradation"]
health_checks: ["/healthz","/readyz"]

13. 2 Rapport de test DR (extrait)

yaml test_id: DR-2025-10 scope: "Full switch-over eu1→eu2"
rta: "27m"
rpa: "11m"
issues:
- id: CAPA-117, desc: "долгое прогревание кэша", due: 2025-11-20, owner: SRE
- id: CAPA-118, desc: "устаревший webhook PSP#2", due: 2025-11-12, owner: Payments reconciliation: {finance: "ok", games: "ok"}
management_signoff: "2025-11-02"

13. 3 Modèle de message d'état

[UTC+02] Идет аварийное переключение в резервный регион. Игры доступны, выводы временно ограничены. Средства игроков в безопасности. Следующее обновление через 15 минут.

14) Feuille de route pour la mise en œuvre (6-8 semaines)

Semaines 1 à 2 : inventaire des services et des dépendances, classification Tier, objectifs RTO/RPO, choix des topologies, passeports DR.
Semaines 3-4 : implémentation des backups/PITR/immutabilité, réplication des secrets/KMS, préparation des runbooks et statut.
Semaines 5 à 6 : tests partiels (OBD/cache/files d'attente), tabletop par scénarios PSP/KYC/région.
Semaines 7 à 8 : full switch-over (si possible), rapport avec RTA/RPA, CAPA, mise à jour DRP et plan de test régulier.

15) Intégration avec d'autres sections wiki

Lien avec : BCP, Registre des risques, Gestion des incidents, Politique des loges (WORM), TPRM et SLA, ISO 27001/27701, SOC 2, PCI DSS, RBAC/Least Privilège, Politique de mot de passe et MFA, Gestion des changements/releases

TL; DR

L'ouvrier DRP = clair RTO/RPO selon Tier → l'architecture Active-Active/Standby + иммутабельные bekapy/PITR → reproduit runbooks et фейловер → reconciliation de l'argent/jeux → les doctrines régulières et CAPA. Ensuite, toute défaillance majeure se transforme en une procédure gérable avec un temps de récupération prévisible et zéro surprise pour les régulateurs et les joueurs.