Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Votre agent diagnostique les problèmes et les résout. Il redémarre les services, met à l’échelle les ressources, renforce les paramètres de sécurité et collecte les diagnostics, avec le niveau de contrôle que vous choisissez.
[! VIDEO <VIDEO_URL/Azure_SRE_Agent__Verified_Fix.mp4> ]
Conseil / Astuce
- Demandez à votre agent de résoudre un problème. Il propose une solution, vous l’approuvez et exécute le correctif.
- Piste d’audit complète : qui l’a déclenchée, ce qui a changé et s’il a fonctionné.
- Choisissez votre niveau de confiance : mode révision (approuver chaque action) ou mode autonome (agent le gère).
Le problème : le diagnostic sans action perd du temps
Vous avez identifié le problème. Et maintenant ? Vous allez dans le portail Azure, trouvez le bon volet, confirmez la ressource, cliquez dans les boîtes de dialogue de confirmation, attendez la fin de l’opération, puis vérifiez que cela a fonctionné. L’enquête a pris cinq minutes. Le correctif prend encore dix minutes.
Cette friction existe dans vos flux de travail opérationnels :
- Opérations quotidiennes : Mettez à l’échelle les ressources pour la charge attendue, redémarrez les services pendant les fenêtres de maintenance.
- Vérifications de conformité : renforcer les paramètres de sécurité sur des dizaines de comptes de stockage.
- Réponse à l’appel : exécutez rapidement des correctifs connus afin que les ingénieurs puissent revenir en veille.
- Optimisation proactive : ajustez les références SKU en fonction des modèles d’utilisation avant que des problèmes ne se produisent.
Comment votre agent ferme la boucle
Lorsque votre agent identifie un problème, il ne s’arrête pas à vous dire ce qui est incorrect. Il propose une action de correction spécifique et, selon votre mode d’exécution, attend votre approbation ou exécute immédiatement l’action.
L’agent suit un modèle cohérent : diagnostiquer → identifier l’action → vérifier les autorisations → exécuter (ou proposer) → vérifier que le correctif a fonctionné. Chaque action est journalisée avec qui l’a déclenchée, ce qui a changé, pourquoi et s’il a réussi.
Après avoir examiné, votre agent peut prendre des mesures directes, créer des éléments de suivi ou informer votre équipe, chacune avec un contexte complet.
Ce qui rend cela différent des scripts
Les scripts sont rigides. Ils exécutent la même action, quel que soit le contexte. Votre agent raisonne d'abord sur la situation. Il considère ce qu’il a trouvé lors de l’enquête, ce qu’il se souvient des incidents passés et ce que vos compétences et votre base de connaissances recommandent. Le même symptôme peut entraîner un redémarrage dans un cas et une montée en puissance dans un autre, car l’agent s’adapte en fonction des preuves.
Les modes de fonctionnement vous offrent un degré de confiance échelonné. Commencez en mode Révision où l’agent propose et vous approuvez. Passez à Autonome lorsque vous êtes confiant dans le modèle. Utilisez ReadOnly pour les agents de surveillance uniquement qui ne prennent jamais d’action.
Ce que votre agent peut faire
Votre agent peut exécuter n’importe quelle action Azure via des commandes Azure CLI. Si vous pouvez l’exécuter dans az, votre agent peut l’exécuter également. Cette fonctionnalité inclut la gestion de n’importe quel type de ressource, la modification des configurations, la création de ressources et l’exécution d’une opération Azure.
| Type de commande | Ce que cela permet |
|---|---|
| Lire les commandes | Interroger n’importe quelle ressource Azure - az webapp list, az containerapp show, az vm list, az network vnet show. S’exécute immédiatement, aucune approbation n’est nécessaire. |
| Écrire des commandes | Modifier n’importe quelle ressource Azure : az webapp restart, az containerapp update, az vm resize, az role assignment create. Nécessite l’approbation en mode Révision. |
Les actions de l’agent sont limitées uniquement par les autorisations affectées à son identité managée. Si vous accordez le rôle de Contributeur sur un groupe de ressources, votre agent peut gérer l'ensemble des éléments de ce groupe. Si vous accordez un rôle personnalisé avec des actions spécifiques, votre agent est limité à ces actions.
Garde-fous de sécurité
L’agent applique des contraintes de sécurité au niveau de la commande.
-
Opérations de suppression bloquées — L'agent n'exécute jamais les commandes
deleteetremove. Elle retourne une erreur qui dirige les utilisateurs vers le portail Azure pour les suppressions. -
Commandes Key Vault bloquées : l’agent bloque toutes les
az keyvaultcommandes pour empêcher l’exposition des informations d’identification. - Verrous de gestion respectés : avant de modifier une ressource, l’agent recherche les verrous de gestion Azure. Les ressources avec des verrous ReadOnly ne peuvent pas être modifiées.
- Validation de l’abonnement : l’agent valide les ID d’abonnement dans les commandes pour un format GUID correct avant l’exécution.
Avant et après
Le tableau suivant compare le processus d’atténuation manuel à l’approche assistée par agent.
| Avant | Après | |
|---|---|---|
| Correction de l’exécution | Accédez au portail Azure, recherchez la ressource, cliquez sur les lames | Demander à l’agent, approuver, terminé |
| Vérification | Vérifier manuellement si le correctif a fonctionné | L’agent vérifie et signale le résultat |
| Audit | J’espère que quelqu’un a documenté ce qu’ils ont fait | Piste d’audit complète dans Application Insights |
| Connaissances | Un ingénieur connaît le correctif | L’agent applique des modèles appris de manière cohérente |
Spécifications relatives aux autorisations
Par défaut, les agents disposent d’un accès Lecteur et ne peuvent pas effectuer d’actions. Vous accordez explicitement des autorisations d’écriture en affectant des rôles à l’identité managée de votre agent.
| Étendue | Sur quoi l’agent peut agir | Recommandé pour |
|---|---|---|
| Ressource | Une seule ressource | Restriction maximale, commencez ici |
| Groupe de ressources | Toutes les ressources d’un groupe | Charges de travail de production |
| Subscription | Toute ressource de l’abonnement | Développement et test uniquement |
Avertissement
L’agent vérifie les verrous de gestion Azure avant de modifier n’importe quelle ressource. Vous ne pouvez pas modifier les ressources avec des verrous ReadOnly, quelles que soient les autorisations ou le mode d’exécution. Les opérations de suppression et de retrait sont entièrement bloquées. Vous pouvez utiliser le portail Azure pour les suppressions.
Autres chemins de réponse
Les atténuations directes ne sont pas la seule option. De nombreuses équipes préfèrent acheminer les résultats vers des éléments de travail ou des systèmes de ticket au lieu d’exécuter directement des actions. Les éléments de travail sont particulièrement utiles lorsque l’examen humain est nécessaire ou que les processus de gestion des modifications s’appliquent.
| Chemin de réponse | Fonctionnement | Idéal pour |
|---|---|---|
| Atténuation directe | L’agent exécute le redémarrage, la mise à l’échelle ou le renforcement | Modèles approuvés, non-production |
| Créer un élément de travail | L’agent crée un problème GitHub ou un élément de travail Azure DevOps | Révision humaine dans la boucle, gestion des changements |
| Envoyer une notification | L'agent publie sur Teams ou envoie des e-mails | Sensibilisation sans action |
| Déclencheur de flux de travail | L’agent distribue GitHub Actions ou Logic Apps | Intégration CI/CD, processus à plusieurs étapes |
Configurez la création et les notifications d’éléments de travail via des connecteurs. Par exemple, connectez un serveur GitHub MCP pour permettre à votre agent de créer des problèmes ou connectez Azure DevOps pour créer automatiquement des éléments de travail.
Pour plus d’informations, consultez Envoyer des notifications et l’automatisation du flux de travail pour chaîner ces types de réponse ensemble.
Exemple : atténuation déclenchée par incident
L’exemple suivant montre comment votre agent gère un incident de mémoire à 3 h 47 pendant que vous dormez.
3:47 AM — PagerDuty déclenche une alerte : « Mémoire élevée sur prod-api »
Votre agent (en mode Révision) gère tout :
Reconnaît l’incident : PagerDuty affiche « Reconnu par l’agent SRE ».
Examine automatiquement :
- Requêtes App Insights : mémoire à 94 %, en augmentation sur 2 heures.
- Vérifie l’historique du déploiement : aucun déploiement récent.
- D'après mes souvenirs : « La dernière fois que cela s'est produit, un redémarrage a résolu le problème. »
Propose un correctif — Publications sur le thread d’incident :
Memory at 94% on prod-api (App Service). Recommended action: Restart the App Service. Evidence: - Memory climbing since 1:30 AM - No recent deployments - Past incident: restart resolved similar issue on 2026-01-15 [Approve] [Deny]Vous approuvez (ou en mode autonome, l’agent s’exécute immédiatement).
L’agent s’exécute et vérifie :
✓ Restarted prod-api ✓ Memory now at 42% ✓ Incident resolved
Que s'est-il passé: Vous avez cliqué sur Approuver et l’agent géré l’investigation, l’action et la vérification.
Piste d’audit
Le système enregistre chaque action d’atténuation ainsi que le contexte complet.
| Champ | Informations capturées |
|---|---|
| Identité | L’agent et l’identité managée |
| Action | Opération exacte effectuée |
| Timestamp | Lors de l’exécution de l’opération |
| Trigger | Diagnostic ou état qui a conduit à l’action |
| Résultat | Réussite ou échec, avec la vérification post-action |
Vous pouvez interroger la piste d’audit dans Application Insights via Monitor > Logs dans le portail de l’agent. Le système journalise chaque az commande en tant qu’événement AgentAzCliExecution personnalisé. Pour plus d’informations, consultez Actions de l’agent d’audit.