Comment Databricks utilise l'IA pour accélérer l'analyse des incidents

Dans notre précédent article de blog, nous avons partagé comment Databricks utilise l'AI pour déboguer des milliers de bases de données. Ici, nous poursuivons cette histoire en explorant comment nos ingénieurs utilisent l'AI pour gérer des centaines de microservices sur plus de 1500 clusters Kubernetes, répartis sur plus de 70 régions et trois clouds.

Quand quelque chose tombe en panne à 2 heures du matin, l'ingénieur d'astreinte doit rapidement répondre à une question : qu'est-ce qui a changé ?

AI SRE est un agent de débogage optimisé par l'AI qui commence à enquêter dès qu'un incident se déclenche. Il corrèle les signaux de l'ensemble de notre stack et guide les ingénieurs dans l'analyse des causes racines.

Dans cet article, nous décrivons le parcours de débogage qui a façonné AI SRE, l'architecture qui le sous-tend et les principes d'ingénierie que nous avons suivis pour rendre un système basé sur les LLM fiable lors des incidents.

Avant AI SRE : l'expérience de 2 heures du matin

Imaginez une alerte d'astreinte typique. Un pic de latence touche une API orientée client. L'ingénieur se réveille et commence la routine habituelle :

• Inspecter les métriques de service sur les tableaux de bord et les régions.
• Rechercher dans les logs les erreurs à la fois pertinentes et inhabituelles.
• Passer en revue les déploiements, les modifications de dépendances et les mises à jour des feature flags.
• Vérifier l'état de santé du cloud, du réseau et de la plateforme partagée.
• Trouver et dérouler le runbook approprié.

Chacun de ces flux de travail fonctionne bien de manière isolée, mais le flux de débogage, c'est-à-dire le fait de relier les signaux entre eux, se fait entièrement dans l'esprit de l'ingénieur. Les ingénieurs expérimentés pouvaient le faire en quelques minutes car ils avaient déjà vu ce schéma. Les ingénieurs plus récents pouvaient y passer des heures ou faire remonter le problème à quelqu'un d'autre.

Les outils n'étaient pas le problème principal. La responsabilité de relier leurs signaux incombait à l'ingénieur d'astreinte, soumis à un SLA.

Commencer par le client, pas par la technologie

Nous n'avons pas commencé par créer un agent. Nous avons commencé par observer les gens déboguer.

Pendant plusieurs semaines, nous avons interrogé des ingénieurs d'astreinte de dizaines d'équipes pour cartographier leurs parcours de débogage de bout en bout. Nous avons lu des post-mortems et des documents d'investigation. Nous avons posé une question simple : où passez-vous votre temps et où bloquez-vous ?

Trois schémas sont apparus de manière constante :

• L'assemblage du contexte prenait la majeure partie du temps. Le moment de révélation, c'est-à-dire l'identification de la cause racine, était souvent rapide une fois que l'ingénieur avait les bons signaux sous les yeux. Mais rassembler ces signaux (la bonne métrique, la bonne fenêtre temporelle, le déploiement concerné, la dépendance en amont qui a changé) consommait 60 à 80 % du temps d'investigation.
• Les connaissances étaient inégalement réparties. Chaque équipe comptait quelques experts qui savaient tout simplement comment leur système tombait en panne. Lorsque ces experts n'étaient pas disponibles, les investigations ralentissaient considérablement. Les runbooks existaient mais étaient souvent obsolètes ou incomplets, et ils ne pouvaient pas répondre à de nouveaux modes de défaillance.
• L'état de santé de la plateforme était invisible jusqu'à ce qu'il ne le soit plus. De nombreux incidents provenaient d'un problème d'infrastructure à grande échelle, comme une panne de fournisseur cloud ou de réseau, ou d'une défaillance critique du système comme Auth. Mais les ingénieurs qui déboguaient au niveau de la couche applicative n'avaient pas de moyen simple de vérifier ces signaux, ils passaient donc du temps à explorer des hypothèses au niveau applicatif avant de découvrir que le problème se situait au niveau des couches d'infrastructure inférieures.

