Tester la DR sans impact

Un plan de récupération qui n’a jamais été testé n’est qu’une hypothèse. L’expérience du monde réel montre que les plans DR révèlent fréquemment des lacunes — dérive de configuration, automatisation manquante, runbooks obsolètes ou temps de démarrage plus longs que prévu — qui n’apparaissent que dans des conditions de test. Seuls des tests DR réguliers permettent d’avoir la certitude que votre plan fonctionnera lorsque vous en aurez le plus besoin.

Test Failover est une fonctionnalité intégrée d’Azure Site Recovery qui vous permet de simuler un basculement vers la région secondaire sans interrompre la production. Lors d’un basculement de test, ASR crée des copies des VMs répliquées dans un réseau virtuel isolé de la région secondaire. Les VMs de production continuent de fonctionner normalement dans la région primaire : les utilisateurs actifs ne courent donc aucun risque.

Le VNet de test isolé ne doit pas être connecté aux systèmes de production. Cela empêche les VMs de test d’écrire accidentellement dans la base de données de production, d’envoyer des e-mails à de vrais clients ou de déclencher des transactions de paiement. Créez un VNet de basculement de test dédié, sans appairage avec les VNets de production et sans accès à Internet, puis utilisez-le exclusivement pour les exercices DR.

Un test DR doit valider un ensemble précis de critères :

• Temps de démarrage — toutes les VMs démarrent-elles dans le délai prévu ?
• Démarrage de l’application — l’application s’initialise-t-elle correctement lorsqu’elle est connectée à la base de données récupérée ?
• Intégrité des données — les données au point de récupération sont-elles cohérentes et complètes ?
• RTO réel — mesurez le temps total écoulé entre le déclenchement du basculement et le moment où l’application commence à traiter les demandes
• Exécution du runbook — tous les scripts d’automatisation se sont-ils terminés correctement ?

Pendant le test, démarrez un chronomètre dès que vous déclenchez le basculement de test. Arrêtez-le lorsque l’application est confirmée comme saine (la sonde d’intégrité de l’équilibreur de charge renvoie 200 OK). Il s’agit de votre RTO réel. Comparez-le à votre RTO cible. Si le RTO réel dépasse la cible, identifiez les goulots d’étranglement — démarrage lent des VMs, initialisation longue de la base de données, délai de propagation du DNS — et corrigez-les.

Une fois le basculement de test terminé, connectez-vous à la base de données récupérée et vérifiez les données. Vérifiez que les transactions validées avant la limite de réplication sont présentes et que les transactions partiellement validées sont correctement traitées (annulées ou terminées). Pour les bases de données prenant en charge la restauration à un instant donné (PITR), testez une restauration vers un horodatage précis et vérifiez l’état attendu des données.

Lorsque le test est terminé, vous devez nettoyer les ressources du basculement de test — les VMs de test, leurs disques et leurs interfaces réseau dans la région secondaire. Azure Site Recovery fournit dans le portail l’action 'Cleanup test failover', qui supprime automatiquement toutes les ressources de test. Oublier ce nettoyage entraîne des coûts inutiles et encombre la région secondaire avec des ressources obsolètes.

Après chaque test DR, rédigez un rapport de test comprenant : la date et le périmètre du test, les RTO et RPO réels obtenus, une liste de contrôle des éléments validés avec leur état de réussite ou d’échec, les éventuelles lacunes ou défaillances observées, ainsi que les actions correctives prévues. Ce rapport est utile pour les audits de conformité (ISO 27001, SOC 2, HIPAA) et pour suivre l’amélioration de la maturité DR au fil du temps.

Les bonnes pratiques du secteur et les référentiels de conformité exigent généralement des tests DR au minimum chaque année, mais de nombreuses organisations effectuent des tests chaque trimestre, voire chaque mois, pour les charges de travail de niveau 1. Des tests plus fréquents détectent plus tôt les dérives de configuration et renforcent la confiance de l’équipe ainsi que ses automatismes. Automatisez autant que possible la préparation et la vérification des tests afin de réduire l’effort nécessaire à leur exécution fréquente.

Azure Chaos Studio est un service géré d’ingénierie du chaos qui vous permet d’injecter des défaillances contrôlées dans des ressources Azure afin de tester la résilience des applications. Vous pouvez arrêter des VMs, rendre des zones indisponibles, limiter le CPU ou injecter une latence réseau pour observer le comportement de votre application. Contrairement à un exercice DR standard, l’ingénierie du chaos vérifie si votre application se dégrade progressivement dans des conditions de défaillance partielle.

Les tests DR sont particulièrement utiles lorsqu’ils s’inscrivent dans un cycle d’amélioration continue : Planifier → Exécuter → Mesurer → Corriger → Recommencer. Après chaque test, corrigez les lacunes constatées, mettez à jour les runbooks et la documentation, puis testez de nouveau. Au fil du temps, l’écart entre vos objectifs RTO/RPO déclarés et les valeurs réellement obtenues devrait se réduire, jusqu’à ce que vous réussissiez systématiquement chaque test dans les limites acceptées.

Vérifiez votre compréhension des concepts de Microsoft Azure Fundamentals (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que le basculement de test permet de simuler un événement DR sans interrompre la production en créant des copies de VMs dans un VNet isolé ; que vous devez mesurer le RTO réel et vérifier l’intégrité des données pendant le test ; et que vous devez nettoyer les ressources de test et documenter les résultats après chaque exercice. Nous allons maintenant voir la récupération d’urgence pour les services PaaS tels qu’Azure SQL Database.