Azure Site Recovery : tester un plan de reprise sans toucher à la production

Un plan Azure Site Recovery peut être entièrement configuré et rester inutilisable le jour de l’incident. La réplication peut être saine alors que l’ordre de démarrage est faux, que le réseau de secours ne résout pas les noms attendus ou qu’une identité n’accède plus à sa dépendance. La seule preuve utile est un test failover qui redémarre l’application et produit des résultats vérifiables.

Le cas d’usage est une application à trois tiers protégée par Azure Site Recovery : base de données, services applicatifs et frontal web. L’équipe veut tester son recovery plan sans interrompre la production ni connecter par erreur les machines de test aux flux réels. Le runbook doit aboutir à une décision : plan prêt, corrections ciblées puis nouveau test, ou exercice abandonné et nettoyé.

Définir ce que l’exercice doit prouver

Un test failover ne doit pas se limiter à voir des VM démarrer. Écrivez les critères de succès avant l’exécution : point de reprise acceptable, ordre de démarrage, dépendances disponibles, contrôles applicatifs et durée maximale.

exercise:
recovery_plan: rp-orders-prod
owner: platform-operations
protected_scope:
  - sql-orders-01
  - api-orders-01
  - web-orders-01
recovery_point: latest_app_consistent
test_vnet: vnet-drill-weu
production_connectivity: forbidden

success_criteria:
- all_recovery_plan_groups_complete
- dns_resolves_test_dependencies
- database_accepts_read_only_validation
- api_health_returns_expected_build
- synthetic_order_uses_test_data_only
- no_production_queue_or_webhook_is_reached
- cleanup_completes_and_replication_remains_healthy

decision:
ready: all_critical_checks_pass
repair: bounded_gap_with_owner_and_deadline
abort: isolation_or_data_safety_not_proven

Ce contrat sépare la reprise technique de la reprise métier. Une VM démarrée ne prouve ni la cohérence des données ni la capacité du service à traiter une requête.

Construire un réseau de test réellement isolé

Le réseau du test doit reproduire les subnets et les plages utiles sans avoir de chemin vers la production. N’ajoutez pas un peering ou une route par confort de diagnostic. Si Active Directory ou DNS est nécessaire, fournissez une instance dédiée au test ou une copie contrôlée dans ce périmètre.

Avant le test failover
VNet de test dédié et identifié
Noms de subnets cohérents avec le mapping Site Recovery
Aucun peering vers les VNets de production
Aucune route vers les plages on-premises de production
NSG limitant les entrées aux postes d'administration prévus
DNS de test configuré et résolutions critiques documentées
Sortie Internet absente ou limitée aux destinations nécessaires
Webhooks, files, SMTP et APIs partenaires remplacés par des cibles de test

Bloquer l'exercice
Le VNet sélectionné est celui du site de secours de production
Une dépendance ne peut fonctionner qu'en écrivant en production
Le plan suppose une IP fixe non disponible dans le subnet de test
L'équipe ne sait pas distinguer les données de test des données réelles

Azure Site Recovery tente de réutiliser le nom du subnet et l’adresse IP prévus. Si le subnet n’existe pas ou si l’adresse est indisponible, le placement peut différer. Vérifiez donc les NIC créées au lieu de supposer que le mapping a été respecté.

Relire le recovery plan comme un graphe de dépendances

Les groupes du recovery plan doivent refléter l’ordre applicatif. Pour une architecture classique, la base démarre avant l’API, puis le frontal. Les composants d’un même groupe démarrent en parallèle ; deux services dépendants ne devraient donc pas être placés ensemble uniquement pour raccourcir le plan.

Groupe 1 - fondations
DNS ou annuaire de test si requis
Base de données
Vérification du montage et de la cohérence

Groupe 2 - services
API et workers
Secrets et identités disponibles
Pause de validation avant ouverture du frontal

Groupe 3 - exposition de test
Frontal web
Load balancer interne ou endpoint de test
Probes synthétiques

Actions à relire
Pré-actions sans dépendance à un endpoint de production
Runbooks Azure Automation idempotents et bornés au resource group de test
Actions manuelles avec owner et critère de reprise
Post-actions qui n'activent ni DNS public ni trafic client

Une automatisation de reprise doit recevoir explicitement le contexte test. Un runbook qui déduit son environnement depuis le nom d’une VM peut exécuter la mauvaise action après renommage ou changement de convention.

Choisir le point de reprise avec une raison

Le dernier point traité minimise généralement le temps de reprise, tandis qu’un point cohérent applicativement privilégie l’état de l’application. Le bon choix dépend du scénario testé. Pour un exercice de redémarrage d’une application transactionnelle, un point cohérent applicativement est souvent le meilleur candidat ; pour mesurer le RTO minimal, le dernier point traité peut être pertinent.

Consignez l’horodatage sélectionné et l’écart avec la production. Si une VM du plan ne possède pas le type de point attendu, arrêtez le test avant de mélanger silencieusement des états incompatibles.

