Wie Databricks AI nutzt, um die Untersuchung von Vorfällen zu beschleunigen

In unserem vorherigen Blogbeitrag haben wir berichtet, wie Databricks AI nutzt, um Tausende von Datenbanken zu debuggen. Hier setzen wir diese Geschichte fort und zeigen, wie unsere Engineers AI einsetzen, um Hunderte von Microservices auf über 1500 Kubernetes-Clustern in mehr als 70 Regionen und drei Clouds zu betreiben.

Wenn um 2 Uhr morgens etwas schiefgeht, muss der zuständige On-Call-Engineer schnell eine Frage beantworten: Was hat sich geändert?

AI SRE ist ein AI-gestützter Debugging-Agent, der mit der Untersuchung beginnt, sobald ein Vorfall ausgelöst wird. Er verknüpft Signale aus unserem gesamten Stack und führt Engineers durch die Ursachenanalyse.

In diesem Beitrag beschreiben wir den Debugging-Prozess, der AI SRE geprägt hat, die dahinterstehende Architektur und die Engineering-Prinzipien, denen wir gefolgt sind, um ein LLM-gestütztes System bei Vorfällen vertrauenswürdig zu machen.

Vor AI SRE: Das Erlebnis um 2 Uhr morgens

Stellen Sie sich einen typischen On-Call-Alarm vor. Ein Latenz-Spike trifft eine kundenorientierte API. Der Engineer wacht auf und beginnt mit den gewohnten Schritten:

• Service-Metriken über Dashboards und Regionen hinweg prüfen.
• Logs nach Fehlern durchsuchen, die sowohl relevant als auch ungewöhnlich sind.
• Deployments, Änderungen an Abhängigkeiten und Feature-Flag-Updates überprüfen.
• Status von Cloud, Netzwerk und gemeinsam genutzter Plattform prüfen.
• Das passende Runbook finden und durchgehen.

Jeder dieser Workflows funktioniert für sich genommen gut, aber der eigentliche Debugging-Workflow – also das Verknüpfen der verschiedenen Signale – findet ausschließlich im Kopf des Engineers statt. Erfahrene Engineers erledigen das in wenigen Minuten, weil sie das Muster bereits kennen. Weniger erfahrene Engineers verbringen unter Umständen Stunden damit oder müssen den Vorfall eskalieren.

Die Tools waren nicht das Hauptproblem. Die Last, die Signale miteinander zu verknüpfen, lag ganz beim On-Call-Engineer, der gegen ein SLA ankämpfen musste.

Beim Kunden anfangen, nicht bei der Technologie

Wir haben nicht damit begonnen, einen Agenten zu bauen. Wir haben zuerst Menschen beim Debuggen beobachtet.

Über mehrere Wochen hinweg haben wir On-Call-Engineers aus Dutzenden von Teams befragt, um deren Debugging-Prozesse lückenlos zu erfassen. Wir haben Postmortems und Untersuchungsberichte gelesen. Dabei stellten wir eine einfache Frage: Womit verbringen Sie Ihre Zeit und wo bleiben Sie stecken?

Drei Muster zeichneten sich immer wieder ab:

• Das Zusammentragen des Kontexts raubte die meiste Zeit. Der eigentliche „Aha“-Moment, also das Erkennen der Ursache, ging oft schnell, sobald der Engineer die richtigen Signale vor sich hatte. Aber das Sammeln dieser Signale (die richtige Metrik, das passende Zeitfenster, das relevante Deployment, die geänderte Upstream-Abhängigkeit) beanspruchte 60–80 % der Untersuchungszeit.
• Wissen war ungleich verteilt. Jedes Team hatte einige wenige Experten, die „einfach wussten“, wie ihr System fehlschlägt. Wenn diese Experten nicht verfügbar waren, verlangsamten sich die Untersuchungen drastisch. Runbooks waren zwar vorhanden, aber oft veraltet oder unvollständig, und sie konnten keine Antworten auf neuartige Fehlermuster liefern.
• Der Plattformstatus war unsichtbar – bis es zu spät war. Viele Vorfälle ließen sich auf ein größeres Infrastrukturproblem zurückführen, wie den Ausfall eines Cloud-Anbieters oder Netzwerks, oder auf den Ausfall eines kritischen Systems wie Auth. Engineers, die auf Anwendungsebene debuggten, hatten jedoch keine einfache Möglichkeit, diese Signale zu überprüfen. So verbrachten sie Zeit mit Hypothesen auf Anwendungsebene, bevor sie merkten, dass das Problem in tieferen Infrastrukturschichten lag.

