Azure Monitor et KQL : décider un rollback après déploiement sans couper les alertes

Après un déploiement, la question opérationnelle arrive souvent trop vite : faut-il rollbacker ou tenir la position ? Les alertes Azure Monitor s’allument, les logs applicatifs deviennent plus bruyants, un dashboard passe au rouge, et chacun cherche une preuve dans une fenêtre de quelques minutes. Couper l’action group pour respirer peut sembler utile, mais cela détruit souvent le signal qui permet justement de décider.

Le cas d’usage est volontairement concret : une application Azure vient d’être déployée derrière un chemin privé, une gateway, APIM ou un service managé. Les premières alertes arrivent dans les dix minutes. L’équipe doit déterminer si le changement a introduit une régression réelle, si le monitoring observe un warm-up normal, ou si la règle d’alerte est mal calibrée. L’objectif du runbook est de produire une décision exploitable : continuer, surveiller, corriger en avant, ou rollbacker avec validation.

Nommer la décision avant les requêtes

KQL ne doit pas devenir une chasse libre aux anomalies. Avant d’ouvrir les logs, il faut écrire la décision attendue et les critères qui la rendent défendable. Un rollback n’est pas justifié parce qu’une métrique bouge. Il l’est quand l’impact utilisateur, la régression technique et le lien temporel avec le changement sont suffisamment alignés.

Decision a produire
Continuer le deploiement
Surveiller avec fenetre courte
Corriger en avant avec changement borne
Rollbacker la version ou la configuration

Preuves minimales
Fenetre de deploiement horodatee
Symptome utilisateur ou degradation SLO
Changement technique plausible
Signal avant/apres comparable
Perimetre touche: service, region, revision, route, identite ou dependance
Test de validation apres action
Chemin de retour documente

Stop conditions
Erreur critique qui augmente apres le changement
Degradation utilisateur confirmee
Dependances saines mais service deploye instable
Absence de preuve suffisante pour corriger en avant
Rollback disponible et moins risque que l'attente

Cette étape évite deux erreurs symétriques : rollbacker dès le premier bruit, ou rester exposé parce que la preuve n’est pas encore parfaitement présentée.

Fixer une fenêtre de changement propre

La plupart des diagnostics échouent parce que la fenêtre temporelle est floue. Il faut isoler trois périodes : référence avant déploiement, fenêtre de changement, période d’observation après déploiement. Les requêtes doivent conserver ces bornes, même si l’équipe ajuste ensuite le périmètre.

let deploymentStart = datetime(2026-06-21T09:30:00Z);
let deploymentEnd = datetime(2026-06-21T09:42:00Z);
let beforeWindow = 45m;
let afterWindow = 45m;
let serviceName = "orders-api";
AppRequests
| where TimeGenerated between ((deploymentStart - beforeWindow) .. (deploymentEnd + afterWindow))
| where AppRoleName == serviceName
| extend phase = case(
  TimeGenerated < deploymentStart, "before",
  TimeGenerated <= deploymentEnd, "deploying",
  "after")
| summarize
  requests = count(),
  failed = countif(Success == false),
  p95_duration_ms = percentile(DurationMs, 95)
by phase, bin(TimeGenerated, 5m)
| order by TimeGenerated asc

Le point important n’est pas la requête exacte. C’est la discipline : comparer le même service, la même granularité, la même source de logs et la même définition d’échec.

Séparer impact utilisateur et bruit interne

Un service peut produire plus d’exceptions sans que les utilisateurs soient réellement touchés, par exemple pendant un warm-up, une reconnexion de clients ou une purge de cache. L’inverse est aussi vrai : peu d’exceptions visibles peuvent masquer des timeouts côté client. La décision de rollback doit commencer par l’impact.

let deploymentStart = datetime(2026-06-21T09:30:00Z);
let deploymentEnd = datetime(2026-06-21T09:42:00Z);
let afterWindow = 45m;
AppRequests
| where TimeGenerated between ((deploymentStart - 45m) .. (deploymentEnd + afterWindow))
| where AppRoleName == "orders-api"
| summarize
  total = count(),
  failed = countif(Success == false),
  server_errors = countif(ResultCode startswith "5"),
  client_errors = countif(ResultCode startswith "4"),
  p95_duration_ms = percentile(DurationMs, 95)
by bin(TimeGenerated, 5m), OperationName
| extend failure_rate = todouble(failed) / todouble(total)
| where total > 20
| order by TimeGenerated asc, failure_rate desc

Si le taux d’échec monte sur une opération utilisateur centrale, le diagnostic peut avancer vers le rollback. Si seuls des endpoints de health check ou des tâches internes bruitent, la décision peut être de surveiller ou de corriger l’alerte.

Corréler la régression avec la version ou la configuration

Le lien temporel ne suffit pas. Un pic après déploiement peut venir d’un trafic inhabituel, d’une dépendance externe, d’un incident réseau ou d’une identité expirée. Il faut rattacher le symptôme à un artefact : version, révision, slot, image, rule set, route, feature flag ou configuration.