Exécuter et collecter les preuves au fil du plan

Lancez le test failover depuis le recovery plan, sélectionnez le VNet isolé et suivez les jobs Site Recovery. Capturez chaque transition : contrôle des prérequis, création des VM, démarrage des groupes, actions automatiques et pauses manuelles.

{
"exerciseId": "drill-2026-08-08-orders",
"recoveryPlan": "rp-orders-prod",
"recoveryPointUtc": "2026-08-08T05:42:00Z",
"testVnet": "vnet-drill-weu",
"jobs": [
  {"group": "database", "status": "completed", "durationSeconds": 420},
  {"group": "services", "status": "completed", "durationSeconds": 265},
  {"group": "frontend", "status": "completed", "durationSeconds": 118}
],
"checks": {
  "replicationHealth": "healthy",
  "dns": "pass",
  "database": "pass",
  "apiHealth": "pass",
  "syntheticJourney": "pass",
  "productionIsolation": "pass"
},
"observations": []
}

Les durées d’exemple servent à montrer le format, pas à fixer un objectif universel. Mesurez vos propres jalons : début du job, VM disponible, service prêt et parcours métier validé.

Valider depuis le chemin de secours

Les contrôles doivent partir du réseau de test et viser les noms réellement utilisés après reprise. Une connexion directe à l’IP d’une VM peut masquer une erreur DNS, un certificat invalide ou un load balancer mal configuré.

set -euo pipefail

TEST_HOST="orders.drill.internal"
EXPECTED_BUILD="2026.08.08"

getent hosts "$TEST_HOST"

curl --fail --silent --show-error --connect-timeout 5 --max-time 15 "https://$TEST_HOST/health"

actual_build=$(curl --fail --silent "https://$TEST_HOST/version")
test "$actual_build" = "$EXPECTED_BUILD"

# Le parcours doit utiliser un tenant, une file et des webhooks de test.
curl --fail --silent --show-error -H "X-Drill-Id: drill-2026-08-08-orders" -H "Content-Type: application/json" --data '{"customer":"drill-only","amount":1}' "https://$TEST_HOST/api/orders/validate"

Ajoutez un contrôle négatif : le service ne doit pas pouvoir publier dans une file de production, appeler un webhook réel ou mettre à jour un enregistrement DNS public. L’isolation est un résultat de test, pas seulement une propriété supposée du VNet.

Qualifier les écarts sans bricoler pendant l’exercice

Quand une étape échoue, conservez l’état et classez l’écart avant de modifier quoi que ce soit. Un problème de démarrage ne se traite pas comme un problème DNS ; un échec d’identité ne justifie pas l’ouverture d’un NSG.

VM absente ou job bloqué
Vérifier réplication, quota, SKU, disque, zone et job Site Recovery

VM démarrée, service arrêté
Vérifier ordre du plan, montage, configuration locale et dépendance de démarrage

Nom non résolu ou mauvaise IP
Vérifier DNS du VNet de test, subnet, enregistrements et cache

401 ou 403 sur une dépendance
Vérifier identité, audience, rôle et périmètre de la ressource de test

Application saine, parcours métier en échec
Vérifier file, webhook, certificat, load balancer et données de test

Flux observé vers la production
Arrêter l'exercice, couper le chemin réseau, conserver les preuves et nettoyer

Les corrections importantes doivent être apportées au recovery plan, à l’IaC ou au runbook source, puis testées dans un nouvel exercice. Une réparation manuelle sur la VM temporaire ne rend pas le plan de reprise plus fiable.

Nettoyer et vérifier le retour à l’état nominal

Terminez par Cleanup test failover et documentez les observations. Vérifiez que les VM et interfaces temporaires ont disparu, que les verrous ou ressources auxiliaires ne restent pas orphelins et que la réplication des éléments protégés demeure saine.

Plan prêt
Tous les critères critiques passent depuis le réseau de test
Le temps de reprise mesuré respecte l'objectif interne
L'isolation production est prouvée
Le nettoyage est complet et la réplication reste saine

Plan à corriger
Ecart borné avec owner, correction source et date de nouveau test
Aucune validation critique n'est déclarée réussie par contournement manuel
Le test est nettoyé avant une nouvelle exécution

Exercice abandonné
Isolation, cohérence des données ou dépendance critique non maîtrisée
Flux de test immédiatement coupés
Preuves conservées, cleanup exécuté et incident ouvert si nécessaire

Conclusion

Un test Azure Site Recovery réussi ne se résume pas à trois VM vertes dans le portail. Il prouve un point de reprise, un ordre de démarrage, un réseau isolé, des dépendances disponibles, un parcours applicatif contrôlé et un nettoyage complet.

La décision finale doit rester binaire sur les contrôles critiques : le plan est prêt, ou il doit être corrigé et retesté. Cette discipline transforme Site Recovery d’une configuration rassurante en système de reprise réellement exploitable.