Als wir erkannten, dass Debugging eine Abfolge wiederholbarer Untersuchungsschritte gefolgt von Expertenurteilen ist, wurde klar, dass AI-Agenten diese Arbeit beschleunigen können. Aber kein einzelnes Team konnte einen Agenten bauen, der jeden Service, jedes Signal und jedes Fehlermuster versteht. Wir brauchten eine gemeinsame Plattform, die die grundlegenden Bausteine wie das Sammeln von Kontext, das Ausführen von Tools und Runbooks sowie das Verknüpfen von Belegen übernimmt und es den Teams gleichzeitig ermöglicht, diese Plattform mit ihrem eigenen Betriebswissen zu erweitern. Die Frage verlagerte sich von „Können wir das Debugging automatisieren?“ zu „Wie geben wir jedem Team eine AI-gestützte Plattform für eine schnellere, fundierte Diagnose und Behebung an die Hand?“

Wir stellen vor: AI SRE

AI SRE unterstützt zwei sich ergänzende Ansätze: die automatische Triage, die beginnt, sobald ein Vorfall ausgelöst wird, und die interaktive Untersuchung, bei der On-Call-Engineers Hypothesen prüfen und zusätzliche Belege anfordern können.

Automatische Triage bei der Auslösung eines Vorfalls

Wenn ein Vorfall ausgelöst wird, legt AI SRE sofort los – noch bevor der Engineer überhaupt seinen Laptop geöffnet hat. Es startet drei Untersuchungspfade parallel und sammelt sich ergänzende Belege, um eine erste Einschätzung zu erstellen:

Plattform-Integritätsprüfungen bewerten die Umgebung, in der der Service ausgeführt wird.

• Ist die zugrunde liegende Cloud-Infrastruktur intakt?
• Gibt es aktuelle Netzwerkprobleme in der betroffenen Region?
• Gibt es Beeinträchtigungen bei Upstream-Abhängigkeiten (Datenbanken, Message Queues, gemeinsam genutzten Services)?

Dies allein schließt eine Vielzahl von falschen Fährten aus, sodass ein Engineer nicht mehr 30 Minuten mit dem Debuggen seines Anwendungscodes verbringt, nur um festzustellen, dass die Ursache ein großflächiges Infrastrukturproblem war.

Analyse auf Service-Ebene ruft die relevanten Logs, Metriken und Traces für den betroffenen Service und seine direkten Abhängigkeiten ab. Sie untersucht kürzliche Deployments und Konfigurationsänderungen. Sie identifiziert Anomalien im Vergleich zum normalen Verhalten des Services – nicht nur „CPU-Auslastung ist hoch“, sondern „CPU-Auslastung stieg um 2:47 Uhr um das Dreifache an, zeitgleich mit einem Deployment, das die Batch-Größe in der Verarbeitungspipeline geändert hat“.

