🤖 AI

A Topology-Aware, Memory-Centric Architecture that Separates Root-Cause Derivation from Root-Cause Explanation

Cet article présente OPS CORTEX, une architecture sensible à la topologie et centrée sur la mémoire qui découple la dérivation déterministe de la cause racine de l'explication basée sur les LLM en maintenant une représentation persistante et structurée du comportement et des dépendances du système afin de relever les défis de la propagation des fautes dans les déploiements de microservices modernes.

Auteurs originaux : Momil Seedat

Publié 2026-06-23

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Momil Seedat

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes le capitaine d'un immense vaisseau spatial de haute technologie. Soudain, des alarmes commencent à hurler partout. Les lumières clignotent en rouge. Le vaisseau tremble.

Le Problème :
Dans les systèmes informatiques modernes (appelés « microservices »), lorsqu'un problème survient, il est facile de déclencher les alarmes mais difficile de les comprendre. C'est comme si 50 capteurs différents criaient « Feu ! » en même temps. Le vrai problème n'est pas que les capteurs ne fonctionnent pas ; c'est que l'humain aux commandes (l'ingénieur) est submergé. Il doit comprendre :

Quel capteur signale le vrai feu ?
Quels capteurs ne font que réagir à la fumée du premier incendie ?
Pourquoi cela arrive-t-il maintenant et pas hier ?

Habituellement, le système informatique oublie tout dès que l'alarme s'arrête. Il n'a aucun souvenir de ce à quoi ressemble un mardi à 3 heures du matin, ou de la façon dont ses composants sont connectés. Ainsi, l'ingénieur doit jouer au détective en partant de zéro à chaque fois, souvent alors que le système est en train de s'effondrer.

La Solution : OpsCortex (La « Mémoire Opérationnelle »)
Le document présente OpsCortex, une nouvelle façon de gérer ces systèmes. Au lieu d'essayer de rendre l'ordinateur plus « intelligent » avec un cerveau géant (comme une IA super avancée) pour deviner la réponse, les auteurs disent : « Donnez au système une mémoire. »

Considérez OpsCortex comme une mémoire à long terme super organisée pour le système informatique. Elle est construite comme une bibliothèque à quatre étages :

Le Bureau de Travail (Niveau 1) : C'est le « Maintenant ». Il contient la température actuelle, la vitesse et les alertes. C'est comme un post-it sur un bureau qui est jeté toutes les quelques heures.
La Carte en Direct (Niveau 2) : C'est un dessin de la façon dont tous les services informatiques communiquent entre eux. Si le Service A parle au Service B, cette carte le sait. Elle est mise à jour constamment.
L'Album Photo (Niveau 3) : Chaque minute, le système prend un « instantané » de toute la carte et l'enregistre. Cela permet de regarder en arrière et de voir : « Oh, la connexion s'est brisée il y a 5 minutes, et non il y a 1 seconde. »
L'Encyclopédie (Niveau 4) : C'est le cerveau permanent. Il se souvient : « À 3 heures du matin les mardis, le système ralentit habituellement un peu, et c'est normal. » Il se souvient aussi des catastrophes passées et de la façon dont elles ont été résolues.

Comment ça marche : Le « Détective et le Traducteur »
Le document soutient que trouver la cause d'un problème et l'expliquer sont deux tâches différentes. OpsCortex sépare ces deux fonctions :

