Automation
Azure Automation : diagnostiquer un runbook avant de relancer le job
Un runbook de production pour qualifier un échec Azure Automation avec identité managée, paramètres, modules, Hybrid Worker, webhooks, logs, validation et rollback avant de relancer.
Un runbook Azure Automation qui échoue en production pousse souvent à cliquer sur Rerun trop vite. Le job a peut-être expiré, un module a changé, une identité managée a perdu un rôle, un Hybrid Worker n’a plus la même connectivité, une variable Automation contient une ancienne valeur, ou le webhook a reçu un payload incomplet. Relancer sans qualifier l’état peut rejouer une action partielle : rotation de secret, nettoyage de ressources, bascule de configuration, correction RBAC ou tâche de maintenance.
Le cas d’usage est un runbook PowerShell ou Python utilisé par l’exploitation pour appliquer une opération limitée sur Azure. Il s’exécute soit dans Azure Automation, soit sur un Hybrid Runbook Worker pour atteindre un réseau privé. Le but du runbook de diagnostic est de décider si le job peut être relancé tel quel, doit être relancé avec un paramètre corrigé, doit être rollbacké, ou doit rester bloqué jusqu’à correction du contrat d’automatisation.
Figer le contrat du job
Commencez par décrire ce que le job devait faire, pas seulement le message d’erreur. Un runbook est une interface de production : paramètres, identité, cible, préconditions, effets de bord, idempotence et validation.
Incident
Automation Account: aa-prod-ops
Runbook: rotate-expiring-app-secret
JobId: 7f7f3c1a-0000-0000-0000-000000000000
Mode: Azure sandbox ou Hybrid Worker
Declencheur: manuel, schedule, webhook ou pipeline
Cible: application, resource group, abonnement, tenant
Effet attendu: preparer ou appliquer la rotation
Derniere etape certaine avant echec
Validation attendue apres execution
Rollback connu ou point de non-retour
Questions avant relance
Le job est-il idempotent ?
Une action partielle a-t-elle deja ete appliquee ?
Les parametres viennent-ils d'un webhook, d'une variable ou d'un appel manuel ?
L'identite runtime est-elle bien celle attendue ?
La connectivite du Hybrid Worker est-elle necessaire ?Si l’équipe ne sait pas répondre à ces questions, la relance est déjà un changement de production, pas une simple reprise technique.
Lire l’état réel du job
Récupérez l’état du job, les paramètres reçus, les streams et le contexte d’exécution. Ne vous contentez pas du statut visible dans le portail.
RG="rg-automation-prod"
ACCOUNT="aa-prod-ops"
JOB_ID="7f7f3c1a-0000-0000-0000-000000000000"
az automation job show --resource-group "$RG" --automation-account-name "$ACCOUNT" --name "$JOB_ID" --output json
az automation job output --resource-group "$RG" --automation-account-name "$ACCOUNT" --job-id "$JOB_ID" --stream Any --output tableConservez l’heure de début, l’heure de fin, le runbook publié, les paramètres et le worker utilisé. Ce sont les éléments qui permettent de comparer une relance avec l’exécution échouée.
Séparer paramètres, variables et secrets
Un runbook échoue souvent parce que son entrée a dérivé. Le code n’a pas changé, mais la variable Automation, le webhook, le schedule ou le secret référencé ne correspond plus au contrat attendu.
Verifier les entrees
Parametres fournis au job
Valeurs par defaut du runbook publie
Variables Automation lues pendant l'execution
Credentials ou certificats Automation encore utilises
Secrets Key Vault referencees par le runbook
Payload webhook et schema attendu
Heure de declenchement et fuseau du schedule
Bloquer la relance quand
Un parametre cible est vide ou trop large
Le payload webhook ne porte pas d'identifiant de changement
Une variable globale a ete modifiee pendant l'incident
Le runbook peut toucher plusieurs environnements avec la meme entree
La relance rejouerait une etape deja termineeLe bon correctif peut être de relancer avec un paramètre borné, pas de modifier le script. Mais cette décision n’est sûre que si la cible et l’état partiel sont prouvés.
Prouver l’identité runtime
Azure Automation peut utiliser une identité managée système, une identité managée utilisateur ou un ancien Run As account. Sur Hybrid Worker, le script peut aussi dépendre du contexte local, d’un module installé ou d’un accès réseau spécifique. La relance doit prouver l’identité qui agira.
RG="rg-automation-prod"
ACCOUNT="aa-prod-ops"
az automation account show --resource-group "$RG" --name "$ACCOUNT" --query "{identity:identity, publicNetworkAccess:publicNetworkAccess}" --output json
PRINCIPAL_ID="00000000-0000-0000-0000-000000000000"
az role assignment list --assignee "$PRINCIPAL_ID" --all --query "[].{scope:scope, role:roleDefinitionName}" --output tableUne erreur AuthorizationFailed ne doit pas mener directement à un rôle plus large. Vérifiez d’abord que le runbook utilise la bonne identité, le bon tenant, le bon abonnement et la bonne cible.
Vérifier modules et version publiée
La version publiée du runbook et les modules importés sont une surface de changement. Une mise à jour d’Az.Accounts, Az.Resources ou d’un module interne peut modifier l’authentification, la sérialisation ou la gestion d’erreur sans changer le runbook lui-même.
RG="rg-automation-prod"
ACCOUNT="aa-prod-ops"
RUNBOOK="rotate-expiring-app-secret"
az automation runbook show --resource-group "$RG" --automation-account-name "$ACCOUNT" --name "$RUNBOOK" --query "{state:state, runbookType:runbookType, lastModifiedTime:lastModifiedTime, logProgress:logProgress, logVerbose:logVerbose}"
az automation module list --resource-group "$RG" --automation-account-name "$ACCOUNT" --query "[].{name:name,version:version,provisioningState:provisioningState,lastModifiedTime:lastModifiedTime}" --output tableSi le module a changé juste avant l’incident, la relance doit passer par un test contrôlé ou un rollback de module. Rejouer le job avec le même environnement instable ne valide rien.
Qualifier le Hybrid Worker avant d’accuser le script
Quand un runbook dépend d’un Hybrid Worker, l’échec peut venir du poste d’exécution : service arrêté, extension dégradée, connectivité privée, DNS, proxy, droits locaux ou module absent. Testez le worker comme un composant de production.
Verifier le worker
Groupe Hybrid Worker attendu
Machine qui a pris le job
Service agent actif
Connectivite vers Azure Automation
DNS et routage vers les ressources privees ciblees
Version PowerShell ou Python disponible
Modules locaux attendus
Acces Key Vault, Storage, API interne ou endpoint prive
Relance interdite quand
Le job peut tomber sur un worker non qualifie
Le DNS local ne resout pas la cible privee
Le worker a perdu son acces sortant controle
Les modules locaux different entre workers du meme groupe
Les logs ne disent pas quel worker a execute le jobSi le worker est la cause, le rollback peut être de retirer temporairement le worker du groupe, de corriger sa connectivité ou de forcer une exécution sur un groupe sain, pas de changer le runbook.
Corréler job, activité Azure et logs applicatifs
La preuve utile relie le job à ses effets. Cherchez les écritures Azure, les erreurs d’autorisation, les appels de dépendance et les traces applicatives autour de la fenêtre d’exécution.
let JobStart = datetime(2026-07-03T06:10:00Z);
let JobEnd = datetime(2026-07-03T06:24:00Z);
AzureActivity
| where TimeGenerated between ((JobStart - 10m) .. (JobEnd + 20m))
| where Caller has_any ("aa-prod-ops", "00000000-0000-0000-0000-000000000000")
or CorrelationId == "<job-correlation-id>"
| project TimeGenerated,
OperationNameValue,
ActivityStatusValue,
Caller,
ResourceGroup,
ResourceId,
CorrelationId,
Properties
| order by TimeGenerated ascSi le job a déjà modifié une ressource, la relance doit être traitée comme une reprise d’état, pas comme une nouvelle exécution complète.
Décider la relance, la reprise ou le rollback
La décision doit être explicite. Un job échoué peut être relancé, repris à une étape, corrigé en entrée, rollbacké ou gelé.
Relancer tel quel
Le job est idempotent
Aucune action partielle n'a ete appliquee
L'identite, les modules et le worker sont sains
L'echec vient d'un timeout ou d'une dependance temporaire prouvee
Relancer avec parametre corrige
Le payload etait incomplet ou trop large
La cible exacte est maintenant prouvee
La relance ne rejoue pas une etape terminee
Le changement est attache a un incident ou une demande validee
Reprendre manuellement ou par etape
Une action partielle est terminee
Le runbook n'a pas de checkpoint fiable
La prochaine action depend de l'etat observe
Une validation humaine est requise avant la suite
Rollbacker ou bloquer
L'identite runtime est incorrecte
Un module ou worker a derive
Le job a touche une cible non attendue
Les logs ne prouvent pas l'etat applique
La relance pourrait doubler un effet de bordLe critère central est l’idempotence réelle. Si le runbook ne sait pas détecter ce qu’il a déjà fait, la relance doit être remplacée par une reprise contrôlée.
Automatiser le paquet de diagnostic
Un bon mode opératoire n’est pas un bouton magique de relance. C’est une collecte qui produit la décision : relance, reprise, rollback ou blocage.
diagnostic_pack:
collect:
- job_state_and_streams
- input_parameters_and_webhook_payload
- runbook_published_version
- automation_variables_used
- module_versions
- runtime_identity_and_role_scope
- hybrid_worker_group_and_machine
- azure_activity_changes
- validation_signal_after_each_step
decide:
- rerun_same_inputs
- rerun_with_corrected_inputs
- resume_from_verified_state
- rollback_previous_step
- block_until_contract_fix
require_human_validation:
- production_write
- secret_rotation
- rbac_change
- network_or_firewall_change
- non_idempotent_rerunCette automatisation reste sûre parce qu’elle ne masque pas l’état. Elle donne à l’opérateur les éléments nécessaires pour agir sans improviser.
Valider après action
Après relance ou rollback, validez l’effet métier et l’état Azure. Le statut Completed du job ne suffit pas.
Validation minimale
Le job termine avec le runbook et les modules attendus
L'identite runtime correspond au principal autorise
Les ressources ciblees sont exactement celles du perimetre
Les journaux AzureActivity confirment les operations attendues
Les secrets, roles, routes ou configurations ont l'etat final prevu
Les checks applicatifs ou probes reviennent au vert
Le dossier incident contient entree, decision, action et preuve
Rollback incomplet quand
Le job est vert mais la cible n'a pas change
Une action partielle reste sans proprietaire
Le worker sain n'est pas identifie
Les modules restent en etat incoherent
La prochaine relance peut reproduire le meme incidentConclusion
Relancer un runbook Azure Automation est une décision d’exploitation. Elle doit prouver le contrat du job, l’état partiel, les paramètres, l’identité, les modules, le worker, les logs et le chemin de validation.
La bonne sortie n’est pas toujours Rerun. C’est parfois une relance bornée, une reprise manuelle, un rollback de configuration, une correction de module ou un blocage assumé jusqu’à ce que le runbook redevienne opérable. Cette discipline garde l’automatisation utile sans transformer un échec ponctuel en incident rejoué.