Circle K a réduit l’analyse des incidents de 45–60 minutes à moins de 15 minutes

Lorsqu’une alerte se déclenche, l’ingénieur ne commence généralement pas encore à réparer le système. Il ouvre d’abord les métriques, recherche les lignes pertinentes dans les journaux, vérifie l’état des conteneurs, consulte la documentation du service et examine les dernières modifications du code. Chez Circle K, cette analyse prenait 45–60 minutes. L’entreprise a précisément automatisé cette partie du travail : un agent rassemble le contexte provenant de plusieurs sources et transmet à l’ingénieur d’astreinte, dans Slack, la cause probable de l’incident, les preuves et les étapes suivantes.

Selon les métriques internes de Circle K, le temps moyen de l’analyse initiale est tombé à moins de 15 minutes, soit une réduction de 67–75 %. Les cas simples sont traités en 5–8 minutes. Il ne s’agit pas d’une expérimentation indépendante, mais d’un retour d’expérience publié par AWS sur le déploiement de son propre service. Ces chiffres doivent donc être considérés comme le résultat obtenu par une équipe précise, et non comme une promesse valable pour n’importe quelle infrastructure.

Fonctionnement de l’analyse

Le signal de Grafana passe par Amazon SNS et SQS avant d’arriver dans Lambda. Dans la première version, deux agents spécialisés travaillaient en parallèle. Le premier vérifiait l’état des tâches ECS, des équilibreurs de charge, des métriques et des journaux CloudWatch. Le second recherchait les erreurs applicatives et les traces dans OpenSearch, tout en récupérant dans la base de connaissances la fiche du service et ses dépendances.

Un troisième agent interrogeait ensuite GitHub : il trouvait le dépôt du service concerné, étudiait le code, les fichiers d’infrastructure et les derniers commits. Un dernier appel au modèle regroupait les résultats dans un rapport succinct : cause probable, faits justificatifs, propriétaire du service et actions recommandées.

Imaginons une hausse soudaine des réponses HTTP 5xx. L’inspection de l’infrastructure détecte des redémarrages de conteneurs, les journaux montrent des refus de connexion à PostgreSQL et l’analyse du dépôt révèle qu’une nouvelle connexion est créée pour chaque requête. Si une campagne marketing a débuté peu avant l’incident, le système relie l’augmentation de la charge à l’épuisement du pool de connexions. L’ingénieur d’astreinte reçoit non pas une avalanche de messages, mais une hypothèse vérifiable et plusieurs pistes de correction : réutiliser les connexions, ajouter RDS Proxy ou ajuster la mise à l’échelle.

Ce qui a changé avec l’augmentation de la charge

Lorsque le volume des journaux et du contexte a augmenté, les différents nœuds de Bedrock Flows ont commencé à manquer de temps. L’équipe a d’abord renforcé le filtrage et réduit le contexte transmis, puis déplacé la logique vers Amazon Bedrock AgentCore Runtime. Les trois agents ont été réunis dans un seul processus avec état persistant, tandis que l’accès à OpenSearch, à la base de connaissances et à GitHub a été centralisé via AgentCore Gateway.

Trois décisions sont particulièrement importantes en pratique. Premièrement, l’agent peut affiner ses requêtes au fil de l’enquête sans perdre le contexte déjà découvert. Deuxièmement, les traces OpenTelemetry indiquent la durée des étapes et les goulets d’étranglement. Troisièmement, les outils bénéficient d’un accès limité aux données et administré de manière centralisée.

Ce qui peut être reproduit sans dépendre d’AWS

L’idée principale ne réside ni dans le choix du modèle ni dans une autonomie complète. Il faut commencer par automatiser la collecte répétitive des faits, tout en laissant à l’ingénieur la décision et la correction. Séparez les sources entre infrastructure, journaux applicatifs, documentation et code ; accordez à chaque outil les droits minimaux ; exigez que le rapport final renvoie aux données observables.

Circle K souligne également qu’il est plus utile de filtrer les journaux en amont et de transmettre au modèle les lignes pertinentes que de lui demander de parcourir seul d’immenses volumes. Mais ce filtrage peut masquer un signal important, tandis que le modèle peut établir de manière convaincante un lien entre des événements sans rapport. Le résultat de l’agent doit donc rester une hypothèse, avec des horodatages, des sources et la possibilité de vérifier rapidement chaque conclusion. La meilleure première étape de déploiement consiste à utiliser un mode fantôme sur l’historique des incidents, à mesurer le temps, la précision des causes et la proportion de recommandations erronées, puis seulement à connecter le système au canal opérationnel des ingénieurs d’astreinte.