Étape 1 : Le Détective (Logique Déterministe) :
D'abord, le système utilise des règles mathématiques simples (comme un détective suivant une piste de pas de géant). Il regarde la « Carte en Direct » et demande : « Quel service s'est cassé en premier ? » et « Quels services lui sont connectés ? »
- Analogie : Si un domino tombe et en renverse une ligne de 10 autres, les mathématiques ne devinent pas. Elles indiquent simplement le premier domino qui est tombé. C'est 100 % fiable et rapide.
Étape 2 : Le Traducteur (L'IA/LLM) :
Seulement après que le Détective a trouvé le coupable, le système fait appel à l'« IA Traductrice ».
- Analogie : L'IA n'est pas sollicitée pour deviner qui est le coupable. Au lieu de cela, le Détective remet à l'IA un dossier de preuves (la carte, la chronologie, le premier domino) et dit : « Voici ce qui s'est passé. Maintenant, rédige un rapport pour le capitaine humain en langage clair et dis-lui comment réparer cela. »
- Cela rend l'IA bien plus efficace dans sa tâche car elle ne devine pas ; elle explique simplement des faits.

Pourquoi est-ce meilleur (L'astuce du « Silence »)
Le système apprend également à ignorer le « bruit ».

Le Problème : Chaque nuit, un ordinateur peut exécuter une tâche lourde et lente qui ressemble à un plantage, mais qui est en réalité normale. Les anciens systèmes criaient « ALARME ! » chaque nuit.
La Correction par OpsCortex : Le système apprend : « Oh, cela arrive tous les soirs à 2 heures du matin. C'est normal. » Il se tait.
Le Filet de Sécurité : Mais si cette même tâche devient soudainement plus lente que d'habitude, ou si elle se produit à 14h au lieu de 2h du matin, le système se souvient : « Attendez, ce n'est pas le schéma habituel ! » et réveille l'alarme.

Preuve en Monde Réel
Les auteurs ont testé cela sur une fausse boutique en ligne. Ils ont provoqué 8 types de pannes différentes (comme un engorgement de file d'attente ou une surcharge de service).

Lorsqu'ils l'ont testé contre des catastrophes réelles (comme les pannes de Slack mentionnées dans le document), la conception a directement résolu les problèmes auxquels ces entreprises ont été confrontées :
- Slack 2021 : Leur propre tableau de bord s'est brisé car il dépendait du même réseau défectueux. OpsCortex n'a pas besoin du tableau de bord ; il possède sa propre mémoire permanente (Niveau 4) afin de pouvoir fonctionner même si les outils principaux échouent.
- Slack 2022 : Un petit changement a provoqué un crash massif pendant une période de fort trafic. OpsCortex se souvient de ce à quoi ressemble un « pic de trafic » habituel, de sorte qu'il repère la dérive vers le désastre avant même que l'alarme ne se déclenche.

L'Essentiel
Le document affirme que le plus grand problème pour réparer les systèmes informatiques n'est pas le manque de meilleurs capteurs ou d'une IA plus intelligente. C'est le manque de mémoire.

OpsCortex dit : « Construisons un système qui se souvient de ce qui est normal, qui se souvient de la façon dont les choses sont connectées et qui se souvient des erreurs passées. » En faisant cela, il peut trouver la cause profonde grâce à des mathématiques simples, puis utiliser l'IA uniquement pour l'expliquer clairement. Cela rend le système moins coûteux, plus calme et beaucoup plus rapide pour s'auto-réparer.

Résumé Technique : OpsCortex – Mémoire Opérationnelle pour Systèmes de Microservices Auto-Diagnostiques

Énoncé du Problème

Les architectures de microservices modernes font face à une asymétrie critique : la détection des défaillances est mature et automatisée, mais la localisation de la cause racine et l'explication restent manuelles, lentes et sujettes à la perte de contexte. Lorsque les fautes se propagent à travers les dépendances de services, elles déclenchent des « inondations d'alertes » qui submergent les ingénieurs. Les défis fondamentaux identifiés sont :

Fatigue liée aux alertes : Les systèmes basés sur des seuils sont dépourvus de mémoire ; ils ne peuvent pas distinguer les événements récurrents bénins (ex: tâches batch nocturnes) des véritables crises.
Perte de Contexte : Les données de diagnostic critiques — telles que le graphe d'appels en direct, les bases de référence selon l'heure de la journée et les changements de configuration récents — sont souvent transitoires ou éparpillées, forçant le diagnostic à devenir une « archéologie ».
Le Problème de la Cascade : Les signaux de défaillance sont topologiques et temporels (qui a cassé en premier et comment les dommages se sont propagés), pourtant les flux d'alertes plats rejettent cette structure, rendant difficile la distinction entre la cause racine et les victimes en aval.

L'article soutient que l'ingrédient manquant dans les opérations autonomes n'est pas de meilleurs détecteurs d'anomalies ou des modèles de langage (LLM) plus vastes, mais une mémoire opérationnelle : une représentation persistante et structurée du comportement du système, des dépendances et des défaillances historiques.

Méthodologie

OpsCortex est un prototype multi-agents qui organise la mémoire opérationnelle selon une architecture à quatre niveaux et sépare la dérivation de la cause racine de l'explication.

1. Architecture de Mémoire Opérationnelle à Quatre Niveaux

Le système stratifie la mémoire par durée de vie et par usage pour garantir que le système n'est jamais « aveugle » lors d'un redémarrage :

Niveau 1 (Mémoire de Travail Chaude - Redis) : Stocke les valeurs de métriques actuelles, les fenêtres glissantes et les flux d'alertes avec un TTL (Time-To-Live) court. Cela représente le « présent » du système.
Niveau 2 (Graphe de Dépendance en Direct - NetworkX) : Un graphe dirigé à trois niveaux en cours d'exécution (Service → Catégorie → Métrique) avec des arêtes CALLS. Le statut se propage vers le haut (la pire métrique détermine le statut de la catégorie, etc.) pour une traversée rapide.
Niveau 3 (Historique de Snapshots - Neo4j) : Sérialise le graphe complet toutes les 60 secondes. Cela permet au système d'analyser comment l'état a changé dans les minutes précédant un incident, distinguant une fuite lente d'un crash soudain.
Niveau 4 (Cerveau Permanent - SQLite) : L'état « appris ». Il stocke les bases de référence par service/métrique/heure/jour de la semaine, les arêtes d'appels confirmées avec des comptes de confiance, les registres de bruit structurel et l'historique complet des incidents. Lors d'un démarrage à froid, ce niveau reconstruit le graphe et les bases de référence avant l'arrivée de nouvelles télémétries, garantissant que le système conserve ses connaissances malgré les redémarrages.

2. Le Pipeline « Dériver, Puis Expliquer »

Le processus de diagnostic est délibérément divisé en deux étapes distinctes pour tirer parti des forces de la logique déterministe et de l'IA générative :

Étape 1 : Dérivation Déterministe :
- Calcul de la Cause Racine : Le système effectue une recherche en largeur (BFS) sur les arêtes CALLS confirmées pour identifier tous les services connectés à une faute.
- Ordonnancement Temporel : La cause racine est identifiée comme le service ayant franchi son seuil d'alerte le premier ( $arg \min t_{amber}$ ). Cela sépare la cause de ses victimes.
- Gestion du Bruit (Suppression puis Détection) : Le système apprend le bruit structurel (ex: tâches nocturnes inoffensives) et supprime les alertes correspondantes. Cependant, la suppression est annulée par des pics soudains (z-score de pic), une dérive graduelle (z-score de tendance) ou des anomalies corrélées dans les services pairs.
- Bases de Référence Temporelles : La détection utilise des bases de référence segmentées par (service, métrique, heure, jour de la semaine) pour tenir compte des variations cycliques normales.
Étape 2 : Explication Générative :
- Un LLM est invoqué uniquement après que la couche déterministe a identifié une cause racine et assemblé les preuves (chemin de faute, z-scores, scores Isolation Forest, progression du statut).
- La tâche du LLM est restreinte à expliquer, confirmer et recommander des corrections basées sur les preuves fournies, plutôt qu'à inférer la causalité à partir de la télémétrie brute.
- Reconnaissance de Formes (Pattern Matching) : Si un nouvel incident correspond à une signature connue de la mémoire permanente, le système reconstruit le diagnostic antérieur et contourne totalement le LLM, réduisant ainsi les coûts et la variance.

Contributions Clés

Architecture de Mémoire à Quatre Niveaux : Une conception qui sépare l'état présent, la topologie en direct, l'historique des changements et la connaissance permanente, évitant la perte de contexte lors des redémarrages.
Méthode de Cause Racine en Deux Étapes : Une approche déterministe (BFS + ordonnancement temporel) qui calcule la cause, avec le LLM strictement confiné au rôle d'explicateur utilisant des preuves pré-assemblées.
Cycle de Vie « Supprimer puis Détecter » Appris : Un mécanisme qui réduit le bruit structurel tout en annulant dynamiquement la suppression lorsqu'une dégradation réelle (pics ou dérives) survient.
Cartographie Explicite des Modes de Défaillance : Une correspondance architecturale directe où chaque choix de conception répond à des modes de défaillance spécifiques observés lors d'incidents de production documentés (pannes Slack 2021 et 2022).

Résultats et Validation

Le prototype a été validé sur un benchmark d'e-commerce instrumenté avec huit scénarios de défaillance injectables, incluant des surcharges de requêtes, des retards de file d'attente, des défaillances en cascade et l'épuisement des ressources.

Comportements d'Apprentissage : Le système a démontré avec succès sa capacité à apprendre et à supprimer les modèles récurrents bénins (tâches batch) tout en détectant et en levant immédiatement la suppression lorsqu'ils se dégradaient.
Contournement par Pattern : Le système a réussi à identifier des formes connues pour contourner le LLM, démontant des gains d'efficacité de coût à mesure que le système « apprend ».
Portée de la Validation : Les auteurs précisent explicitement qu'il s'agit d'une validation du mécanisme de bout en bout, et non d'une évaluation comparative de précision par rapport à des données de production ou d'autres outils comme MicroRCA.

Signification et Revendications

L'article pose que le goulot d'étranglement des opérations autonomes est la mémoire, et non la perception. Bien que les systèmes de détection soient abondants, les systèmes qui « comprennent » la normalité, les dépendances et l'historique ne le sont pas.

OpsCortex revendique une importance en tant qu'argument architectural concret pour :

Recadrer l'Objectif : Passer de l'inférence de causes racines à partir de zéro à chaque alerte vers le maintien d'un « modèle vivant » où la réponse est souvent déjà connue.
Division du Travail : Assigner les tâches déterministes (localisation, ordonnancement) à des systèmes basés sur des règles, et les tâches génératives (explication, recommandation) aux LLM, réduisant ainsi le risque de causes racines hallucinées.
Réduction des Coûts : Rendre le système « moins cher » au fil du temps en apprenant à supprimer le bruit et à contourner les appels LLM coûteux pour les formes connues.

Les auteurs restent modestes quant au statut actuel du prototype, reconnaissant des limites telles que l'utilisation du « premier franchissement » comme proxy de la causalité (qui peut échouer dans les systèmes à couplage par rétroaction) et l'absence d'évaluation sur des corpus d'incidents réels étiquetés. Les travaux futurs identifiés consistent à passer des heuristiques temporelles à l'inférence causale et à valider le système sur des données post-mortem réelles.