Runbook-Ausführung ist hier der Bereich, in dem AI SRE eine teamspezifische Persona annimmt. Teams codieren ihre Debugging-Verfahren, wie die Prüfungen, die ein Domain-Experte durchführen würde, die Schwellenwerte, auf die er achten würde, und die Schritte zur Behebung. Teams können ihre bestehenden Runbooks mithilfe von Skills in agentenbasierte Runbooks umwandeln. Diese Skills greifen auf die Codebasis, Observability-Daten und die Historie vergangener Vorfälle zurück, um Runbooks präziser und kontextbezogener zu machen. Anschließend führt es diese Schritte im Namen des On-Call-Engineers aus und nimmt dieselbe Untersuchung vor, die ein Domain-Experte durchführen würde – allerdings in Sekunden statt in Minuten.

Wenn der Engineer zum ersten Mal die Details des Vorfalls liest, hat AI SRE bereits eine umfassende Diagnose-Zusammenfassung erstellt: was ausgefallen ist, was sich geändert hat und was laut dem Runbook Ihres Teams zu prüfen ist – alle Signale, Verknüpfungen und nächsten Schritte in einer einzigen Ansicht.

Interaktives Debugging für tiefgehendere Untersuchungen

Nicht jede Untersuchung endet mit der automatischen Triage. Manchmal ist die Ursache subtil oder der Engineer möchte eine Hypothese prüfen. Die UI von AI SRE bietet eine interaktive Debugging-Umgebung, in der Engineers Folgefragen in natürlicher Sprache stellen, zusätzliche Signale anfordern und bestimmte Zeitfenster oder Komponenten genauer analysieren können.

Hier zeigt sich die Stärke der Kombination aus strukturierten Integritätsprüfungen und dialogorientierter AI. Ein Engineer könnte fragen: „Gab es in den 10 Minuten vor diesem Alarm Auffälligkeiten beim Kafka-Consumer-Lag?“ AI SRE ruft die relevanten Metriken ab, legt sie über den Zeitverlauf des Vorfalls und erklärt die Ergebnisse.

Eine mehrschichtige Architektur für das Debugging

Unsere wichtigste Erkenntnis aus den Kundenbefragungen war, dass Debugging nicht nur ein einzelnes Problem ist, sondern ein ganzer Stapel von Problemen, deren Lösung gezielte Abstraktionen erfordert. Wir haben AI SRE als mehrschichtige Plattform konzipiert, bei der jede Schicht eine klare Aufgabe hat und sich die darüber liegenden Schichten auf zunehmend übergeordnetere Aspekte konzentrieren können.

Primitives bilden das Fundament: die rohen Betriebsdaten, von denen letztlich jede Untersuchung abhängt. Primitives für Metriken, Alarme, Logs, Release-Informationen und Code existieren bereits, aber der Zugriff darauf während eines Vorfalls bedeutete bisher, zwischen fünf verschiedenen Tools mit fünf verschiedenen Abfragesprachen hin- und herzuwechseln. Die Primitives-Schicht ersetzt diese Systeme nicht, sondern erkennt sie als die „Source of Truth“ (die verlässliche Datenquelle) an.

Die API-Schicht nutzt Primitives und bietet einen kontrollierten, einheitlichen Zugriff auf die zugrunde liegenden Daten. Anstatt dass jedes Debugging-Tool die Datenquellen wie Logs oder Metrik-Speicher direkt abfragt, haben wir zweckspezifische APIs entwickelt: eine Observability-API, eine Deployment-API und eine Alerts-API, die Authentifizierung, Ratenbegrenzung und Daten-Normalisierung übernehmen. Dies ist die Schicht, die „rohe Infrastruktur“ in „debuggbare Infrastruktur“ verwandelt. Das bedeutet auch: Wenn wir ein zugrunde liegendes System austauschen, funktionieren die darüber liegenden Debugging-Tools weiterhin einwandfrei.

In der Core Engine sitzt die Intelligenz. Ein Bot-Framework stellt die Orchestrierungsebene für die Erstellung von Debugging-Workflows bereit, während die Engine die Mechanismen für die parallele Ausführung, die Korrelation von Ergebnissen und die LLM-gestützte Synthese übernimmt. Dies ist die Plattform, auf der unsere hauseigenen Bots laufen. Entscheidend ist jedoch, dass es sich um dieselbe Plattform handelt, die jedem Team zur Verfügung steht, das eigene Bots entwickeln möchte.

