Atlassian estime que l’analyse des causes profondes des incidents dans les environnements de microservices ne peut plus reposer uniquement sur un examen manuel. Lorsque des centaines de services interconnectés fonctionnent dans plusieurs régions, une seule panne produit une grande quantité de métriques, de journaux et de traces, tandis que l’ingénieur d’astreinte doit généralement naviguer entre des tableaux de bord séparés et élaborer mentalement une hypothèse sur l’origine du problème et son mode de propagation.
Dans un article publié sur le blog de la CNCF, Santosh Balaranganathan, Michael Yoo, James Moessis, James Kieltyka, Jason Lee et Lavender Neesham, d’Atlassian, expliquent un système automatisé d’analyse des causes profondes visant à automatiser la génération d’hypothèses, afin que l’équipe d’intervention passe plus rapidement à l’étape de vérification et de remédiation au lieu de reconstituer manuellement les éléments de preuve.
Transformer l’analyse des causes profondes en un problème de corrélation multi-signaux
La conception repose sur la mise en relation de trois couches de preuves : le type de signal, le temps et la topologie des services. Les signaux comprennent les métriques, les journaux et les traces, tandis que la simultanéité temporelle détermine les événements susceptibles d’être liés, et que le graphe des dépendances des services aide à distinguer le service à l’origine de la défaillance de celui qui en a été affecté ultérieurement.
Le processus commence par la réduction du périmètre de recherche au moyen d’une carte des services dérivée d’OpenTelemetry. Au lieu d’analyser tous les services de la plateforme, le système identifie ceux qui se trouvent sur le parcours de l’expérience utilisateur dégradée, constituant généralement un périmètre de quelques dizaines de services plutôt que de quelques centaines. La carte reflète les communications réelles extraites des relations parent-enfant entre les spans du trafic de production, et non la structure supposée dans la documentation.
Des données de surveillance aux hypothèses classées
Une fois le périmètre défini, des modules indépendants détectent les anomalies dans chaque type de signal. Pour les métriques, Atlassian surveille les indicateurs RED, à savoir le taux de requêtes, le taux d’erreurs et la durée des réponses, à l’aide de méthodes statistiques telles que la déviation absolue médiane et les plages de percentiles. Chaque anomalie produit une valeur d’intensité, la valeur observée et la ligne de base dont elle s’est écartée.
Les traces distribuées sont examinées à la recherche d’exceptions inattendues, de nouveaux modes de propagation des erreurs et d’augmentations de la latence sur des spans précis. Les journaux utilisent des techniques de regroupement fondées sur les embeddings pour rassembler les entrées sémantiquement similaires, puis mettre en évidence les groupes d’erreurs nouveaux ou rares par rapport à la distribution habituelle du service.
Tous les détecteurs convertissent leurs résultats en événements dotés d’un schéma unifié comprenant l’horodatage, le nom du service, le type de signal, le niveau de gravité et les détails. Cette couche permet au moteur de corrélation d’analyser les événements sans dépendre de la manière dont chaque détecteur a identifié la situation. Elle permet également d’ajouter de nouveaux détecteurs ou de remplacer un modèle statistique par un autre fondé sur l’apprentissage automatique sans reconstruire l’ensemble du système.
Le temps et le graphe des dépendances pour déterminer la direction de la défaillance
Le moteur regroupe les événements proches dans une fenêtre temporelle configurable, généralement de plus ou moins cinq minutes. Chaque groupe reçoit un score de cohérence temporelle : plus les événements sont rapprochés, plus la probabilité qu’ils soient liés est élevée. Pour éviter de répéter la même hypothèse des dizaines de fois, le système utilise des empreintes de séquences de services et fusionne les chaînes de défaillance répétées en un seul groupe, avec un décompte des redémarrages. Ainsi, un mode de défaillance qui s’est répété 47 fois en cinq minutes peut être décrit au lieu de créer 47 hypothèses identiques.
Le système identifie ensuite le nœud le plus affecté, ou ce qu’il appelle le nœud en aval, puis remonte le graphe des dépendances à la recherche de services anormaux qui l’ont précédé dans le temps. Si le service B est appelé par le service A et qu’un problème est apparu dans B avant celui d’A, B devient un candidat plus probable comme source de la défaillance, tandis que le problème d’A est considéré comme un effet ultérieur. L’évaluation finale combine la cohérence temporelle et le score du chemin de propagation pour classer les hypothèses.
Le résultat ne se limite pas à une liste de services et à des niveaux de confiance. Chaque hypothèse comprend le service suspecté, le chemin de propagation et les preuves présentes à chaque nœud, telles que les métriques ayant dépassé leurs seuils ou les identifiants des traces associés à la défaillance, ainsi qu’un récit en langage humain expliquant la séquence des événements et la raison pour laquelle une source donnée est privilégiée.
Pourquoi cette méthode est-elle importante pour les équipes d’exploitation ?
La valeur pratique ne réside pas dans le remplacement de l’ingénieur d’intervention, mais dans la réduction du temps nécessaire pour parvenir à une hypothèse vérifiable. Atlassian relie son moteur d’analyse des causes profondes à une plateforme plus large de réponse aux incidents, qui comprend la détection de l’impact de la panne sur les utilisateurs, l’identification de l’équipe responsable et un assistant d’incident capable de proposer des actions telles que le retour à une version précédente ou la désactivation d’un feature flag sur la base des éléments disponibles. La plateforme enregistre également si les ingénieurs ont accepté, rejeté ou modifié l’hypothèse afin d’améliorer les pondérations au fil du temps.
L’expérience montre que commencer par des méthodes simples et interprétables peut être plus approprié que de construire des modèles complexes d’apprentissage automatique pour chaque signal. Des méthodes telles que la déviation absolue médiane et les plages de percentiles ont suffi à détecter de nombreuses anomalies métriques, tandis que des méthodes d’apprentissage automatique ont été utilisées pour regrouper les journaux et analyser la structure des traces, là où les méthodes statistiques sont moins adaptées.
La méthode n’élimine toutefois pas les limites. La qualité des hypothèses dépend de la cohérence des données de surveillance, de la précision du graphe des dépendances des services et de la capacité des détecteurs à distinguer une défaillance réelle du bruit. En outre, le niveau de confiance ne constitue pas une preuve définitive de causalité ; Atlassian souligne donc l’importance d’afficher la source de chaque élément de preuve et le récit qui le relie au résultat. L’entreprise étudie ensuite l’utilisation d’un format fondé sur des modèles de langage, capable de demander des données supplémentaires et d’ajuster les hypothèses, tout en imposant des limites de débit, une exécution isolée et un registre clair de la provenance des preuves.
Lecture éditoriale de certi.news : le changement concret apporté par cette approche consiste à faire passer l’analyse des incidents d’une comparaison manuelle entre des outils distincts à un processus unifié qui intègre le signal, le temps et la topologie. Sa réussite opérationnelle dépendra de l’interprétabilité, de la qualité des données et des boucles de rétroaction, et non du seul algorithme de classement. C’est pourquoi la modularité, l’élimination des doublons et la documentation des preuves semblent être des principes applicables immédiatement, davantage que la promesse d’une automatisation complète de l’analyse des causes profondes.