Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
REL13-BP03 Tester la mise en œuvre de la reprise après sinistre pour valider la mise en œuvre
Testez régulièrement le basculement sur votre site de restauration pour vérifier qu'il fonctionne correctement RTO et RPO qu'il est respecté.
Anti-modèles courants :
-
Ne jamais exécuter de basculements en production.
Avantages du respect de cette bonne pratique : en testant régulièrement votre plan de reprise après sinistre, vous vous assurez qu’il fonctionnera quand il le faudra et que votre équipe sait comment exécuter la stratégie.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
S’il y a bien un modèle à éviter, c’est celui qui consiste à développer des chemins de récupération rarement testés. Par exemple, vous pouvez avoir un magasin de données secondaire qui est utilisé pour les requêtes en lecture seule. Lorsque vous écrivez dans un magasin de données et que l’instance principale connaît une défaillance, vous pouvez basculer vers le magasin de données secondaire. Si vous ne testez pas fréquemment ce basculement, vous constaterez peut-être que vos hypothèses sur les capacités du magasin de données secondaire sont incorrectes. La capacité du magasin de données secondaire, qui peut avoir été suffisante lors de votre dernier test, peut ne plus être en mesure de tolérer la charge dans le cadre de ce scénario. Notre expérience a montré que le seul chemin de récupération après erreur qui fonctionne est celui que vous testez fréquemment. C’est pourquoi l’idéal est de n’avoir qu’un petit nombre de chemins de récupération. Vous pouvez établir des modèles de reprise et tester ceux-ci régulièrement. Si vous avez un chemin de récupération complexe ou critique, vous devez toujours exécuter régulièrement cette panne en production pour vous assurer du bon fonctionnement de ce chemin de récupération. Dans l’exemple que nous venons de présenter, vous devez procéder régulièrement au basculement vers l’instance de secours, quel que soit le besoin.
Étapes d’implémentation
Préparez vos charges de travail pour la reprise. Testez régulièrement vos chemins de récupération. L’informatique orientée récupération identifie les caractéristiques des systèmes qui améliorent la récupération : isolement et redondance, capacité de l’ensemble du système à réduire les modifications, capacité à surveiller et déterminer l’état de santé, capacité à fournir des diagnostics, reprise automatique, conception modulaire et capacité à redémarrer. Entraînez votre chemin de reprise pour vérifier qu’il peut s’effectuer au moment et à l’état spécifiés. Utilisez vos runbooks au cours de cette reprise pour documenter les problèmes et trouver des solutions pour les résoudre avant le prochain test.
Pour les charges de travail EC2 basées sur Amazon, utilisez-le AWS Elastic Disaster Recoverypour implémenter et lancer des instances de forage dans le cadre de votre stratégie de reprise après sinistre. AWS Elastic Disaster Recovery permet d'exécuter des exercices de manière efficace, ce qui vous aide à vous préparer en cas de basculement. Vous pouvez également lancer fréquemment vos instances en utilisant Elastic Disaster Recovery à des fins de test et d’opération sans rediriger le trafic.
Ressources
Documents connexes :
-
APNPartenaire : partenaires qui peuvent aider à la reprise après sinistre
-
Blog d’architecture AWS : série sur la reprise après sinistre
-
AWS Marketplace : produits pouvant être utilisés pour la reprise après sinistre
-
Reprise après sinistre des charges de travail sur AWS : restauration dans le cloud (AWS livre blanc)
Vidéos connexes :
Exemples connexes :