AgentSRE : Agents IA composables pour la remédiation autonome des incidents sur AWS

Le cycle des incidents qui envahit la journée d’un SRE

Une grande partie de la journée d’un ingénieur en fiabilité des sites est consacrée à un cycle répétitif : une alerte est déclenchée, quelqu’un s’en occupe, la cause racine est identifiée, une correction est appliquée et le ticket est fermé. Chaque étape prend du temps, et le temps moyen de résolution (MTTR) peut varier de quelques minutes à plusieurs heures. À mesure que les infrastructures cloud se développent, cette routine manuelle devient un goulot d’étranglement.

AgentSRE est une plateforme autonome de gestion des incidents sur AWS conçue pour résoudre ce problème. Elle gère un incident de sa détection à sa résolution grâce à des agents IA composables, chacun spécialisé dans un type différent de tâche de correction. La conception considère la correction comme un ensemble d’agents coopérant entre eux plutôt que comme un seul script d’automatisation monolithique, et les raisons de cela sont expliquées ci-dessous.

À quoi ressemble un incident typique

Imaginez une alerte CloudWatch qui signale une forte latence de lecture sur une base de données. L’ingénieur de garde reçoit une notification, ouvre un tableau de bord, vérifie les métriques et consulte les journaux des requêtes lentes, pour finalement découvrir qu’un index manquant force des scans complets de la table. Il rédige alors une instruction CREATE INDEX, confirme que la correction a fonctionné et met à jour le ticket.

Tous ces étapes sont nécessaires, mais la plupart relèvent de tâches mécaniques. L’ingénieur ne résout pas un nouveau problème ; il suit un schéma de diagnostic et de réparation familier, ce qui a des conséquences réelles. Changer de contexte, naviguer dans les tableaux de bord et exécuter des requêtes manuellement ajoutent du temps, surtout lorsque l’incident dure plus longtemps que nécessaire.

Si le schéma de diagnostic est bien compris et que la solution à appliquer est clairement définie, tout le cycle peut être automatisé, avec une personne chargée d’approuver la modification. AgentSRE couvre l’ensemble du cycle de vie des incidents en cinq étapes : détection, enquête, décision, exécution et clôture.

La caractéristique distinctive réside dans la manière dont l’exécution est organisée. Un script unique et complexe qui tente toutes les solutions possibles est remplacé par des agents spécialisés, un par catégorie : un agent de base de données pour la correction des problèmes SQL et un agent de file d’attente pour gérer les messages. Chaque agent constitue sa propre machine à états, ce qui permet de le développer, de le tester et de le déployer séparément, et de nouveaux types d’agents peuvent être ajoutés sans modifier les existants. La composabilité est le principe de conception central. Elle reflète la façon dont une équipe opérationnelle répartit les problèmes entre des spécialistes, et elle permet à la plateforme de s’étoffer au fur et à mesure que de nouvelles méthodes de correction apparaissent.

Architecture en bref

La plateforme fonctionne entièrement sur des services gérés par AWS, ce qui permet de maintenir les coûts opérationnels faibles et une mise à l’échelle automatique.

Dans le diagramme d’architecture, tout commence à gauche avec une alarme CloudWatch qui alimente un pipeline basé sur des événements. Les sujets SNS diffusent la notification, un script Lambda d’alerte ouvre l’incident dans ServiceNow, et l’agent AWS DevOps commence à enquêter de lui-même. Les résultats de son analyse apparaissent dans une interface React divisée en sections Chat, Incidents et Rapports. En bas, trois vues de topologie montrent aux opérateurs à quoi ressemble visuellement chaque incident. Une seule illustration couvre ainsi tout le parcours, de la détection à la visualisation, sans que aucune étape n’attende une transmission manuelle.

Détection

