Architecture de Reprise après Sinistre : niveaux, compromis et tests
#architecture#disaster-recovery#reliability#cloud#business-continuity
La reprise après sinistre (DR) n'est pas une fonctionnalité à ajouter plus tard. C'est une décision architecturale qui détermine le coût d'infrastructure, la complexité opérationnelle et la tolérance au risque dès le premier jour.
Comparaison des niveaux DR
| Niveau | Stratégie | RPO | RTO | Coût relatif | Risque de perte |
|---|---|---|---|---|---|
| Niveau 0 | Aucun plan DR | Indéfini | Jours-Jamais | 1x (base) | Perte totale possible |
| Niveau 1 | Sauvegarde & Restauration | Heures-Jours | Heures-Jours | 1.1x | Dernière fenêtre de backup |
| Niveau 2 | Pilot Light | Minutes-Heures | Heures | 1.3x | Minimal |
| Niveau 3 | Warm Standby | Minutes | 15-60 min | 1.5-2x | Très faible |
| Niveau 4 | Hot Standby | Secondes | Minutes | 2-3x | Quasi nul |
| Niveau 5 | Actif-Actif | Quasi nul | Quasi nul | 3-4x | Effectivement nul |
RPO = Objectif de Point de Reprise (combien de données pouvez-vous perdre) RTO = Objectif de Temps de Reprise (en combien de temps devez-vous être de retour)
Checklist de test DR
| Type de test | Fréquence | Portée | Perturbation | Confiance |
|---|---|---|---|---|
| Exercice sur table | Trimestriel | Parcours des runbooks | Aucune | Faible-Moyenne |
| Basculement composant | Mensuel | Un service/BDD | Minimale | Moyenne |
| Basculement régional | Semestriel | Bascule complète de région | Modérée | Haute |
| Chaos engineering | Continu | Injection de pannes aléatoires | Variable | Haute |
| Exercice DR complet | Annuel | Simulation de panne totale | Significative | Très haute |
| Test restauration backup | Mensuel | Restaurer un backup pour vérifier | Aucune | Moyenne |
Matrice coût vs récupération
Coût ▲
4x │ ● Actif-Actif
│
3x │ ● Hot Standby
│
2x │ ● Warm Standby
│
1.5x │ ● Pilot Light
│
1x │ ● Sauvegarde/Restauration
│
└────────────────────────────────────────────► Vitesse de récupération
Jours Heures 30min Minutes Secondes
Décisions par criticité métier
| Type de système | Niveau recommandé | Justification |
|---|---|---|
| Outils internes | Niveau 1-2 | Indisponibilité tolérable, sensible au coût |
| SaaS B2B (standard) | Niveau 3 | SLA typiquement 99.9%, RPO horaire acceptable |
| SaaS B2B (enterprise) | Niveau 4 | SLA 99.95%+, RPO en minutes |
| E-commerce | Niveau 4 | Perte de revenu par minute quantifiable |
| Services financiers | Niveau 5 | Exigences réglementaires, zéro perte |
| Santé (critique) | Niveau 5 | Sécurité patient, mandats de conformité |
Point clé
L'échec DR le plus courant n'est pas technique -- c'est que le plan n'a jamais été testé. Un plan DR qui n'a pas été exercé depuis 6 mois est une hypothèse, pas un plan.