Azure Service Health : qualifier un signal régional avant failover

Un signal Azure Service Health ou Resource Health arrive rarement au bon moment. Une région annonce une dégradation, une ressource passe en état indisponible, un dashboard commence à clignoter, et l’équipe doit décider vite : attendre, basculer, rollbacker, couper une automatisation, ou prévenir les utilisateurs.

Le risque est de traiter le signal Azure comme une décision déjà prise. Service Health indique un événement de plateforme. Resource Health signale l’état d’une ressource. Aucun des deux ne prouve seul l’impact applicatif, le bon périmètre de failover ou la sécurité d’un rollback. Ce runbook sert à relier signal fournisseur, symptômes utilisateur, dépendances, routage, DNS, traces et plan de retour avant d’engager une bascule régionale.

Poser le périmètre de décision

Commencez par écrire le contrat de l’incident. Une bascule régionale n’est pas une commande technique isolée : elle touche routage, caches, données, files, identités, endpoints privés, observabilité et capacité de retour.

incident:
signal: Azure Service Health degradation
region: westeurope
first_seen_utc: 2026-07-19T06:42:00Z
impacted_services:
  - App Service
  - Azure SQL
  - Storage
workload: customer-api-prod
primary_region: westeurope
secondary_region: northeurope

decision_needed:
- wait_and_monitor
- fail_over_traffic
- rollback_last_release
- disable_write_path
- pause_automation

evidence_required:
- provider_event_scope
- user_visible_symptom
- resource_health_state
- dependency_errors
- routing_and_dns_state
- data_consistency_risk
- rollback_path

Sans ce cadrage, l’équipe peut confondre une panne région Azure, une régression applicative, une erreur DNS, une limite de dépendance ou un problème d’observabilité.

Séparer Service Health, Resource Health et signal applicatif

Service Health est utile pour comprendre le contexte fournisseur. Resource Health rapproche le signal d’une ressource précise. Les logs applicatifs disent si les utilisateurs voient réellement le problème. Il faut lire ces trois plans ensemble.

Service Health
Evenement fournisseur
Region et services declares
Statut, dernier message, heure de debut
Consequence possible sur plusieurs abonnements

Resource Health
Etat d'une ressource concrete
Available, Degraded, Unavailable ou Unknown
Historique de transition
Annotation plateforme ou utilisateur

Signal applicatif
Taux d'erreur, latence, saturation, timeouts
Parcours utilisateur touches
Dependances en erreur
Difference entre region primaire et secondaire

Decision
La bascule est justifiee seulement si le signal applicatif et le risque de maintien depassent le risque de failover

Un événement Service Health sans symptôme applicatif peut justifier une surveillance renforcée. Un symptôme applicatif sans événement Service Health doit rester un incident produit ou infrastructure jusqu’à preuve contraire.

Lister les ressources touchées sans extrapoler

Avant de basculer, vérifiez quelles ressources sont réellement en état dégradé. Si vous utilisez Azure Resource Graph, l’objectif est de rapprocher les ressources critiques, leur région et leur statut de santé.

resourcehealthresources
| where type =~ "microsoft.resourcehealth/availabilitystatuses"
| extend resourceId = tostring(properties.targetResourceId)
| extend availabilityState = tostring(properties.availabilityState)
| extend reasonType = tostring(properties.reasonType)
| extend summary = tostring(properties.summary)
| where resourceId has "/resourceGroups/rg-prod-"
| project resourceId, availabilityState, reasonType, summary, location
| order by availabilityState asc, resourceId asc

Cette vue ne doit pas être utilisée seule pour décider. Elle sert à limiter le périmètre : quelles ressources critiques sont dégradées, lesquelles restent disponibles, et quelles dépendances ne sont pas couvertes par le signal.

Confirmer l’impact utilisateur avant le failover

Une bascule régionale peut aggraver un incident si le secondaire n’est pas chaud, si les données ne sont pas synchrones, si les endpoints privés ne sont pas validés ou si les allowlists ne couvrent pas la région de secours. Il faut donc vérifier l’impact utilisateur avant l’action lourde.

let Window = 2h;
let PrimaryRegion = "westeurope";
requests
| where timestamp > ago(Window)
| extend region = tostring(customDimensions["region"])
| summarize total=count(),
          failed=countif(success == false),
          p95_ms=percentile(duration, 95)
by bin(timestamp, 5m), region, cloud_RoleName
| extend failure_rate = todouble(failed) / todouble(total)
| where region in (PrimaryRegion, "northeurope")
| order by timestamp asc

Si les erreurs montent uniquement sur un endpoint interne non utilisateur, la décision peut être de dégrader une fonctionnalité ou de suspendre une automatisation. Si le parcours principal échoue, la question de failover devient plus forte.

Vérifier routage, DNS et chemin secondaire

Le failover échoue souvent sur des détails opérables : TTL DNS trop long, Front Door ou Traffic Manager mal pondéré, origin secondaire froid, certificat non valide, Private DNS Zone non liée, firewall ou NAT non prêt, sonde qui mesure le mauvais chemin.