In der Anwendungsschicht findet das eigentliche Debugging statt. Hier läuft unser Incident-Triage-Bot auf Plattformebene. Zudem können hier KI-Tools von Drittanbietern integriert werden, die ergänzende Funktionen bereitstellen, ohne dass wir alles von Grund auf neu entwickeln müssen.

Diese Trennung ermöglicht es uns, den Datenzugriff und die Orchestrierung unabhängig voneinander zu verbessern und gleichzeitig sowohl zentral gepflegte Workflows als auch teaminterne Runbooks zu unterstützen.

Entwicklung für Zuverlässigkeit in einer nicht-deterministischen Welt

Einen LLM-gestützten Agenten für das Incident Management so zuverlässig zu machen, dass man ihm vertrauen kann – und Vertrauen ist hier alles –, erforderte gezieltes Engineering. Dabei haben uns einige Prinzipien geleitet:

Strukturierte Prüfungen vor ergebnisoffener Analyse. AI SRE führt zuerst deterministische Plattform-Integritätsprüfungen und Runbook-Schritte aus. Die LLM-Schicht fasst die Ergebnisse zusammen und erklärt sie, aber die Datenerfassung wird nicht dem Urteil des Modells überlassen.

Transparenz statt Blackbox-Antworten. Jede Schlussfolgerung, die AI SRE präsentiert, verweist direkt auf die zugrunde liegenden Belege: die spezifische Metrik, die Log-Zeile, den Deploy-Diff. Engineers können die Argumentation überprüfen, anstatt ihr einfach nur vertrauen zu müssen. Dies war nicht verhandelbar, da Bereitschafts-Engineers keine Maßnahmen auf Basis einer Empfehlung ergreifen, die sie nicht selbst überprüfen können.

Graceful Degradation. Wenn AI SRE eine Fehlerursache nicht mit Sicherheit bestimmen kann, wird dies explizit kommuniziert und die dennoch gesammelten Belege nach Relevanz geordnet dargestellt. Eine unvollständige Untersuchung, die ehrlich mit ihren Grenzen umgeht, ist weitaus nützlicher als eine halluzinierte Diagnose.

Ergebnisse

AI SRE unterstützt mittlerweile mehr als 150 Teams bei Databricks. Über 250 wöchentlich aktive Nutzer führen täglich mehr als 2.000 Untersuchungen durch und sparen so mehrere Stunden Debugging-Zeit. Seit dem Start haben wir durchweg positives Feedback erhalten:

„Das Storage-Plattform-Team verlässt sich bei der Triage stark auf AI SRE. Es nimmt meine Untersuchungen vorweg: Noch bevor ich überhaupt eine Warnmeldung öffne, hat der Agent bereits Signale korreliert und eine erste Ursachenanalyse erstellt. Ein großes Lob an das Team für die Entwicklung einer wirklich universellen Debugging-Plattform, die es mehreren Teams ermöglicht, agentenbasierte Workflows in ihren Alltag zu integrieren.“—Gaurav Garg, Sr. Staff Engineer

„Vor AI SRE bestand die erste Phase eines Incidents aus dem Zusammentragen von Kontext: Dashboards, Zeitfenster, flottenweite Filter. Jetzt laufen alle relevanten Kontextinformationen an einem Ort zusammen, bereits auf die Warnmeldung bzw. den Incident eingegrenzt. Ich muss mich nicht blind auf das Wort des Agenten verlassen. Die Belege sind direkt in die Untersuchung eingebettet, und mit einem Klick öffnet sich das zugrunde liegende Tool – bereits vorgefiltert –, sodass ich es selbst überprüfen kann.“—Himanshu Mishra, Senior Engineer