Le premier signal est une alarme CloudWatch déclenchée par une anomalie, comme une latence élevée des lectures, l’épuisement des connexions ou une file de lettres mortes qui continue de croître. Elle publie des informations sur un sujet SNS, ce qui déclenche le fonctionnement du Lambda d’alerte, lequel ouvre immédiatement un incident dans ServiceNow et lance l’enquête de l’agent AWS DevOps. Cette étape ne nécessite absolument pas d’intervention humaine.

Enquête

L’agent AWS DevOps est un service géré qui mène l’enquête de manière autonome. Il examine les métriques CloudWatch, les informations Performance Insights de RDS ainsi que les journaux des requêtes lentes, et décide lui-même quels données sont pertinentes compte tenu de l’alarme. Un Lambda asynchrone collecte les résultats et les enregistre dans DynamoDB.

Amazon Bedrock, qui exécute Claude, synthétise ensuite les résultats en une brève description de la cause racine, une évaluation de l’impact et des mesures correctives recommandées. Ce résumé apparaît en haut de l’affichage de l’enquête, tandis que l’analyse complète est disponible en dessous.

L’écran capturé montre l’affichage des résultats de l’enquête, avec d’abord le résumé et ensuite les détails.

Décision et gouvernance

Des vérifications de sécurité sont effectuées avant toute modification. Les mécanismes de contrôle examinent chaque instruction SQL et rejetent celles qui sont destructrices, comme la suppression d’une table ou la suppression de lignes sans clause WHERE. L’action reçoit un niveau de risque et est envoyée à une personne pour validation. La boîte de dialogue de confirmation présente l’instruction exacte, la ressource cible ainsi que les modalités de réversion.

Cette étape humaine est intentionnelle. Une autonomie totale est puissante, mais les modifications en production méritent un jugement humain, surtout pour les opérations à plus haut risque.

Le dialogue ci-dessus est ce que voit un opérateur lorsqu’on lui demande de confirmer une correction.

Affecter la correction au bon agent

Lorsqu’une correction est approuvée, l’orchestrateur classe la catégorie de la solution et envoie la demande à l’agent approprié. C’est là que la composabilité se révèle utile.

Le diagramme décrit en détail le processus de correction. Lorsque quelqu’un approuve une solution, l’orchestrateur prend le relais et effectue trois tâches : il identifie la cause racine, applique les mécanismes de sécurité SQL et transmet la demande au spécialiste compétent, tout en enregistrant l’opération dans DynamoDB. Par la suite, deux voies s’offrent. Du côté de la base de données, une machine à états LangGraph intégrée à Amazon Bedrock AgentCore valide le SQL avec un analyste IA, l’exécute contre la base de données via une fonction Lambda située dans le VPC, et enregistre le résultat ainsi qu’une entrée d’audit dans Jira. Du côté de la file d’attente, le fonctionnement est similaire pour des tâches telles que l’évacuation d’une file de lettres mortes ou l’envoi de messages vers leur source initiale.

Aucun agent n’accède directement aux ressources. Chacun fait appel à des outils de passerelle : une fonction de passerelle qui se connecte à RDS pour l’agent de base de données, et une autre qui effectue des opérations SQS pour l’agent de file d’attente. Cette conception permet de garder les agents légers tout en assurant un accès contrôlé aux ressources et leur traçabilité. Une fois que l’une ou l’autre branche est terminée, un pipeline de résultats partagé enregistre le résultat dans DynamoDB, ajoute une note dans ServiceNow, résout la demande et met à jour la topologie, de sorte que chaque incident se termine de manière cohérente, quel que soit l’agent qui s’en est occupé.

Comment fonctionne la classification

L’intelligence qui rend cela possible se trouve dans l’orchestrateur. Lorsque l’AWS DevOps Agent termine son travail, il produit une analyse des causes racines en langue naturelle ; l’orchestrateur la lit puis attribue une catégorie de correction avant que tout agent ne s’exécute.

