Résumé exécutif

logIQ est la capacité d’enquête et de remédiation agentique de HCLTech, construite sur AWS. Au lieu de donner aux ingénieurs un autre tableau de bord à surveiller, il leur offre un premier intervenant toujours en service. Dès qu’une alerte se déclenche, logIQ commence automatiquement à enquêter, et pour les types de défaillances qu’il reconnaît déjà, il résout le problème avant même qu’un ingénieur ne soit appelé.

La conception repose sur une séparation stricte : l’agent qui enquête n’est jamais l’agent qui agit. Un second agent s’occupe de la remédiation et chaque changement effectué, qu’il s’agisse d’une automatisation en direct ou d’une demande d’extraction sur l’infrastructure en tant que code, se fait dans les contrôles de déploiement déjà en place dans l’entreprise. L’objectif est simple : éliminer les 30 à 90 minutes que chaque incident perd actuellement à la classification manuelle avant que la remédiation ne puisse commencer.

Introduction

La plupart des processus d’intervention en cas d’incident se ressemblent d’une organisation à l’autre. Une alerte se déclenche, un ingénieur est appelé et avant que toute correction ne soit possible, l’ingénieur passe le début de l’incident à établir ce qui s’est passé : extraire les journaux, vérifier les déploiements récents et cartographier les ressources touchées. Ce travail fastidieux est le prix à payer pour arriver à la solution, et il doit être payé dans chaque incident, peu importe l’heure de la journée.

logIQ est conçu pour fermer cet écart : une suite agentique cloud-native qui considère l’enquête et la remédiation comme deux tâches distinctes et automatisables, plutôt que comme un même travail indifférencié laissé à un seul ingénieur. Il fournit un modèle fonctionnel pour passer d’une alerte à une résolution documentée sans dépendre de la disponibilité d’une personne pour débuter le processus.

Le besoin

Considérez ce qui se produit lorsqu’une alerte se déclenche aujourd’hui. Un ingénieur est appelé et la résolution est retardée dès le départ, car les journaux sont dans un outil, l’historique des déploiements dans un autre et la topologie des ressources dans un troisième, sans aucun lien automatique entre eux. Ce qui devrait être un diagnostic rapide devient une enquête manuelle répétée de façon identique lors de chaque incident, peu importe à quel point la cause sous-jacente est routinière.

logIQ comble l’écart entre le déclenchement d’une alerte et l’action qui s’ensuit. Plutôt que de s’arrêter à la notification, il enquête de façon automatisée, applique un correctif connu lorsqu’il existe et remet un résumé structuré à un ingénieur seulement lorsque l’incident requiert réellement un jugement humain. Cela assure l’uniformité, l’auditabilité de l’intervention et fonctionne dans les processus de gestion des changements déjà utilisés par les entreprises : Git et l’infrastructure en tant que code, et non à côté d’eux.

Architecture de la solution

• La plateforme fonctionne comme un pipeline en trois étapes : détection, enquête et remédiation. Tout outil de surveillance peut le déclencher ; un agent effectue le travail de diagnostic qu’un ingénieur ferait autrement manuellement et un second agent agit sur le résultat sans sortir du cadre du contrôle des changements existant
• Prise en charge universelle des alertes : logIQ accepte les webhooks de toute plateforme de surveillance, y compris Datadog, Splunk, PagerDuty, New Relic, Grafana et ServiceNow. Les sources indirectes passent d'abord par Amazon SNS et une fonction Lambda signée, mais le point d’entrée fonctionne de la même façon, peu importe l’outil ayant généré l’alerte : un événement authentifié déclenche la chaîne
• Enquêtes corrélées : Une fois déclenché, l’agent DevOps AWS interroge CloudWatch, CloudTrail et OpenSearch, puis vérifie les résultats par rapport à l’historique des validations récentes dans GitHub et GitLab. La plupart des pannes en production sont causées par quelque chose qui a changé, donc cette étape de corrélation est généralement la voie la plus rapide vers la cause première, terminée en quelques minutes plutôt que dans les 45 à 90 minutes qu’une intervention manuelle demande habituellement
• Remédiation selon trois approches encadrées : Une fois l’enquête produisant un résultat structuré, l’agent de remédiation logIQ sélectionne exactement un chemin : un runbook d’automatisation SSM pré-rédigé pour les pannes connues, une demande de fusion dans le dépôt d’infrastructure en tant que code pour les modifications à rendre permanentes, ou un transfert complet à l’ingénieur de garde pour toute situation inédite. Aucun chemin ne permet l’application directe d’un changement non révisé dans un environnement de production