let deploymentStart = datetime(2026-06-21T09:30:00Z);
AppTraces
| where TimeGenerated > deploymentStart - 30m
| where AppRoleName == "orders-api"
| extend version = tostring(Properties["appVersion"])
| extend revision = tostring(Properties["revision"])
| summarize
  traces = count(),
  errors = countif(SeverityLevel >= 3),
  sample_error = anyif(Message, SeverityLevel >= 3)
by version, revision, bin(TimeGenerated, 10m)
| order by TimeGenerated asc, errors desc

Quand la version fautive est visible, la décision devient plus simple. Quand elle ne l’est pas, c’est un signal d’exploitation à corriger : une application qui ne journalise pas sa version rend les rollbacks plus lents et plus discutables.

Vérifier les dépendances avant de blâmer le déploiement

Un rollback applicatif ne corrige pas une dépendance indisponible, une résolution DNS cassée, une règle WAF trop large ou une identité sans droit. Avant de revenir en arrière, il faut vérifier si le service déployé échoue parce qu’il est mauvais ou parce que son environnement a changé.

let deploymentStart = datetime(2026-06-21T09:30:00Z);
AppDependencies
| where TimeGenerated between ((deploymentStart - 45m) .. (deploymentStart + 60m))
| where AppRoleName == "orders-api"
| summarize
  calls = count(),
  failed = countif(Success == false),
  p95_duration_ms = percentile(DurationMs, 95),
  result_codes = make_set(ResultCode, 10)
by Target, DependencyType, bin(TimeGenerated, 5m)
| extend failure_rate = todouble(failed) / todouble(calls)
| where calls > 10
| order by TimeGenerated asc, failure_rate desc

Si une seule dépendance bascule en échec pour plusieurs services, le rollback de l’application n’est peut-être pas l’action prioritaire. Si les dépendances restent stables mais que la nouvelle version échoue, le rollback gagne en crédibilité.

Produire une matrice stop, go ou rollback

La décision doit tenir en quelques lignes, pas dans une conversation dispersée. Une matrice simple aide l’équipe à trancher sans inventer de nouveaux critères en plein incident.

Continuer
Pas de degradation utilisateur mesurable
Erreurs limitees a warm-up ou endpoints internes
Dependances stables
Alertes bruyantes mais expliquees

Surveiller
Signal faible ou intermittent
Impact utilisateur non confirme
Fenetre de stabilisation attendue
Validation supplementaire en cours

Corriger en avant
Cause identifiee et correction bornee
Blast radius plus faible qu'un rollback complet
Validation immediate disponible
Retour arriere de la correction possible

Rollbacker
Degradation utilisateur confirmee
Regression liee a la version ou configuration
Pas de correction bornee disponible dans la fenetre
Rollback teste ou procedure connue
Critere de succes apres rollback defini

Cette matrice doit être préparée avant l’incident. Pendant l’incident, l’équipe ne devrait remplir que les preuves et choisir la ligne correspondante.

Valider le rollback comme un changement de production

Un rollback n’est pas une annulation magique. C’est un changement de production qui peut échouer, masquer une autre cause ou réintroduire une ancienne limite. Il faut donc le valider avec les mêmes signaux que ceux qui ont justifié la décision.

Avant rollback
Version ou configuration cible identifiee
Commande ou procedure relue
Impact attendu ecrit
Canal de notification conserve
Heure de debut horodatee

Pendant rollback
Surveiller erreurs utilisateur
Surveiller latence p95 ou SLO principal
Surveiller dependances critiques
Garder les logs actifs

Apres rollback
Comparer 15 minutes avant/apres
Confirmer retour du signal utilisateur
Verifier absence de nouvelle erreur critique
Capturer la preuve de stabilisation
Ouvrir la correction durable ou post-incident

La validation doit aussi dire quoi faire si le rollback ne réduit pas l’impact. Dans ce cas, il faut revenir au diagnostic de dépendance, de routage, d’identité ou de plateforme au lieu d’enchaîner des rollbacks à l’aveugle.

Automatiser la collecte, pas la décision sensible

L’automatisation peut préparer la décision sans la prendre seule. Un job AWX, un script ou un agent interne peut collecter les mêmes requêtes KQL, produire un résumé et attacher les preuves au ticket. La décision de rollback reste humaine tant que l’organisation n’a pas prouvé que le périmètre, les seuils et le retour arrière sont sûrs.

Collecte automatique acceptable
Fenetre de deploiement
Taux d'erreur avant/apres
Latence avant/apres
Operations les plus touchees
Dependances en echec
Version ou revision observee
Liens vers dashboards et logs

Validation humaine obligatoire
Confirmer impact utilisateur
Choisir rollback ou correction en avant
Accepter le risque du retour arriere
Declencher le changement sensible
Confirmer la stabilisation

Cette séparation garde l’outillage utile sans transformer l’incident en bouton rouge automatique.

Conclusion

Décider un rollback après déploiement n’est pas une question d’intuition ou de courage. C’est une chaîne de preuves : fenêtre de changement, impact utilisateur, comparaison avant/après, corrélation avec la version, état des dépendances, critères stop/go et validation après action.

Azure Monitor et KQL donnent la matière, mais le runbook donne la décision. Quand les critères sont prêts avant l’incident, l’équipe peut agir vite sans couper les alertes, sans confondre bruit et régression, et sans rollbacker plus large que nécessaire.