La classification s’effectue en deux étapes. Un analyseur structuré cherche d’abord dans les données analysées un bloc de correction prédéfini indiquant le type de correction, la ressource cible et l’action prévue. En l’absence de ce bloc, l’orchestrateur fait appel à un classificateur basé sur un modèle de langage d’Amazon Bedrock, qui lit la description libre de la cause ainsi que le contexte initial de l’alarme pour déterminer la catégorie. Le contexte de l’alarme permet de relier le symptôme à la correction appropriée. Une forte latence de lecture suggère l’ajout d’un index de base de données, des connexions épuisées indiquent la nécessité d’arrêter une requête bloquante, et une file de messages non traités en croissance nécessite un nettoyage ou une relance.

Une fois la catégorie définie, le routage devient déterministe : les données de base sont acheminées vers l’agent de bases de données, et les files d’attente vers l’agent de files d’attente. Le fait de séparer la classification de l’exécution facilite les ajouts ultérieurs, car une nouvelle catégorie se contente d’être associée à un nouvel agent sans que la logique de routage ne change.

Les deux agents de production

AgentSRE inclut deux agents de production, chacun conçu pour une catégorie spécifique de corrections. Tous deux fonctionnent sous forme d’environnements d’exécution containerisés sur Amazon Bedrock AgentCore et partagent une architecture interne similaire : une machine à états LangGraph composée de quelques nœuds bien définis, chacun équipé de mécanismes permettant d’enregistrer son temps d’exécution et son résultat.

L’agent de bases de données

Cet agent gère toutes les corrections basées sur SQL. Son architecture suit un flux de travail typique des opérations sur les bases de données, organisé en machine à états dotée d’une couche de routage qui sélectionne l’étape suivante en fonction de l’état actuel.

Lorsqu’une demande arrive, l’agent sélectionne d’abord la base de données cible ainsi que la requête SQL suggérée dans l’incident. Ensuite vient la validation, au cours de laquelle un analyste IA exécuté sur Bedrock examine la requête pour s’assurer qu’elle est bien formulée et sûre. Ce contrôle sémantique s’ajoute aux mécanismes de protection déterministes déjà mis en œuvre par l’orchestrateur, de sorte qu’une requête défectueuse ou dangereuse rencontre une deuxième barrière.

Lorsque la validation est réussie, l’agent exécute la requête, mais pas directement. Il appelle une fonction Lambda située dans la VPC, qui se connecte à l’instance RDS cible via une authentification IAM. Les identifiants de la base de données et l’accès réseau restent ainsi confinés à un seul composant contrôlé, tandis que l’agent reste léger, sans connexion directe à la base de données.

Un seul pipeline gère une série de correctifs. L’agent peut créer un index manquant pour résoudre les retards de lecture, terminer une requête bloquante qui détient des verrous et épuise les connexions, ou exécuter d’autres instructions correctives selon les besoins. Par la suite, il enregistre le résultat, y compris les lignes affectées et le temps d’exécution, et crée une entrée correspondante dans Jira ainsi qu’un enregistrement d’audit complet. Étant donné que le même pipeline de validation, d’exécution et d’audit sert à chaque opération SQL, il n’est pas nécessaire de modifier la structure de l’agent pour intégrer un nouveau type de correction de base de données.

L’agent de file d’attente

L’agent de file d’attente gère les problèmes liés aux messages, le plus souvent une file de lettres mortes où s’accumulent des messages échoués. Il suit la même séquence en trois étapes de validation, d’exécution et d’audit, mais avec une logique spécifique aux files d’attente.

La validation montre pourquoi la sécurité est primordiale pour un agent de file autonome. Avant d’effectuer toute action destructrice, il s’assure que la file cible est bien une file de lettres mortes, d’abord en vérifiant le format ARN, puis en interrogeant son outil de passerelle au sujet des attributs de la file. Une file qui n’est pas une file de lettres mortes fait immédiatement arrêter l’agent en signalant une défaillance de sécurité, plutôt que de prendre le risque d’utiliser une file de production active. Effacer la mauvaise file détruirait les messages en transit, et ce risque justifie amplement une vérification spécifique.