Une fois que nous avons reconnu le débogage comme une séquence d'étapes d'investigation reproductibles suivies d'un jugement d'expert, il est devenu clair que les agents AI pouvaient accélérer le travail. Mais aucune équipe ne pouvait à elle seule concevoir un agent capable de comprendre chaque service, signal et mode de défaillance. Nous avions besoin d'une plateforme partagée gérant les briques de base communes comme la collecte de contexte, l'exécution d'outils et de runbooks, et la corrélation des preuves, tout en permettant aux équipes de l'enrichir avec leurs propres connaissances opérationnelles. La question est passée de Pouvons-nous automatiser le débogage ? à Comment donner à chaque équipe une plateforme optimisée par l'AI pour un diagnostic et une résolution plus rapides et éclairés ?

Présentation d'AI SRE

AI SRE prend en charge deux expériences complémentaires : le triage automatique, qui commence lorsqu'un incident se déclenche, et l'investigation interactive, qui permet aux ingénieurs d'astreinte d'explorer des hypothèses et de demander des preuves supplémentaires.

Triage automatique lors du déclenchement d'un incident

Lorsqu'un incident se déclenche, AI SRE démarre immédiatement, avant même que l'ingénieur n'ait ouvert son ordinateur portable. Il lance trois pistes d'investigation en parallèle, rassemblant des preuves complémentaires pour produire une évaluation initiale :

Les vérifications de l'état de santé de la plateforme évaluent l'environnement dans lequel le service s'exécute.