La couche de raisonnement agentique

La conception repose sur une séparation ferme entre l’agent qui enquête et l’agent qui agit, coordonnés par Amazon EventBridge.

• Enquête : gérée par l’agent DevOps. Cet agent a une responsabilité unique : établir une constatation structurée en interrogeant les journaux, les métriques et la topologie active, puis en corrélant l’apparition des symptômes avec l’historique des déploiements. Il recommande des actions, mais ne les exécute pas. Cette séparation permet à cet agent de s’exécuter automatiquement sur chaque alerte, sans risquer d’agir sur une vision incomplète de l’incident
• Correction : gérée par l’agent logIQ Remediation. Ce second agent reçoit la constatation via EventBridge et Lambda et sa marge de décision est volontairement restreinte : défaillance connue, changement persistant ou incident nouveau. Chaque résultat correspond à une action prédéfinie, ce qui permet à la correction de demeurer déterministe plutôt qu’improvisée
• Le contrôle des changements n’est jamais contourné, car les défaillances connues passent par l’automatisation SSM derrière une porte d’approbation. Les changements persistants se font par une demande de tirage (pull request) dans le dépôt IaC, tel que CloudFormation, plutôt que par une modification directe et en direct. Dans les deux cas, le processus de révision existant de l’entreprise demeure la source de vérité sur ce qui a changé et pourquoi. logIQ ne remplace pas ce processus. Il lui fournit l’information nécessaire pour agir plus rapidement

Mise en œuvre technique

• Une alerte est déclenchée par n'importe quel outil de surveillance, y compris Splunk, Datadog, New Relic, Grafana ou PagerDuty
• L'alerte est livrée comme un HTTP POST à un point de terminaison webhook. Les sources indirectes passent d'abord par Amazon SNS et une fonction Lambda de signature, de sorte que chaque événement atteignant le point de terminaison est authentifié
• Le webhook transfère à l'Agent DevOps, qui interroge Amazon CloudWatch, AWS CloudTrail et Amazon OpenSearch, ainsi que les outils d'observabilité externes connectés comme Splunk et corrèle ensuite les symptômes avec l'historique des commits dans Git
• L'Agent DevOps construit une topologie en temps réel des ressources affectées et produit un constat structuré avec un plan de remédiation recommandé
• Le constat passe par Amazon EventBridge et via Lambda à l'agent de remédiation logIQ
• Pour une défaillance connue, l'agent de remédiation déclenche un carnet d'exécution SSM Automation, qui s'exécute derrière une porte d'approbation
• Pour un changement d'infrastructure persistant, l'agent de remédiation ouvre une demande de tirage sur le dépôt IaC, tel que CloudFormation, gardant le changement à l'intérieur des contrôles de déploiement existants
• Pour un incident nouveau, l'agent de remédiation envoie les constats complets et le plan recommandé à l'ingénieur de garde via Amazon SNS. Chaque incident, y compris ceux qui nécessitent une intervention humaine, commence par le contexte plutôt que par une enquête vierge

Architecture technique et services AWS

Services AWS utilisés dans la solution :