Lorsque la validation est réussie, l’une de deux actions a lieu. La suppression efface tous les messages accumulés dans la file des lettres mortes, c’est-à-dire ceux considérés comme irrécupérables. La réexpédition les renvoie dans la file d’origine pour une nouvelle tentative, avec une limite de vitesse configurable afin d’éviter de submerger les consommateurs ultérieurs. Un contrôle d’état est également disponible pour suivre l’avancement d’une réexpédition.

Tout comme l’agent de base de données, l’agent de file envoie chaque opération via sa propre fonction de passerelle, qui effectue les appels boto3 SQS et enregistre toutes les actions aux fins d’audit. Il accepte soit une demande structurée, soit un texte en langue naturelle, et extrait l’action ainsi que l’ARN de la file à partir de chacun d’eux.

Indépendance par conception

Aucun agent ne connaît l’autre. Chacun dispose de sa propre machine à états, d’outil de passerelle et de mécanisme de validation adaptés à son domaine. Seul l’orchestrateur voit les deux, et il ne fait rien d’autre que de classer et diriger les actions.

Cette indépendance est ce que signifie concrètement la composabilité. Un troisième agent, chargé de redémarrer un conteneur, de renouveler des identifiants ou de modifier une politique d’échelle, suivrait la même méthode : une machine à états LangGraph qui effectue les étapes de validation, d’exécution et d’audit, ainsi qu’un outil de passerelle propre à cet agent. Il s’enregistre alors dans une nouvelle catégorie auprès de l’orchestrateur, tandis que les agents existants restent inchangés. La croissance s’obtient en ajoutant de nouveaux éléments, jamais en les modifiant.

Rapports et clôture

Lorsque le travail est terminé, l’agent indique si cela a réussi, combien de lignes ont été modifiées et combien de temps cela a pris. Le résultat est enregistré dans DynamoDB et ajouté à l’incident ServiceNow en tant que note de travail ; une exécution réussie résout alors le ticket sans besoin d’autres interventions. Toutes les étapes sont enregistrées, ce qui permet de disposer d’un historique complet allant du premier alarme jusqu’à la résolution.

L’interface d’opérations

L’automatisation effectue le travail, mais les opérateurs ont toujours besoin d’un endroit pour surveiller, diriger et comprendre ce qui se passe. AgentSRE dispose d’une interface web personnalisée, développée avec React et hébergée sur AWS Amplify, qui constitue une vue d’ensemble unique pour l’intégralité du cycle de vie de l’incident. L’accès s’effectue via le single sign-on Microsoft Entra ID, de sorte que le fournisseur d’identité de l’organisation contrôle qui peut utiliser les outils de gestion opérationnelle. L’interface comprend trois zones, chacune répondant à un besoin différent.

Chat

Chat est une interface de conversation pour l’AWS DevOps Agent. Les opérateurs posent des questions en langage simple concernant l’état d’une base de données donnée, la présence d’alertes actives ou l’avancement d’une enquête. En saisissant un numéro d’incident, une enquête complète débute directement depuis la conversation. L’interface conserve le contexte des échanges entre les messages et gère les réponses lentes en tentant à nouveau en arrière-plan, afin que les opérateurs obtiennent une réponse et non une erreur.

L’aperçu d’écran montre l’interface de conversation.

Incidents

Incidents est le tableau de bord pour les opérations quotidiennes. Chaque incident affiche son statut, indiquant s’il a été examiné et si une correction a été appliquée. Un opérateur peut y lancer une enquête, lire la cause racine, examiner la topologie et commencer les actions correctives. La correction ne nécessite qu’un clic, suivi d’une boîte de dialogue de confirmation affichant le changement précis avant son exécution.

Ceci est le tableau de bord des incidents.

Rapports

Les rapports fournissent des analyses détaillées sur tous les incidents : nombre d’enquêtes, taux de résolution, MTTR ainsi que des répartitions par priorité et par ressource. Ils transforment les données relatives à un seul incident en informations opérationnelles au fil du temps.