• L'infrastructure cloud sous-jacente est-elle saine ?
• Y a-t-il des problèmes de réseau en cours dans la région concernée ?
• Les dépendances en amont (bases de données, files d'attente de messages, services partagés) subissent-elles des dégradations ?

Cela permet à lui seul d'éliminer une grande catégorie de fausses pistes, évitant ainsi à un ingénieur de passer 30 minutes à déboguer son code applicatif pour finalement découvrir que la cause racine était un problème d'infrastructure à grande échelle.

L'analyse au niveau du service extrait les logs, métriques et traces pertinents pour le service concerné et ses dépendances directes. Elle examine les déploiements récents et les modifications de configuration. Elle identifie les anomalies par rapport au comportement de référence du service, pas seulement « le CPU est élevé », mais « le CPU a triplé à 2 h 47, coïncidant avec un déploiement qui a modifié la taille des lots dans le pipeline de traitement ».

L'exécution du runbook est l'étape où AI SRE adopte un profil spécifique à l'équipe. Les équipes encodent leurs procédures de débogage, comme les vérifications qu'un expert du domaine effectuerait, les seuils qu'il rechercherait, les mesures d'atténuation qu'il prendrait. Les équipes peuvent convertir leurs runbooks existants en runbooks agentiques à l'aide de compétences. Ces compétences s'appuient sur la base de code, les données d'observabilité et l'historique des incidents passés pour rendre les runbooks plus précis et plus conscients du contexte. Il exécute ensuite ces étapes pour le compte de l'ingénieur d'astreinte, réalisant la même investigation qu'un expert du domaine, mais en quelques secondes plutôt qu'en minutes.

Au moment où l'ingénieur prend connaissance des détails de l'incident pour la première fois, AI SRE a déjà assemblé un résumé de diagnostic complet : voici ce qui est en panne, voici ce qui a changé et voici ce que le runbook de votre équipe conseille de vérifier, le tout regroupant les signaux, la corrélation et les étapes suivantes dans une vue unique.

Débogage interactif pour une investigation plus approfondie

Toutes les investigations ne se terminent pas par un auto-triage. Parfois, la cause racine est subtile, ou l'ingénieur souhaite explorer une hypothèse. L'UI d'AI SRE fournit un environnement de débogage interactif où les ingénieurs peuvent poser des questions de suivi en langage naturel, demander des signaux supplémentaires et zoomer sur des fenêtres temporelles ou des composants spécifiques.

C'est là que la combinaison de vérifications de santé structurées et d'AI conversationnelle devient puissante. Un ingénieur pourrait demander : « Y avait-il quelque chose d'inhabituel concernant le retard du consommateur Kafka (Kafka consumer lag) dans les 10 minutes précédant cette alerte ? » AI SRE récupère les métriques pertinentes, les superpose à la chronologie de l'incident et explique ce qu'il trouve.

Une architecture en couches pour le débogage

Notre principale conclusion tirée des entretiens avec les clients est que le débogage n'est pas un problème unique, mais une pile de problèmes, et que les résoudre nécessite des abstractions délibérées. Nous avons conçu AI SRE comme une plateforme en couches, où chaque couche a une responsabilité claire et où les couches supérieures peuvent se concentrer sur des préoccupations de niveau de plus en plus élevé.

Les primitives constituent le fondement : les données opérationnelles brutes dont dépend en fin de compte chaque investigation. Les primitives pour les métriques, les alertes, les logs, les informations de version et le code existent déjà, mais y accéder lors d'un incident signifiait jongler entre cinq outils différents avec cinq langages de requête différents. La couche des primitives ne remplace pas ces systèmes ; elle les reconnaît comme la source de vérité.

La couche API utilise des primitives et fournit un accès contrôlé et uniforme aux données sous-jacentes. Plutôt que d'avoir chaque outil de débogage interrogeant directement les sources de données comme les logs ou le stockage de métriques, nous avons créé des API spécifiques : une API d'observabilité, une API de déploiement et une API d'alertes qui gèrent l'authentification, la limitation du débit et la normalisation des données. C'est la couche qui transforme « l'infrastructure brute » en « infrastructure déboguable ». Cela signifie également que lorsque nous remplaçons un système sous-jacent, les outils de débogage situés au-dessus ne cessent pas de fonctionner.

Le Moteur central est l'endroit où réside l'intelligence. Un framework de bot fournit la couche d'orchestration pour créer des flux de travail de débogage, et le moteur gère les mécanismes d'exécution parallèle, de corrélation des résultats et de synthèse alimentée par LLM. C'est la plateforme sur laquelle fonctionnent nos bots internes, mais surtout, c'est aussi la même plateforme mise à la disposition de chaque équipe qui souhaite créer la sienne.

La Couche applicative est l'endroit où le débogage a réellement lieu. C'est là que fonctionne notre bot de triage des incidents au niveau de la plateforme. C'est également là que les outils d'IA tiers peuvent s'intégrer, offrant des fonctionnalités complémentaires sans que nous ayons à tout reconstruire à partir de zéro.

Cette séparation nous permet d'améliorer l'accès aux données et l'orchestration de manière indépendante, tout en prenant en charge à la fois les flux de travail gérés de manière centralisée et les runbooks propres aux équipes.

Bâtir pour la fiabilité dans un monde non déterministe

Rendre un agent alimenté par LLM suffisamment fiable pour la réponse aux incidents, où la confiance est primordiale, a nécessité une ingénierie rigoureuse. Quelques principes nous ont guidés :

Des vérifications structurées avant un raisonnement ouvert. AI SRE exécute d'abord des vérifications déterministes de l'état de la plateforme et des étapes de runbook. La couche LLM synthétise et explique les résultats, mais la collecte de données n'est pas laissée à l'appréciation du modèle.

La transparence plutôt que des réponses de type boîte noire. Chaque conclusion présentée par AI SRE renvoie aux preuves sous-jacentes : la métrique spécifique, la ligne de log, le diff de déploiement. Les ingénieurs peuvent vérifier le raisonnement, et pas seulement lui faire confiance. C'était non négociable, car les ingénieurs d'astreinte n'agiront pas sur une recommandation qu'ils ne peuvent pas auditer.

Dégradation progressive. Si AI SRE ne peut pas déterminer une cause profonde avec certitude, il le dit explicitement et présente les preuves qu'il a recueillies, organisées par pertinence. Une enquête partielle qui est honnête quant à ses limites est bien plus utile qu'un diagnostic hallucinatoire.

Impact

AI SRE prend désormais en charge plus de 150 équipes au sein de Databricks, avec plus de 250 utilisateurs actifs hebdomadaires qui mènent plus de 2 000 enquêtes chaque jour, économisant ainsi plusieurs heures de débogage. Nous avons reçu des retours positifs depuis le lancement :

« L'équipe de la plateforme de stockage s'appuie fortement sur AI SRE pour le triage. Il devance mes enquêtes : avant même que j'ouvre une alerte, l'agent a déjà corrélé les signaux et produit une première analyse de la cause profonde. Félicitations à l'équipe pour avoir créé une plateforme de débogage véritablement générique qui permet à plusieurs équipes d'intégrer des workflows d'agents dans leur quotidien. »—Gaurav Garg, Ingénieur principal

« Avant AI SRE, la première étape d'un incident consistait à rassembler le contexte : tableaux de bord, fenêtres temporelles, filtres sur l'ensemble du parc. Désormais, le contexte pertinent arrive au même endroit, déjà ciblé sur l'alerte ou l'incident. Je n'ai pas besoin de croire l'agent sur parole. Les preuves sont intégrées à l'enquête, et un simple clic ouvre l'outil sous-jacent, pré-filtré, afin que je puisse le vérifier par moi-même. »—Himanshu Mishra, Ingénieur senior

« AI SRE a transformé la réponse aux incidents en unifiant les métriques, les logs et l'état des dépendances, en accélérant le triage des incidents et en faisant émerger les causes profondes plus tôt, réduisant ainsi le MTTR à l'échelle de l'entreprise. »—Adama Kone, Responsable - Équipe NOC

Le résultat le plus important n'a pas été de remplacer le jugement des ingénieurs. Il a été de leur fournir un point de départ plus rapide et étayé par des preuves pour leur enquête.

Ce que nous avons appris

Trois enseignements tirés de la création d'AI SRE :

Laisser les équipes s'approprier leur expertise. Un agent centralisé qui tente d'intégrer les connaissances du domaine de chaque équipe sera toujours obsolète et fragile. En faisant des runbooks d'agents une primitive composable que les équipes possèdent et maintiennent, nous avons transformé AI SRE en une plateforme qui devient plus intelligente à mesure qu'elle grandit, sans que la plateforme ne devienne le goulot d'étranglement.

Construire la couche de contexte avant d'optimiser le modèle. Nous avons passé plus de temps à cartographier la façon dont les ingénieurs enquêtent réellement sur les incidents qu'à faire de l'ingénierie de prompt. Cet investissement initial dans la compréhension du problème nous a permis de construire la bonne solution, à savoir un agent qui rassemble le contexte et exécute des vérifications connues, plutôt que la solution évidente, qui aurait été un chatbot greffé sur notre système d'observabilité.

Gagner la confiance grâce à des preuves traçables. Les ingénieurs d'astreinte travaillent sous pression et ne peuvent pas se permettre de suivre de fausses pistes. Chaque recommandation formulée par AI SRE est étayée par des preuves traçables. Cette transparence est ce qui a transformé des utilisateurs précoces sceptiques en utilisateurs quotidiens.

Les garde-fous importent plus pour les agents que pour les humains. Donner aux agents l'accès aux données d'observabilité impliquait de repenser notre couche API, et pas seulement de l'ouvrir. Les agents effectuent des requêtes différemment des humains. Ils interrogent les points de terminaison par rafales, exécutent des vérifications en parallèle, et ne se fatiguent pas ni ne ralentissent d'eux-mêmes. Nous avons dû intégrer des garde-fous pour que les agents puissent travailler rapidement sans mettre à mal l'infrastructure qui alimente également les systèmes d'alerte et de surveillance critiques pour l'entreprise.

Et ensuite ?

Aujourd'hui, AI SRE se concentre sur la phase d'enquête de la réponse aux incidents : comprendre ce qui s'est passé et pourquoi. La suite logique consiste à s'étendre à la résolution guidée : non seulement diagnostiquer le problème, mais aussi aider les ingénieurs à prendre la bonne mesure corrective en toute sécurité.

Nous investissons également dans l'apprentissage croisé entre incidents : utiliser des modèles d'incidents passés pour améliorer les diagnostics futurs, faire émerger les problèmes récurrents avant qu'ils ne déclenchent des alertes, et aider les équipes à identifier les failles de fiabilité systémiques.

Rejoignez-nous

En regardant vers l'avenir, nous sommes ravis de continuer à repousser les limites de la manière dont l'IA peut façonner les systèmes de production et rendre les infrastructures complexes simples d'utilisation. Si vous êtes passionné par la création de la prochaine génération de plateformes internes alimentées par l'IA, rejoignez-nous !

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original