Chemin utilisateur
Front Door, Traffic Manager, Application Gateway ou DNS public
Health probe qui mesure le vrai endpoint applicatif
Certificat et hostname valides sur le secondaire
TTL connu et temps de propagation acceptable

Chemin prive
Private DNS Zone liee aux VNets secondaires
Resolver ou forwarder hybride pret
UDR, NSG, firewall et NAT controles
Dependances PaaS joignables depuis la region de secours

Chemin donnees
Mode de replication connu
RPO et RTO relus
Files, jobs et consommateurs idempotents
Ecritures bloquees si la coherence n'est pas garantie

Private Endpoint peut faire partie du chemin, mais il ne doit pas devenir le seul diagnostic. La bascule dépend aussi du routage global, du DNS, de l’état applicatif, de la réplication et des contrôles de sécurité.

Décider avec une matrice exploitable

Le runbook doit produire une décision relisible. Une équipe d’astreinte ne doit pas deviner pourquoi elle a basculé à 08:00 ou pourquoi elle a choisi d’attendre.

Attendre et surveiller
Service Health degrade mais pas d'impact utilisateur confirme
Resource Health disponible sur les ressources critiques
Probes synthetiques et logs applicatifs stables
Revue planifiee dans une fenetre courte

Basculer le trafic
Impact utilisateur confirme sur la region primaire
Chemin secondaire valide par probe applicative
Donnees et dependances compatibles avec la bascule
Rollback ou retour primaire documente

Rollbacker le dernier changement
Symptome demarre apres deploiement ou changement infra
Service Health ne couvre pas le composant touche
Secondaire expose le meme risque applicatif
Ancien etat sain connu

Degrader une fonctionnalite
Parcours principal stable
Dependances secondaires ou jobs asynchrones touches
Ecritures ou automatisations risquent de dupliquer l'etat
Mode degrade testable et reversible

Bloquer la bascule
Etat secondaire inconnu
Replication ou coherence non prouvee
DNS, certificats ou probes non valides
Retour arriere impossible a executer proprement

La décision doit inclure une heure de réévaluation. Attendre sans horizon est une absence de décision, pas une stratégie.

Exécuter la bascule avec garde-fous

Si la bascule est choisie, réduisez le nombre de changements simultanés. Modifiez une surface de routage, observez, puis continuez. Les automatisations de failover doivent rester bornées : pas de purge globale, pas de modification de seuils d’alerte, pas d’ouverture réseau large pour “faire passer”.

change:
action: shift_traffic_to_secondary
owner: incident-commander
start_utc: 2026-07-19T07:10:00Z
traffic_surface: front-door-origin-priority
primary_origin: app-westeurope
secondary_origin: app-northeurope

guards:
max_change_per_step: one_routing_surface
keep_logs_enabled: true
keep_user_symptom_alert: true
freeze_nonessential_deployments: true
pause_write_automation_if_consistency_unknown: true

validation:
- synthetic_probe_secondary_success
- user_error_rate_decreases
- dependency_errors_do_not_move_to_secondary
- no_duplicate_jobs_or_messages
- rollback_instruction_confirmed

Le meilleur failover est celui qui laisse assez de preuves pour comprendre ensuite si la bascule a corrigé l’incident ou seulement déplacé le symptôme.

Valider après bascule ou retour arrière

Après action, validez le service et le contrôle. Une page verte ne suffit pas si les jobs asynchrones doublonnent, si les traces ne sont plus corrélées ou si le retour primaire est devenu impossible.

Validation service
Taux d'erreur utilisateur revenu au niveau attendu
Latence stable sur le chemin secondaire
Dependances critiques sans nouvelle erreur dominante
Files, traitements et webhooks sans duplication
Donnees coherentes avec le mode de replication

Validation controle
Decision, heure, preuves et owner notes dans l'incident
Alertes utilisateur toujours actives
Logs et traces visibles sur la region active
Retour primaire ou rollback de routage teste en lecture
Actions temporaires avec heure de fin

Si le failover corrige l’impact mais que le retour est incertain, l’incident reste ouvert. L’état cible est peut-être stable, mais l’exploitation n’est pas encore revenue à un mode contrôlé.

Conclusion

Un signal Azure Service Health ou Resource Health doit déclencher un diagnostic, pas une bascule automatique. La bonne question n’est pas seulement “Azure est-il en panne ?”, mais “quel impact voit-on, quel chemin est touché, quel secondaire est prêt, et quel retour arrière reste possible ?”.

En séparant signal fournisseur, état ressource, symptôme utilisateur, routage, DNS, données et observabilité, l’équipe peut choisir entre attente surveillée, failover, rollback, mode dégradé ou blocage. La décision devient opérable : elle inclut des preuves, une validation et un retour arrière, au lieu d’une réaction précipitée à une alerte régionale.