La vue des rapports apparaît ci-dessus. Dans la vue d’enquête, l’interface propose également une visualisation de la topologie, décrite ci-après, qui transforme des analyses complexes en graphiques interactifs permettant de comprendre rapidement la situation.

Intégration avec ServiceNow

Une plateforme autonome qui ignorerait les systèmes existants de gestion des services informatiques créerait plus de problèmes qu’elle n’en résoudrait. C’est pourquoi AgentSRE s’intègre directement à ServiceNow, ce qui signifie que chaque incident qu’il gère est reflété dans le système de données sur lequel les équipes opérationnelles comptent déjà.

L’information circule dans les deux sens tout au long du cycle de vie. Lorsqu’une alarme CloudWatch se déclenche, la fonction Lambda chargée des alertes crée automatiquement un incident dans ServiceNow, prérempli des détails de l’alarme, de sa priorité et de sa catégorie, après avoir d’abord cherché un incident existant pour éviter les doublons. Ainsi, le ticket est créé dès le début sans qu’il soit nécessaire de le soumettre manuellement.

Au fur et à mesure que l’incident progresse, AgentSRE publie des mises à jour sur le ticket. Les résultats de l’enquête sont ajoutés sous forme de notes de travail, afin que toute personne consultant le ticket puisse voir l’analyse complète de la cause racine dans son contexte. Lorsqu’une correction est appliquée, les résultats, incluant les actions entreprises, l’issue obtenue et une date et heure, sont enregistrés sous forme d’une autre note de travail. Après une correction réussie, la plateforme transfère le ticket dans l’état « résolu » et y ajoute des notes décrivant la solution trouvée.

Le résultat est un registre complet et auditable au sein de ServiceNow qui reflète l’ensemble du flux de travail automatisé. Les équipes continuent à travailler avec l’outil qu’elles connaissent, tandis que l’automatisation s’occupe du travail pénible ; le respect des processus existants permet à la plateforme d’être adoptée au sein d’une entreprise plutôt que de rester un système parallèle dont les utilisateurs devraient apprendre les particularités séparément.

Ceci est un ticket ServiceNow après que la plateforme l’a mis à jour.

Voir ce qui s’est passé : vues de topologie

Savoir ce qui s’est produit lors d’un incident est presque aussi important que de le résoudre, et une image communique mieux qu’un texte dense. AgentSRE propose trois vues de topologie, chacune affichée sous forme de graphique interactif.

Topologie d’enquête

Cette vue montre le rayon d’explosion : quels ressources sont affectées et comment elles sont connectées. La ressource à l’origine du problème est mise en évidence de manière distincte, et des bords animés suivent le parcours de la panne à mesure que celle-ci se propage. Le graphique est généré dynamiquement à partir des résultats de l’enquête, de sorte que différents incidents produisent des topologies différentes, car chaque graphique reflète ce que l’agent a réellement découvert.

La vue ci-dessus présente une topologie d’enquête.

Topologie de l’infrastructure

Cette carte montre toute l’architecture : chaque passerelle API, fonction Lambda, agent, base de données, file d’attente et composant de surveillance, ainsi que les liens entre eux. Elle permet aux opérateurs d’avoir une vision complète de l’installation et du parcours suivi par les requêtes.

La carte de l’infrastructure montre le même système.

Topologie de l’agent composable

Cette vue suit pas à pas le parcours de correction : la déclenchement par l’utilisateur, la classification par l’orchestrateur, l’appel de l’agent, l’utilisation d’outils de passerelle, la modification des ressources et le résultat final affiché dans ServiceNow. Chaque nœud représente un composant réel invoqué au cours de la correction, ce qui permet à l’architecture composable de cesser d’être une idée abstraite pour devenir quelque chose que les opérateurs peuvent voir et vérifier.

La topologie de l’agent montre une seule exécution de correction.