• Amazon SNS : Reçoit et transmet les alertes provenant de sources de surveillance indirectes dans le flux de détection
• AWS Lambda : Signe les événements webhook entrants et achemine les résultats structurés de l’enquête vers la correction
• Agent AWS DevOps : Effectue l’enquête automatisée, interroge les journaux, les métriques et la topologie, puis effectue une corrélation des constats avec l’historique des déploiements
• Amazon CloudWatch : Fournit les métriques et la télémétrie opérationnelle utilisées pendant l’enquête
• AWS CloudTrail : Fournit l’historique des activités et des audits API utilisé pour identifier les changements récents
• Amazon OpenSearch : Fournit la recherche et la corrélation des journaux à travers l’environnement concerné
• GitHub / GitLab (intégrations natives) : Fournissent l’historique des validations et des déploiements utilisé pour relier les symptômes à un changement spécifique
• Amazon EventBridge : Acheminent les résultats structurés de l’agent d’enquête vers l’agent de correction
• Agent de correction logIQ : Associe chaque constat à l’un des trois chemins de correction régis et exécute la décision
• Automatisation AWS Systems Manager (SSM) : Exécute des procédures pré-rédigées et validées pour des cas d’échec connus, derrière une étape d’approbation
• Dépôt d’Infrastructure as Code (CloudFormation) : Reçoit les demandes de tirage pour les modifications d’infrastructure persistantes, en les gardant dans les processus de révision existants

Valeur pour les utilisateurs :

• Cessez de payer la taxe de triage à chaque incident : les enquêtes commencent en quelques secondes après une alerte, en corrélant automatiquement les journaux, l’historique des déploiements et l’état actuel des ressources, remplaçant ainsi les 45 à 90 minutes de triage manuel typiques d’un incident de niveau P2
• Résolvez plus rapidement, avec moins de variabilité : les classes de défaillance connues passent par des guides d’intervention pré-rédigés et validés, éliminant la variabilité liée à l’ingénieur qui traite l’incident
• Contrôle des changements qui n’est jamais contourné : les changements persistants de l’infrastructure passent par une demande d’extraction plutôt que par une modification en direct, de sorte que chaque changement passe toujours par le processus de révision sur lequel l’organisation compte déjà
• Clara séparation entre l’enquête et l’action : l’enquête et la remédiation sont effectuées sous des rôles distincts, des étapes d’approbation sont intégrées au processus d’exécution et chaque action est consignée
• Couverture qui s’élargit avec le temps : lorsqu’un ingénieur résout un incident inédit, cette résolution devient un guide d’intervention potentiel, de sorte que l’ensemble des classes de défaillances que logIQ peut corriger automatiquement continue de croître

Appel à l'action : Aucun incident ne devrait jamais commencer à froid !

• Évaluer en quelques jours : Un examen rapide des sources d’alerte actuelles, de la charge de garde et des types de défaillances récurrentes produit une liste priorisée de candidats à une couverture automatisée
• Lancer un projet pilote rapidement : Une preuve de concept testée sur des scénarios de défaillance représentatifs de votre environnement valide la précision de l’investigation et la sécurité de la remédiation avant un déploiement plus large

« D’une alerte à l’action : détecter, enquêter, remédier. »

• Détecter : Accepter des alertes de n’importe quel outil de surveillance grâce à un seul point d’entrée webhook authentifié
• Enquêter : Corréler les journaux, la topologie et l’historique des déploiements dans une constatation structurée, automatiquement, à chaque alerte
• Rémédier : Acheminer chaque constatation vers une action encadrée, qu’il s’agisse d’un guide d’exploitation validé, d’une demande de tirage ou d’un transfert complet à un ingénieur, sans jamais contourner les contrôles existants avec une modification active non revue

Les entreprises et les partenaires AWS peuvent faire appel à HCLTech pour planifier une séance d'information ou une démonstration de logIQ et découvrir comment une capacité DevOps agentique peut contribuer à réduire le MTTR sans aucun compromis sur la gouvernance

Étiquettes : DevOps, gestion des incidents, AIOps, IA agentique, agent DevOps AWS, analyse des causes profondes, automatisation SSM, infrastructure en tant que code, réduction du MTTR, GitOps