6 min lecture • Guide 777 of 877
Planification de reprise après sinistre
Espérez le meilleur, préparez-vous au pire. GitScrum aide les équipes à documenter les procédures de récupération, suivre les tests DR et assurer la continuité d'activité.
Fondamentaux DR
Objectifs de récupération
DÉFINIR LES CIBLES DE RÉCUPÉRATION :
┌─────────────────────────────────────────────────────────────┐
│ │
│ TERMES CLÉS : │
│ │
│ RTO (Recovery Time Objective) : │
│ Temps d'arrêt maximum acceptable │
│ "Nous devons être de retour en ligne sous X heures" │
│ │
│ RPO (Recovery Point Objective) : │
│ Perte de données maximum acceptable │
│ "Nous pouvons perdre au maximum X heures de données" │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CLASSIFICATION DES SERVICES : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Service Tier RTO RPO ││
│ │ ─────────────── ──── ────── ────── ││
│ │ API Paiement 1 15 min 0 (aucun) ││
│ │ Base utilisateurs 1 30 min 5 min ││
│ │ App principale 1 1 heure 1 heure ││
│ │ Analytics 2 4 heures 24 heures ││
│ │ Env Dev 3 24 heures 1 semaine ││
│ │ Stockage archive 3 48 heures N/A ││
│ │ ││
│ │ Tier 1 : Critique (priorité immédiate) ││
│ │ Tier 2 : Important (restaurer après Tier 1) ││
│ │ Tier 3 : Non-critique (peut attendre) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ COÛT vs RTO : │
│ RTO plus court = Infrastructure plus coûteuse │
│ Équilibrer les besoins métier avec le budget │
└─────────────────────────────────────────────────────────────┘
Scénarios de sinistre
PLANIFICATION DES SCÉNARIOS :
┌─────────────────────────────────────────────────────────────┐
│ │
│ SCÉNARIOS DE SINISTRE COURANTS : │
│ │
│ INFRASTRUCTURE : │
│ • Panne de région cloud │
│ • Défaillance serveur base de données │
│ • Perte de connectivité réseau │
│ • Défaillance DNS │
│ │
│ DONNÉES : │
│ • Corruption de base de données │
│ • Chiffrement ransomware │
│ • Suppression accidentelle de données │
│ • Échec de sauvegarde │
│ │
│ APPLICATION : │
│ • Mauvais déploiement │
│ • Erreur de configuration │
│ • Défaillance de dépendance │
│ • Épuisement des ressources │
│ │
│ SÉCURITÉ : │
│ • Compromission de compte │
│ • Attaque DDoS │
│ • Violation de données │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ POUR CHAQUE SCÉNARIO : │
│ • Détection : Comment le saurons-nous ? │
│ • Réponse : Que faisons-nous immédiatement ? │
│ • Récupération : Comment restaurons-nous le service ? │
│ • Communication : Qui notifions-nous ? │
│ • Post-incident : Comment évitons-nous la récurrence ? │
└─────────────────────────────────────────────────────────────┘
Documentation DR
Runbooks de récupération
STRUCTURE DU RUNBOOK :
┌─────────────────────────────────────────────────────────────┐
│ │
│ RUNBOOK RÉCUPÉRATION BASE DE DONNÉES : │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DR-RUN-001 : Récupération base de données primaire ││
│ │ ││
│ │ SCÉNARIO : ││
│ │ Serveur base de données primaire indisponible ││
│ │ ││
│ │ DÉTECTION : ││
│ │ • Alerte monitoring : échecs connexion DB ││
│ │ • Pic d'erreurs application ││
│ │ • Échecs health check ││
│ │ ││
│ │ ACTIONS IMMÉDIATES (< 5 min) : ││
│ │ 1. Vérifier que DB est vraiment down (pas fausse alerte)││
│ │ 2. Vérifier page statut cloud ││
│ │ 3. Déclarer incident, démarrer comms ││
│ │ ││
│ │ OPTIONS DE RÉCUPÉRATION : ││
│ │ ││
│ │ OPTION A : Failover vers replica (RTO : 15 min) ││
│ │ 1. Promouvoir read replica en primaire ││
│ │ aws rds promote-read-replica --db-id prod-replica ││
│ │ 2. Mettre à jour connection string dans secrets ││
│ │ 3. Déployer application avec nouvelle connexion ││
│ │ 4. Vérifier connectivité ││
│ │ ││
│ │ OPTION B : Restaurer depuis backup (RTO : 2 heures) ││
│ │ 1. Identifier dernière bonne sauvegarde ││
│ │ 2. Restaurer vers nouvelle instance ││
│ │ aws rds restore-db-instance-to-point-in-time ... ││
│ │ 3. Mettre à jour connection string ││
│ │ 4. Vérifier intégrité des données ││
│ │ ││
│ │ VÉRIFICATION : ││
│ │ ☐ Health checks application passant ││
│ │ ☐ Transactions critiques fonctionnelles ││
│ │ ☐ Monitoring montrant état sain ││
│ │ ││
│ │ CONTACTS : ││
│ │ DBA : @db-team (Slack), +33-1-XX-XX-XX-XX ││
│ │ Astreinte : Escalation PagerDuty ││
│ │ AWS Support : Case priorité Critical ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Tests et validation
Programme de tests réguliers
Les plans de reprise après sinistre ne valent que ce que valent leurs tests. Les organisations doivent établir des programmes de tests réguliers qui valident les procédures de récupération fonctionnent comme prévu. GitScrum aide à planifier et suivre ces activités de test.
Les exercices sur table permettent aux équipes de parcourir les scénarios sans impact réel sur les systèmes. Les tests de récupération complète valident que les sauvegardes peuvent être restaurées et que les procédures sont exactes. Les exercices de chaos engineering testent la résilience en conditions réelles.
Documentation et amélioration continue
Après chaque test ou incident réel, les équipes doivent mettre à jour leur documentation DR. Les leçons apprises alimentent l'amélioration des procédures. GitScrum suit ces tâches d'amélioration aux côtés du travail de développement régulier.