La topologie est extraite par une méthode hybride. Un outil d’extraction basé sur des règles construit immédiatement et gratuitement le graphe lorsque l’incident correspond à un schéma connu. Pour tout élément inconnu, le système demande à Bedrock Claude d’extraire la topologie à partir du texte de l’enquête. Les cas courants sont traités rapidement, tandis que les cas inhabituels sont tout de même gérés.

Pourquoi la composabilité est avantageuse

Concevoir les solutions correctives sous forme d’agents composables plutôt que comme un monolithe apporte plusieurs avantages pratiques.

• Extensibilité. Une nouvelle catégorie de correction, telle que redémarrer un conteneur, ajuster une politique d’échelle ou renouveler des identifiants, nécessite simplement la création d’un agent à enregistrer auprès de l’orchestrateur, sans affecter les agents existants.
• Testabilité. Une machine à états unique avec des entrées et sorties définies peut être testée de manière isolée, ce qui réduit le risque qu’un changement dans un agent endommage un autre.
• Observabilité. Chaque agent suit une machine à états définie, ce qui permet de tracer et de visualiser son exécution ; la vue de la topologie des agents composables découle directement de cette conception.
• Reutilisabilité. Un seul agent peut gérer de nombreux incidents. Par exemple, l’agent de base de données s’occupe de la création d’index, de la fin des requêtes et d’autres corrections SQL sans modification.

Stack technologique

La plateforme combine ces services AWS et frameworks open source, regroupés par fonction :

• Le suivi et les alertes proviennent d’Amazon CloudWatch, tandis que l’orchestration basée sur des événements est assurée par Amazon SNS en collaboration avec AWS Lambda.
• L’enquête est gérée par l’AWS DevOps Agent, tandis qu’Amazon Bedrock avec Claude s’occupe du raisonnement, des résumés et de l’extraction de la topologie.
• Amazon Bedrock AgentCore héberge les agents, et LangGraph fournit leurs machines à états.
• Amazon DynamoDB stocke les données d’état et de contrôle, et ServiceNow gère le cycle de vie des tickets.
• L’interface utilisateur utilise React avec React Flow pour afficher l’interface et les graphes de topologie, hébergés sur AWS Amplify.

Impact mesuré

L’automatisation de ce cycle apporte des avantages mesurables. Manuellement, une enquête suivie d’une correction peut prendre entre une et quatre heures, tandis qu’AgentSRE permet de passer de l’alerte à la résolution en moins de dix minutes. L’enquête prend généralement de trois à cinq minutes, et une correction validée s’effectue en moins de trente secondes.

La cohérence s’améliore tout comme la vitesse. Tous les incidents font l’objet de la même enquête approfondie, des mêmes vérifications de sécurité et d’un historique d’audit identique, de sorte que le tableau des équipes de garde ne détermine pas la qualité de la réponse.

Où cela peut aller ensuite

La base composable ouvre plusieurs pistes. D’autres agents pourraient gérer les correctifs au niveau de l’infrastructure via Systems Manager ou Terraform. Les processus d’approbation pourraient être acheminés à travers des outils de collaboration tels que Microsoft Teams. Une couche de connaissances pourrait intégrer les leçons tirées d’incidents passés afin d’améliorer les recommandations futures. Et comme le modèle des agents n’est pas lié à un seul cloud, la même approche pourrait être étendue aux environnements multi-cloud.

Les enseignements architecturaux

La gestion autonome des incidents s’avère à la fois pratique et réalisable lorsqu’elle repose sur les bonnes principes : enquête autonome, agents de correction composables, approbation humaine et vues topologiques détaillées. Ensemble, ils réduisent fortement le temps moyen de résolution tout en préservant la sécurité et une traçabilité complète.

La leçon principale concerne l’architecture. Diviser les tâches de correction en agents spécialisés et composables, au lieu d’utiliser une seule solution d’automatisation, correspond à la manière dont les équipes opérationnelles travaillent réellement, permet au système de rester ouvert à l’extension et rend chaque action visible. À mesure que les environnements cloud deviennent de plus en plus complexes, c’est une approche évolutive pour des opérations pilotées par l’IA.