„AI SRE hat das Incident Management transformiert, indem es Metriken, Logs und den Zustand von Abhängigkeiten vereinheitlicht, die Incident-Triage beschleunigt, Fehlerursachen früher aufdeckt und so die unternehmensweite MTTR senkt.“—Adama Kone, Manager – NOC-Team

Das wichtigste Ergebnis war nicht, das Urteilsvermögen der Engineers zu ersetzen. Es ging vielmehr darum, ihnen einen schnelleren, datengestützten Ausgangspunkt für ihre Untersuchungen zu bieten.

Was wir gelernt haben

Drei Erkenntnisse aus der Entwicklung von AI SRE:

Teams die Verantwortung für ihre eigene Expertise überlassen. Ein zentralisierter Agent, der versucht, das Fachwissen jedes einzelnen Teams abzubilden, wird immer veraltet und fehleranfällig sein. Indem wir agentenbasierte Runbooks zu einem modular aufbaubaren Grundbaustein gemacht haben, den die Teams selbst besitzen und pflegen, haben wir AI SRE in eine Plattform verwandelte, die mit ihrem Wachstum immer intelligenter wird, ohne selbst zum Engpass zu werden.

Die Kontextschicht aufbauen, bevor das Modell optimiert wird. Wir haben mehr Zeit damit verbracht, zu analysieren, wie Engineers Incidents tatsächlich untersuchen, als mit Prompt Engineering. Diese Vorabinvestition in das Verständnis des Problems führte dazu, dass wir das Richtige gebaut haben: einen Agenten, der Kontext zusammenstellt und bekannte Prüfungen ausführt, anstatt der naheliegenden Lösung – einem Chatbot, der einfach auf unser Observability-System aufgepfropft worden wäre.

Vertrauen durch nachvollziehbare Belege gewinnen. Bereitschafts-Engineers arbeiten unter Druck und können es sich nicht leisten, falschen Fährten nachzugehen. Jede Empfehlung von AI SRE ist durch nachvollziehbare Belege gestützt. Diese Transparenz hat skeptische Early Adopter in tägliche Nutzer verwandelt.

Guardrails sind für Agenten noch wichtiger als für Menschen. Den Agenten Zugriff auf Observability-Daten zu geben, bedeutete, unsere API-Schicht neu zu gestalten, anstatt sie einfach nur freizugeben. Agenten fragen anders ab als Menschen. Sie rufen Endpunkte in stoßartigen Wellen auf, führen Prüfungen parallel durch, werden nicht müde und drosseln ihre Aktivität nicht von selbst. Wir mussten Guardrails einbauen, damit Agenten schnell arbeiten können, ohne die Infrastruktur lahmzulegen, die auch für geschäftskritische Alarmierungen und das Monitoring zuständig ist.

Wie es weitergeht

AI SRE konzentriert sich heute auf die Untersuchungsphase des Incident Managements: zu verstehen, was passiert ist und warum. Der nächste logische Schritt ist die Erweiterung auf eine geführte Fehlerbehebung – also nicht nur das Problem zu diagnostizieren, sondern Engineers dabei zu helfen, sicher die richtigen Korrekturmaßnahmen zu ergreifen.

Wir investieren außerdem in incident-übergreifendes Lernen: die Nutzung von Mustern aus vergangenen Vorfällen, um zukünftige Diagnosen zu verbessern, wiederkehrende Probleme aufzudecken, bevor sie einen Alarm auslösen, und Teams dabei zu helfen, systemische Zuverlässigkeitslücken zu identifizieren.

Werden Sie Teil unseres Teams

Mit Blick auf die Zukunft freuen wir uns darauf, die Grenzen dessen, wie KI Produktionssysteme prägen und komplexe Infrastrukturen mühelos erscheinen lassen kann, weiter zu verschieben. Wenn Sie sich leidenschaftlich für den Aufbau der nächsten Generation KI-gestützter interner Plattformen interessieren, werden Sie Teil unseres Teams!

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag