Netflix baut Ontologie-basierte Observability mit 38 Millionen Events pro Sekunde

InfoQ Startseite Präsentationen Ontology-Driven Observability: Aufbau des E2E-Wissensgraphen im Netflix-Maßstab

Prasanna Vijayanathan und Renzo Sanchez-Silva zeigen, wie Netflix Observability bei 38 Millionen Ereignissen pro Sekunde angeht. Sie sprechen darüber, wie reaktives Monitoring durch eine KI-getriebene operationale Ontologie und agentische Workflows mit Claude und Graphdatenbanken ersetzt wird. Sie erklären, wie die Vereinheitlichung von MELT-Telemetrie in abfragbare Wissensgraphen automatisiertes Triaging, Root-Cause-Analyse und selbstheilende Systeme ermöglicht.

Prasanna Vijayanathan ist Ingenieur in der Consumer Engineering Organisation von Netflix, wo er Initiativen zu Performance, Observability und QoE mit KI/ML-Innovationen über Client-Plattformen hinweg leitet, die Zuverlässigkeit und Benutzererfahrung in globalem Maßstab verbessern. Renzo Sanchez-Silva ist Ingenieur im Observability-Team von Netflix, wo er in den vergangenen zehn Jahren Alerting- und Monitoring-Systeme entwickelt hat.

Software verändert die Welt. QCon London fördert die Softwareentwicklung, indem es die Verbreitung von Wissen und Innovation in der Entwickler-Community unterstützt. Als praxisorientierte Konferenz ist QCon für technische Teamleiter, Architekten, Engineering-Direktoren und Projektmanager konzipiert, die Innovation in ihren Teams vorantreiben.

Präsentiert von: Martin Reynolds - Field CTO bei Harness

Prasanna Vijayanathan: Mein Name ist Prasanna Vijayanathan. Ich gehöre zum Observability-Team bei Netflix. Ich arbeite an Observability, Performance und Quality of Experience über alle unsere Member-Anwendungen hinweg. Das bedeutet, dass ich mich damit beschäftige, wie sich Ihre Erfahrung bei Netflix anfühlt, vom Moment, in dem Sie auf das Netflix-Logo klicken, bis Sie etwas anfangen zu schauen. Welche Metriken sollten wir betrachten? Welche Werkzeuge sollten wir haben? Welche Einblicke sollten wir unseren Nutzern bieten, um sicherzustellen, dass wir verstehen, was Ihnen allen gefällt? Wenn Sie gerne Netflix schauen, sind Sie willkommen. Wenn nicht, können Sie meinem Kollegen Renzo die Schuld geben.

Renzo Sanchez-Silva: Ich bin Renzo Sanchez-Silva. Ich bin jetzt fast zehn Jahre bei Netflix, im Monitoring- und Alerting-Team innerhalb des Bereichs Observability, wo ich mehrere Alerting-Infrastrukturen aufgebaut habe und mich inzwischen mit dem Themenfeld AIOps beschäftige. Früher habe ich außerdem einige Forschungsarbeit im Bereich Ontologien geleistet. Mit KI konvergiert alles miteinander.

Prasanna Vijayanathan: Heute wollen wir mit Ihnen über ein Problem sprechen, an dem wir arbeiten und das auf den ersten Blick wie eine Observability-Herausforderung wirkt, in Wahrheit jedoch ein schwieriges Data-Engineering-Problem ist. Bevor ich darauf eingehe, möchte ich den Rahmen abstecken. Warum ist Observability im großen Maßstab schwierig?

Von welchem Maßstab sprechen wir überhaupt? Machen wir ein kurzes Quiz. Netflix hat Live-Events gestartet.

Ende 2024 war eines unserer ersten großen Live-Events, ein Boxkampf zwischen Jake Paul und Mike Tyson. Einige von Ihnen haben ihn vielleicht gesehen. Was glauben Sie, wie hoch unser Spitzenverkehr während dieses Events war?

Er lag definitiv im Millionenbereich. Es waren 65 Millionen gleichzeitige Streams. Das bedeutet, dass 65 Millionen Nutzer gleichzeitig auf Watch geklickt und den Stream angeschaut haben.

Das war unser Spitzenverkehr. Noch eine Frage. Wenn Sie sich bei Netflix einloggen, senden die Anwendungen Anfragen an unsere Infrastruktur, damit unsere Backends antworten und so weiter.

Wie viele Anfragen, glauben Sie, verarbeiten wir pro Tag von unseren Anwendungen an unsere Server? Wir verarbeiten mehr als 2 Milliarden Anfragen pro Tag. Eine letzte Frage.

Bei all diesen Anfragen haben wir natürlich unsere eigenen Observability-Systeme, in denen wir Metriken und viele verschiedene Dinge protokollieren. Wie viele Echtzeit-Logging-Ereignisse, glauben Sie, müssen wir pro Sekunde verarbeiten? Es sind mehr als 38 Millionen Ereignisse pro Sekunde.

Das ist der Maßstab, über den wir sprechen. Zahlreiche Client-Plattformen und Geräte, alle Fernseher auf der ganzen Welt, Mobiltelefone, Laptops, Sie nennen es. Tausende Microservices, die all diese Milliarden von Telemetrie-Ereignissen erzeugen.

Jedes einzelne Mitglied berührt so viele verschiedene Teile unserer Infrastruktur, unsere CDNs, Knoten und so weiter. Darüber hinaus betreiben wir Tausende von Experimenten im Rahmen von A/B-Tests in unserem gesamten Ökosystem. All das in diesem Maßstab zu managen.

Es ist alles, überall, alles gleichzeitig.

Selbst in diesem Maßstab ist unser Ziel bei Netflix, jedem Nutzer jedes Mal die bestmögliche Erfahrung zu bieten. Unsere Strategie bei Observability ist einfach: Haben wir die richtigen Werkzeuge, Metriken und Einblicke, die uns dabei ermöglichen?

Die Strategie ist einfach. Sie ist nicht leicht. In diesem Maßstab ist die Korrelation von Benutzererfahrung mit Systemperformance eine grundlegend andere Herausforderung.

Es ist keine Werkzeugfrage mehr. Es ist eine Data-Engineering-Herausforderung. Traditionell waren Observability-Systeme Monitoring- und Alerting-Werkzeuge, mit denen man Anwendungen und Services beobachtet.

Wenn etwas schiefgeht, wird man alarmiert. Dann schaut man sich an, was los ist, leitet es an die richtigen Teams weiter, sucht die richtigen Entwickler, um es bei Bedarf zu beheben, rollt einen Fix aus und prüft dann, ob die Daten wieder in den erwarteten Bereich zurückkehren. So haben Observability-Systeme traditionell funktioniert.

Mit End-to-End-Observability wollten wir neu überlegen, wie wir Observability betreiben, und sie von einer reaktiven Monitoring-Erfahrung in eine proaktive Insights-Engine verwandeln.

Bevor ich Ihnen zeige, wie wir das tun, möchte ich über die Vision sprechen, die wir entwickelt haben. Stellen Sie sich ein System vor, das automatisch in wenigen Minuten Probleme im gesamten Stack erkennen kann. Nicht nur in einem Service oder einer Anwendung, sondern im gesamten Stack.

Wo immer ein Problem auftritt, wissen Sie, dass genau das passiert. Dann priorisieren Sie diese Probleme automatisch danach, wie sie sich auf unsere Nutzer auswirken. Außerdem können Sie sie automatisch an das richtige Team weiterleiten.

Sie müssen nicht eine Anwendung und einen Fehler betrachten und sagen, ich glaube, ich verfolge diese Nadel durch diesen Heuhaufen und ziehe verschiedene Services heraus und binde sie ein. Dann: Können wir automatisch die Ursache finden? Nicht nur triagieren, sondern können wir tatsächlich die Grundursache des Problems identifizieren?

Oder, noch besser: Können wir Probleme vorhersagen, noch bevor sie tatsächlich beginnen, sich auf unsere Nutzer auszuwirken, und vielleicht sogar Korrekturmaßnahmen vorschlagen oder einleiten?

Ist das möglich? Wir wollten das tun. Der Aufbau dieses Systems würde uns nahtlose Sichtbarkeit verschaffen, vom Gerät des Nutzers durch unsere Netzwerke zu unseren Gateway-Services bis in die tiefsten Bereiche unserer Backend-Abhängigkeiten und Services. Alles verbunden, alles in Echtzeit. Nutzer würden keine Unterbrechungen ihrer Erfahrung bei Netflix haben. Jedes Mal, wenn Sie Netflix schauen, werden Sie es lieben. Ihre Erfahrung wird großartig sein, jedes einzelne Mal. Das ist unsere Vision.

Klingt großartig. Das ist weit von der Realität entfernt. Heute sieht es sehr anders aus.

Ich führe Sie durch eine Zeitlinie einer kürzlichen Untersuchung, vermutlich innerhalb des letzten Jahres oder so. Es gab einen Alarm, der auf einer unserer Client-Plattformen ausgelöst wurde, ich würde sagen, gegen 3:30 Uhr. Typischerweise schauen sich die Bereitschaftsingenieure das an und denken: Ich warte erst einmal ab.

Mal sehen, ob das anhält. Vielleicht passiert etwas Magisches und es verschwindet von selbst. Manchmal tut es das.

Manchmal nicht. Ein paar Stunden später schauen sie sich das tatsächlich an: Ich glaube, das ist ein echtes Problem. Ich muss herausfinden, dieser Nadel folgen und prüfen, ob ein anderer Service sich darauf auswirkt. Im Durchschnitt ist das meist der Fall.

Dann wird es an das richtige Team weitergeleitet. Dann stellt sich heraus, dass dieses Team das Problem bereits seit 1:30 Uhr an diesem Tag debuggt hat. Die Leute sind bereits daran.

Jetzt sind mehrere Teams beteiligt. Zwischen all diesen verschiedenen Teams findet deutlich mehr Debugging statt. Sobald das Debugging beginnt, finden sie die tatsächliche Ursache des Problems und verfolgen die Nadel bis zum tatsächlich verantwortlichen Service.

In diesem Fall stellte sich heraus, dass ein Service, der sich für nicht so wichtig hielt, seine Kapazitäten reduziert hatte. Das verursachte Rückwärtspropagierungsfehler. Das war gegen 6:30 Uhr, drei Stunden nachdem die Client-Anwendung tatsächlich echte Auswirkungen auf Nutzer bemerkt hatte.

Wir haben einen Fix ausgerollt. Er wurde innerhalb einer Stunde behoben. Das ist ein Durchschnittsfall.

Das klingt nicht so schlimm. Es sind etwa vier Stunden. Nicht so schlimm.

Wenn man dann bedenkt, was es gekostet hat: In dieser Zeit wurden neun Teams alarmiert. Mehr als 30 Ingenieure waren in unterschiedlichen Funktionen an dem gesamten Debugging-Prozess beteiligt. Dazu wurden drei weitere verwandte Vorfälle gemeldet.

Es herrscht Panik überall in den Teams. Das ist typisch, und das ist ein Durchschnittsfall. Das ist nicht einmal ein schlechtes Beispiel.

Wenn man dann die vier Stunden und all die beteiligten Ressourcen zusammennimmt, wirkt es einfach verschwenderisch. Genau das möchte man mit End-to-End-Observability lösen.

Wir haben uns gefragt, warum. Warum passiert das? Wir haben vier Hauptthemen identifiziert, die bestanden.

Erstens hat man zu viele isolierte Datenquellen. Wir haben im Wesentlichen Logs, Metriken, Events und Traces, die in unterschiedlichen Formen in verschiedenen Datenspeichern abgelegt sind. Sie existieren in Silos.

Diese Silos kommunizieren nicht miteinander. Sie sind nicht standardisiert, die Strukturen sind unterschiedlich und so weiter.

Das führt zu unverbundenen und kontextlosen Alarmierungen, was bedeutet, dass jedes Team einer Datenquelle folgt, die in ihrem Silo gut funktioniert, und dort Alarme einrichtet. Wenn dann Alarme ausgelöst werden, betrachtet ein Team dasselbe Problem aus seiner Sicht, während ein anderes Team dasselbe Problem aus einer anderen Perspektive betrachtet. Eigentlich sollten die Teams miteinander sprechen, aber das passiert nicht.

Was das zur Folge hat, ist Komplexität darin, wie Teams das Problem einordnen und tatsächlich fehlerbeheben. Letztlich bedeutet das, dass wir nicht erkennen, welche Auswirkungen sich für unsere Nutzer ergeben. Wenn man ein nachgelagerter Dienst ist, fünf oder zehn Hops vom Nutzer entfernt, versteht man fast nie, wie das eigene System und der eigene Dienst den Endnutzer beeinträchtigen.

Angesichts der Vision, die wir für End-to-End-Observability haben, wie lösen wir das und bewegen uns von der Realität zur Vision? Die Antwort aus einem Wort lautet: Verbundenheit. Das war unser Gedanke.

Das ist der gemeinsame Nenner. Wir wollen verbundene Daten, verbundene Alarmierung, verbundene Debugging-Systeme, Workflows und Ursachenanalyse. Wenn wir dieses Leitmotiv für End-to-End-Observability schaffen, brauchen wir nicht zehn verschiedene Datenquellen, die sechs verschiedenen Werkzeugen den Boden bereiten.

Wir wollen eine integrierte Observability-Schicht schaffen. Eine Abstraktion, die uns alles über die Observability unserer Systeme sagen kann. Das bedeutet dann, dass unsere Dashboards, Alarme, Debugging-Workflows und Tools für den Vorfallmanagement alle dieselbe Sprache sprechen.

Dadurch wird die doppelte Arbeit bei der Fehlerbehebung und Einordnung derselben Probleme und Symptome im gesamten System reduziert, was bedeutet, dass man einer Brotkrumenspur folgen und von dort auf demselben Weg vom Gerät des Nutzers bis zur eigentlichen Ursache gelangen kann.

Man kann der Spur aus verschiedenen Richtungen folgen, aber auf denselben Hauptpfad der Ursachenanalyse gelangen. Das führt dazu, dass die Zeit zur Behebung von Problemen verkürzt wird und letztlich die Genauigkeit der Diagnose verbessert wird, was den Nutzern ein weniger gestörtes und besseres Erlebnis verschafft. Der Kern all dessen beginnt mit den Daten, mit verbundenen Daten.

Wir haben Nutzer, Geräte und Anwendungen sowie Dienste und Infrastruktur, die alle diese grob vier Datenkategorien emittieren: Metriken, Events, Logs und Traces. Wir vereinheitlichen sie und führen sie in einer Schicht zusammen, der MELT-Schicht. Sobald wir all diese Quellen vereinheitlicht haben, lösen wir das Problem.

Wichtig ist, dass selbst wenn all dies zusammen existiert, die Daten akkurat und umsetzbar sein müssen.

Lassen Sie mich Ihnen ein weiteres Szenario durchgehen. Sagen wir, wir haben diese Schicht bereits. Sagen wir, wir sehen eine Verschlechterung, LOLOMO TTR.

LOLOMO ist die Metrik für die Liste von Filmlisten, die man bei Netflix sieht. TTR ist eine gewisse Renderzeit für diese Liste von Filmlisten. Man sieht dort eine Verschlechterung.

Es gibt ein langsames Leck und eine deutliche Verschlechterung. Ein Entwickler bemerkt das und fragt unsere vereinheitlichte Datenschicht: Was ist passiert? Nun leben alle Observability-Daten in einer Schicht, also sag mir, was passiert ist.

Dann würde das Metrik-System antworten: Ja, ich sehe, dass LOLOMO TTR sich verschlechtert. Ich sehe außerdem zwölf weitere Metriken über fünf verschiedene Dienste hinweg, die korrelieren und zur selben Zeit auftreten. Auch diese verschlechtern sich.

Wir finden einige Korrelationen. Das ist gut. Dann können Events erzählen, dass es 47 Events über all diese verschiedenen Anwendungen und Dienste hinweg gibt, die genau vor Beginn dieser Verschlechterung auftraten.

Ja, ich kann das in einem Graphen sehen.

Ich kann all diese Events zusammen mit den Metriken sehen. Dann sagen mir die Logs: Ich glaube, es gibt einen Fehler durch Erschöpfung des Connection Pools, der zu diesem Zeitpunkt in einem jener sieben Dienste stark angestiegen ist. Vielleicht ist es das.

Es gibt außerdem all diese Timeout-Fehler in all den anderen Diensten zur selben Zeit. Dann können Traces eine andere Geschichte erzählen. Wenn ich über die Arbeit sprechen soll, die wir mit Traces gemacht haben, wäre das eine eigene Session.

Um Ihnen eine Vorstellung zu geben: Ein Trace zeigt Ihnen den Pfad einer bestimmten Anfrage und Antwort vom Nutzer über alle Dienste, die sie berührt haben. Sie können diesen Pfad verfolgen. Die Herausforderung beim Tracing ist, dass man, außer man weiß genau, welchen Trace man sucht, extrem schwer damit ein Problem präzise debuggen kann.

Es ist nicht einmal eine Nadel im Heuhaufen. Es ist, als würde man im Dunkeln und mit verbundenen Augen nach einem Blatt in einem Wald suchen. Das ist schwierig.

Was uns wirklich fehlt, ist nicht nur Verbundenheit, sondern die Beziehungen zwischen all diesen verschiedenen Teilen dieses Puzzles. Wir müssen die Verbindungen zwischen diesen Komponenten kennen, ja, aber wir wollen auch wissen, wie sie miteinander interagieren und wie sie miteinander in Beziehung stehen. Das nennen wir die Observability-Ontologie. Renzo wird Ihnen zeigen, wie wir diese Beziehungen aufbauen und wie wir sie jeden Tag nutzen.

Renzo Sanchez-Silva: Was ist eine Ontologie? Es ist einfach eine formale Spezifikation von Typen, Eigenschaften und Beziehungen. So kodieren wir Bedeutung.

Das grundlegende Konstrukt davon ist das, was man das Triple nennt. Ein Triple ist ein Subjekt, ein Prädikat und ein Objekt, eine Tatsache pro Triple. Es kann sein: eine Person ist ein Angestellter.

Ein Dienst ist wichtig, oder tier-0 zum Beispiel. Es können auch Eigenschaften sein. Auf diese Weise kodieren wir Wissen.

Es ist sehr grundlegend, sehr ursprünglich eigentlich. Es ist, als würde man sagen: Tarzan liebt Jane. Mama liebt Papa.

Babys haben Mini-Ontologien im Kopf. Wir sammeln einfach all diese symbolischen Triples in unseren Köpfen und beginnen, Aussagen zu machen, zu schlussfolgern und so weiter. Ontologien sind eine Weise, Wissen zu kodieren.

Wir verwenden W3C-Standards: RDF, OWL, die Web Ontology Language, SPARQL als Abfragesprache, SHACL, die Shapes Constraint Language, mit der wir sagen können, dass ein Dienst in AWS beendet werden darf, aber eine weitere Einschränkung ist, dass, wenn der Dienst mehr oder weniger als 10 Prozent der Kapazität hat, er nicht beendet werden darf.

Man kann all diese Dinge kodieren. Man kann die Dienste, die gesamte Infrastruktur beschreiben. Zum Beispiel haben wir ein API-Gateway.

Es ist vom Typ Anwendung. Es gehört einem Team. Es ist in einer Region deployt und so weiter.

Wir können jedes einzelne Teil der Infrastruktur beschreiben, und jedes Teil ist ebenfalls namespaced. Wir haben angefangen, diese Baby-Ontologie zu bauen, indem wir Vorfälle beschrieben haben. Wir haben einige Namespaces identifiziert.

Wir bauen eine operationale Ontologie. Das Ziel, um noch einmal auf Prasannas Vision zurückzukommen, ist, diesen End-to-End-Observability-Graphen aller miteinander verbundenen Dinge in unserer Infrastruktur zu finden. Nennen wir das die operationale Ontologie.

Wir identifizieren beispielsweise diese Namespaces, und sie können formal in den Triples referenziert werden.

Das Problem ist, wie man Ordnung in dieses operationale Chaos bringt, bei Vorfällen, die über Slack, PagerDuty, die MELT-Schicht, Metriken, Traces, Logs und Events verstreut sind. Wir versammeln uns alle gemeinsam im Kanal. Es gibt Hunderte von Nachrichten, viele Dienste, Menschen, die interagieren.

Es ist chaotisch, bis wir die Ursache finden und dann das Problem viele Stunden später beheben. Was wir tun wollen, ist, das zu beobachten und in Echtzeit zu kodieren. Die Strukturen zu erfassen und wie wir sie in maschinenlesbaren Typen erhalten.

Eine Nachricht kann natürlich auf Englisch sein. Dann sagt jemand, das API-Gateway habe nach diesem Deployment Latenzspitzen, und so weiter, und dann rollt Jane zurück. Das kann man in Triples beschreiben.

Das ist die Idee dahinter. Das von Hand zu machen, ist schwierig. Tatsächlich brauchte man früher, als es noch keine KI gab, einen Ontologen, der ständig annotierte: das ist das, das ist eine Person, das ist ein Dienst und so weiter.

Mit KI können wir das viel schneller erledigen. Dafür haben wir das erstellt, was wir eine Harvest-Pipeline nennen. Die Vorfälle treten in Slack auf.

Dort findet das Geschehen statt. Für jeden Kanal transformieren wir jede Nachricht und schicken jede Nachricht an eine Reihe von Anreicherern. Wir rufen Observability-APIs auf.

Wir setzen darauf auf LLMs ein, um zusätzliche Klassifizierung zu finden, und korrelieren das. Wir speichern das in unserer Graphdatenbank, wir nennen sie QuipuDB. Die Anreicher in Grün sind sehr deterministisch.

Wir wollen identifizieren, zum Beispiel, dies ist auf incident.io, wir nutzen es als unsere Software für das Vorfallmanagement, es hat diese ID. Wir haben den PagerDuty-Alarm, der ausgelöst wurde, den extrahieren wir beispielsweise. Wir haben verschiedene sehr deterministische, kleine Algorithmen, die Dinge klassifizieren, weil wir zum Beispiel URLs kennen und IDs extrahieren.

Wir extrahieren zum Beispiel auch die Stimmung dessen, was im Thread oder in der Nachricht geschieht.

In Blau haben wir Alarme und die Timeline, die entsteht. Menschen teilen Links zu unserem Dashboard. Das kodieren wir.

Wir wissen, was das bedeutet. Jemand lädt einen Snapshot oder Screenshot hoch, wir speichern das. Es ist ein Screenshot, der zu diesem Graphen gehört, zu dieser Metrik.

Am Ende dieses Prozesses verwenden wir ebenfalls LLMs, wenn wir all diese grundlegenden Muster oder Entitäten identifiziert haben, und beginnen, neue Beziehungen oder Konzepte oder neue Definitionen zu finden. Beim LLM sieht man großartige Dinge wie etwa Canary-Analysen, fehlgeschlagene Deployments und Ähnliches. Es beginnt, Konzepte aus dem zu finden, was bisher gesammelt wurde.

Wenn etwas neu ist, versuchen wir eine neue Definition vorzuschlagen. Das nennt man in der Ontologie die Open-World-Assumption, bei der man gewissermaßen frei ist, Beziehungen hinzuzufügen, und wir haben Wege, das zu kontrollieren. Es ist ein sehr kontrollierter Prozess.

Das geschieht sequenziell. Manchmal lassen wir etwas einfach stehen, wenn es fehlschlägt. Wenn wir beispielsweise某些 Daten nicht erfassen können, würde man es dort belassen.

Dann prüfen wir gegen unsere wichtigsten Metadatenquellen. Der Software-Katalog ist zum Beispiel der Ort, an dem wir die Definition aller unserer Services haben. Wir identifizieren jeden Service und wissen, welchen Typ er hat und so weiter.

Es ist sehr kontrolliert.

Das Ziel ist es, aus Nichtdeterminismus Determinismus zu schaffen. Der Nichtdeterminismus beginnt beispielsweise mit dem Chaos im Kanal. Das ist die erste Quelle von Nichtdeterminismus.

Dann haben wir eine Reihe von Regeln, mit denen wir die Daten extrahieren. Ganz zum Schluss kommt als i-Tüpfelchen das LLM daher und sagt, dies ist wahrscheinlich eine neue Beziehung, hier besteht eine neue Verbindung und so weiter.

Das Paradox dabei ist, dass wir stochastische Werkzeuge verwenden, um einen deterministischen, per SPARQL abfragbaren Graphen zu erzeugen. Die Ontologie ist die Brücke. Dort speichern wir alle Daten.

Wir identifizieren fünf Schichten. Das ist ein Bootstrapping-Prozess. Die deterministische Extraktion sind die grünen Schritte.

Wir haben zum Beispiel eine Reihe von Regex-Mustern, die erkennen, was ein Jenkins-Job ist, nach ID, nach Server. Das ist eine Entität. Das sind sehr bekannte Muster.

Dann erfolgt die Katalogvalidierung, das heißt es wird im Katalog geprüft, ob der Service ein gültiger, in dieser Region deployter Service ist und so weiter.

Wir reichern mit unseren APIs an, den Observability-APIs, und lassen dann das LLM klassifizieren und neue Prädikate finden. Wir haben außerdem einen letzten Schritt, den wir probabilistische Korrelation nennen, bei dem wir die erste Suche über die gesamte Konversation durchführen. Wir finden Ketten, bei denen der Vorfall mit dieser einen Anwendung begann, die Anwendung B beeinträchtigte, die ursprüngliche Anwendung zurückgerollt wurde und dann das Problem behoben war.

Diese Kette wird ebenfalls als Entität identifiziert, ein Muster, das gespeichert wird, damit wir in Zukunft vielleicht Ähnlichkeiten finden, diesen Vorfall mit etwas Künftigem. Außerdem ist alles eingeschränkt. Wir haben Kategorien, einige Taxonomien, und alle sind beschränkt.

Wenn das LLM zum Einsatz kommt und eine Kategorie klassifizieren soll, etwa ob diese Konversation ein Incident, eine Frage, eine Diskussion oder eine Entscheidung ist, kann es nur aus diesen vier Werten wählen. Wir lassen es nicht neue Dinge halluzinieren, außer es teilt uns das vielleicht mit, und dann sehen wir, wie wir damit umgehen können.

Alles ist typisiert, zum Beispiel ist thread 123 related mit dem Wert true, ein Boolean.

Der Prozess, den wir beschreiben, ist ein Bootstrapping-Prozess, den wir das Wissens-Schwungrad nennen, bei dem jede Umdrehung, sagen wir, ein Thread beginnt. Wir beginnen, Entitäten zu identifizieren. Es kommen weitere Daten herein, und wir drehen uns auf diesem Schwungrad weiter, indem wir beobachten, anreichern, schließen und uns anpassen.

Wir beobachten die MELT-Daten. Wir reichern mit all diesen Anreicherungen an. Wir schließen, um möglicherweise neue Muster zu finden oder alte Muster einfach anzuwenden, und wir passen uns an, um zu sehen, welches Wissen wir gewinnen können.

Die kausale Kette eines Vorfalls wird zu einem bekannten Muster für den nächsten. Beobachten, anreichern, schließen, das ist der Hauptprozess. In jeder Iteration kodieren wir Wissen.

Jeder Zyklus lehrt das System, wie die Ontologie dieses Schema in den Speicher einbringt. Wir haben auch einen Prozess, in dem Daten in Informationen umgewandelt werden, und diese Informationen werden in Wissen kodiert. Das Vierte ist Weisheit, Weisheit in dem Sinne, dass wir die Ursache finden können.

Wir können das heute kodieren, aber auch in der Zukunft.

Wir sagen hier noch nichts vorher. Wir beschreiben nur immer. Zuerst beschreiben. Das macht ein Baby auch so. Daddy loves mommy, er weiß, dass das eine Tatsache ist, aber dann werden später mehr Dinge geschehen. Alles ist über SPARQL abfragbar. SPARQL ist eine seltsame Syntax, aber man gewöhnt sich daran. LLMs lieben sie. Es stört uns nicht. Ich lese sie manchmal nicht einmal wieder. Wiederum akkumuliert die Ontologie die Struktur dessen, was immer wieder geschieht. Muster werden zu abfragbaren Fakten.

Es verwundert nicht, dass wir dabei KI einsetzen. Wir nutzen Claude als unseren Co-Entwickler. Wenn wir einen neuen Thread oder eine neue Nachricht zu einem Incident erhalten, lassen wir diesen Harvester laufen.

Er erstellt einen git worktree, weil wir nicht mit anderen Branches in Konflikt geraten wollen, da viele Incidents gleichzeitig laufen oder vielleicht eine weitere Iteration kommt, eine vorherige Ernte noch an etwas arbeitet und noch nicht abgeschlossen ist. Er erstellt einen git worktree oder einen Branch. Dann nutzen wir Claude auch zum Ernten.

Wir führen nicht einfach nur ein Skript aus. Wir führen Claude mit dem Harvesting-Skript aus, um die Daten zu extrahieren, weil es den LLM-Schritt gibt, der neue Muster findet. Gleichzeitig nutzen wir es, um vielleicht Bugs in genau diesem Skript zu finden, sodass es sich tatsächlich selbst repariert.

Dann endet diese gesamte Schleife, und wir landen bei 15 Branches allein für diese Serie von Iterationen, für einen einzigen Incident, und dann kommt der Human in the Loop ins Spiel.

Entweder ich oder Prasanna können hineingehen und sagen, wir haben all diese Branches, und dann bitten wir Claude, zu cherry-picken und zu sehen, was passiert ist. Es findet sehr interessante Dinge. Es findet neue Fakten.

Bei manchen sagt es, diese fünf Branches haben fast dasselbe getan. Sie haben dieses Muster gefunden. Ein anderer Branch stellte fest, dass er auf Sonnet 4.5 lief, und beschloss, sich auf 4.6 zu aktualisieren, was cool ist.

Es heilt sich gleichzeitig selbst. Man sagt, okay, merge. Dann macht man weiter.

Es ist eine Meta-Schleife. Das Schwungrad erzeugt das Wissen, und das zweite verbessert die Maschinerie und nutzt dabei vorerst uns. Die Idee ist eigentlich, das unabhängig von Menschen zu machen und von selbst zu mergen.

Dann iterieren wir darüber hinaus weiter, also viele Schwungräder übereinander, sozusagen eine Pyramide. Bis es vollständig autonom ist, und dann gehen wir zu anderen Domänen oder Namespaces über. So sehen wir das in Slack, weil Slack praktisch ist.

So sieht es aus. Zum Beispiel finden wir bei jeder Iteration ein paar Kanäle, und dies war zufällig ein Platform-Operations-Kanal, ein Metrics/Analytics-Engineering-Kanal, all diese Klassifizierungen sind Dinge, die es vorher gefunden hat. Ich habe ihm nie gesagt, was es war, aber ich habe es akzeptiert.

Ich habe es geprüft und stichprobenartig kontrolliert. Das ist ein Alert-Management-Kanal. Es sind keine Incident-Kanäle.

Dies sind allgemeine Kanäle. Wir beobachten auch alle Slack-Kanäle. Denn denken Sie daran, die Idee ist nicht nur, mit einer kleinen Ontologie zu beginnen und dann zu größeren Teilen der Infrastruktur aufzusteigen, um sie zu beschreiben.

Das gilt nur für allgemeine Kanäle. Das passiert am Ende einer Iteration. Zum Beispiel hat es in diesem Durchlauf etwas Turtle gefunden.

Turtle ist die Art, wie wir RDF in der Ontologie-Sprache serialisieren. Es fand einige Probleme mit den Regex-Mustern, und die URIs wurden nicht korrekt als gültiges Turtle gespeichert.

Es fand einen Diff und so weiter. Das kann ich fortsetzen und sagen, du kannst das mergen, und es geht und tut es. Alle Tests bestanden. Der Merge ist abgeschlossen und erfolgreich. Lass mich eine Zusammenfassung erstellen. Das bedeutet, dass für die nächste Iteration dieser Code bereits im Main-Branch ist. Bei der nächsten Iteration fügt jemand eine neue Nachricht im Kanal hinzu oder macht eine neue Entdeckung. Jemand findet eine Ursache, die tatsächlich diesen neuen Code ausführen wird. Der nächste git worktree, der gestartet wird, wird diesen Fix bereits gemerged haben.

Der Teil, der diese Ketten extrahiert, über die ich gesprochen habe, ist Teil unserer Korrelations-Engine. Er findet all diese Ketten. Zum Beispiel wurde ein Commit mit Retry-Logik durchgeführt.

Er wurde mit dieser Version deployt. Drei Minuten später gab es einen Fehler, einen Connection-Timeout, ein Alert wurde ausgelöst und der Incident wurde gestartet. Dann kommt das LLM mit seiner eigenen Konfidenz, aber wir speichern diese Kette.

Viele Ketten können in einem Incident auftreten. Stellen Sie sich all diese Ketten zusammen vor, dann werden wir in Zukunft viele Daten für Fine-Tuning und Ähnlichkeit haben. Agents sind tatsächlich Entropie-Reduzierer.

Denn wie gesagt erhalten wir verrauschte Eingaben. Am Ende geben wir Triples aus, mit neuen Beziehungen, aber gleichzeitig finden wir bessere Wege, Daten zu extrahieren, weil die agentische Schleife läuft. Wir machen zum Beispiel Dinge wie SME, Subject-Matter-Expert-Erkennung.

Diese Person ist tatsächlich ein Fachexperte, und wir finden das Thema ebenfalls.

Die Ansammlung dieser Tripel zeigt uns irgendwann, dass diese Person ein Experte für Servicedatenverarbeitung oder für Kafka und so weiter ist. Wir haben auch diese Service-Topologien bereits als Turtle vorliegen, weil wir sie von Grund auf aus vielen Quellen aufgebaut haben, unter Verwendung von eBPF, Logs und Tracing. Wir haben diesen Graphen aller tausenden Abhängigkeiten unserer Services erstellt, welche Services einander aufrufen.

Das ist ein Teil davon. Der Vertrag sind die Enricher. Wir haben eine Klasse, die ein Interface ist, in dem man den Anreicherungsteil sieht; man kann Tripel zum Graphen hinzufügen und so weiter. Wir haben viele davon, und mit jedem weiteren Datenstrom kommen weitere Enricher hinzu.

Claude wird uns tatsächlich sagen, dass wir einen neuen Enricher bauen müssen, weil wir dieses neue Ding sehen, das ich aus der bisherigen Geschichte nicht kenne und so weiter. Es ist nicht im Code. Es ist nicht in der Ontologie.

Wir müssen es erstellen. Jede URI in den Entitäten ist stabil. Wir haben eine Domain und IDs.

Wir können sie immer über den Namespace referenzieren.

Aus einem Graphen gehen wir in eine Wissensbasis. Der Prozess sieht erneut so aus, dass bei jedem Lauf des Harvesters die Turtle-Dateien in S3 gespeichert werden. Wir erstellen eine Parquet-Datei.

Wir haben eine Graphdatenbank, die diesen Stream ständig abfragt. Es ist tatsächlich ein CDC-Stream, ein Change-Data-Capture-Stream, der diese Tripel in den Speicher lädt. Wir können in Echtzeit abfragen, weil wir dann die Daten haben.

Wir haben beispielsweise den Vorfall beschrieben. Jemand anderes aus einer Claude-Code-Sitzung, oder Cursor, oder was auch immer, kann abfragen, was mit Vorfall 123 los ist. Diese Daten haben wir bereits.

Das LLM wird SPARQL-Abfragen stellen und anfangen, Fragen zu stellen, und dann eventuell eine Korrelation zu einem früheren Vorfall herstellen und so weiter. Man nutzt weitere MCP-Tools und so fort. Wir speichern auch Blobs.

Wenn zum Beispiel jemand einen Graphen hochlädt, wird diese Datei in S3 gespeichert, und wir wissen, dass sie zu einer Metrik gehört.

Das ist die verwendete Abfrage. All das ist beschrieben. Der eigentliche Graph, ich meine das Dashboard-Diagramm, hat einen Screenshot. Der Screenshot wird gespeichert, die Bytes in S3. Dieser Blob ist ebenfalls eine Entität. Alles ist verknüpft. Wir können all diese Daten wiederherstellen. Vielleicht möchte man eine forensische Analyse durchführen und alles zurückholen und genau herausfinden, was passiert ist, als die Ereignisse auftraten. Die Ontologie ist ein Vertrag zwischen Chaos und Verständnis. Unsere stochastischen Engines sind durch dieses sehr starke Typsystem eingeschränkt, das auf der Ontologie basiert, und sie erzeugen deterministische, abfragbare Tripel. So haben wir mit der Incident-Ontologie begonnen, mit ein paar Namespaces, vielen Agents und Signalen.

Das ist eines der Artefakte, die wir bei jedem Lauf erzeugen. Es ist einfach eine HTML-Datei, die in S3 gespeichert wird. Wir nutzen sie zum Debuggen, weil ich immer wieder nachschaue: Wird das Richtige extrahiert?

Ich weiß, dass es ein Jira-Issue geben muss, oder Slack-Nutzer oder Dateianhänge und all diese Dinge. Bei jedem Lauf stelle ich manchmal fest, dass keine Dateianhänge gefunden werden. Ich brauche gewisse Artefakte, ein gewisses Ziel, weil ich ständig in den Code schaue.

Ich schaue mir einfach diese Ergebnisse an, weil ich weiß, was darin enthalten sein muss. Wenn es nicht da ist, müssen wir weiter nachbessern. Schließlich konnte ich mit Hilfe dieses Artefakts alles prüfen.

Das ist einfach eine Zeitleiste des Vorfalls. Alles ist typisiert und verknüpft. Das ist ein großer Vorfall mit vielen Beziehungen.

Die Topologie, die Service-Abhängigkeiten, ist ebenfalls darin enthalten. Jeder kann beliebige Fragen stellen, zum Beispiel welche Teams beteiligt sind.

Wer hat hier eine schlechte Stimmung? Wer ist sehr gestresst und so weiter? Alles ist verknüpft. Stellt man sich vor, wie all diese Vorfälle sich im großen Graphen verbinden, können wir sie gleichzeitig abfragen. Die eigentliche Herausforderung besteht darin, all diese Daten zeitnah fließen zu lassen, was wir Time Travel nennen. Im Moment speichern wir nur ein paar Wochen an Daten. All diese Daten liegen in S3, sodass wir letztendlich eine wirklich große Datenbank aufbauen können, die wir jederzeit abfragen können.

Wie nutzen wir die Ontologie? Eine der Anwendungen ist das, was wir AutoSRE nennen. Es ist unsere KI-basierte SRE-Lösung.

So heißt es inzwischen in der Branche: Site Reliability mit Hilfe von KI unterstützen, also SRE. So nennen wir es. AutoSRE greift in Echtzeit auf Metriken, Logs und Traces zu, und auch auf Slack.

Es hat die Topologie, es hat auch Geräte und Möglichkeiten, den End-to-End-Graphen zu betrachten, also die Geräte. Es greift auf die Ontologie zu, also auf den Wissensgraphen, der weitergehende Beziehungen als Domänenkonzepte enthält. Zurück zum LOLOMO-Vorfall bzw. Issue: AutoSRE kommt hinzu, nicht nur der On-Call-Dienst, und analysiert alle MELT-Daten und Versionen aller laufenden A/B-Tests und findet dann Korrelationen viel schneller als Menschen.

Es findet heraus, welche Vorfälle oder Apps daran beteiligt sind und so weiter. Es findet auch Logs.

Es nutzt diese. Wir haben eine Reihe von MCP- und CLI-Tools, die die Infrastruktur abfragen, nicht nur die Ontologie, sondern wirklich die Daten im Allgemeinen. Es schaut sich auch den Code an, wie viele andere Lösungen das tun, denn man kann Systeme nicht verstehen, wenn man nicht bis in den Code hinabsteigt. Das ist die Ausgabe. Es sagt, es gab einen Spike von GraphQL-Fehlern für diese Record-Operation, und die nächsten Schritte sind diese. Wir haben dem tatsächlich Interaktivität hinzugefügt, bei der Nutzer Folgefragen stellen können, weil es heute wirklich schwierig ist, eine KI dazu zu bringen, beim ersten Durchlauf im ersten Loop die richtige Antwort zu liefern. Man muss viele Iterationen durchlaufen, um tiefer einzutauchen, weil die LLMs abschweifen können und so weiter.

Was hält die Zukunft für uns bereit? Es gibt drei Dinge. Wir wollen eine automatische Root-Cause-Analyse finden.

Wir wollen nicht weiter graben. Wir können einfach die Kristallkugel fragen: Das ist die Ursache. Als Nächstes wollen wir tatsächlich automatische Remediations durchführen.

Wenn wir zum Beispiel wissen, dass diese Muster auftreten, wird die Ontologie sagen, in dieser Situation ist das Beste, die Instanz einfach zu beenden. In Ordnung. Tu es.

Auto-Remediation. Selbst ganz ohne menschliches Zutun. Das dritte ist eine selbstheilende Infrastruktur.

Das ist der Traum. Wir wollen gar nicht erst zu einem Vorfall kommen. Wir wollen nicht einmal einen Alert bekommen.

Wir wollen immer weiter nach links shiften, bis zu dem Punkt, an dem die Infrastruktur sich selbst heilt, denn wenn wir nicht nur unsere Vorfälle oder unsere operativen Daten beschreiben, werden wir Ontologien bis hin zur Data-Lineage verschmelzen, bis zu dem Punkt, an dem man zum Beispiel sagen kann: Ein Film wurde erstellt.

Es gab einen Datenfehler in einer Pipeline, die von diesem Team, von dieser Person zu diesem Zeitpunkt ausgeführt wurde, der sich kaskadenartig bis hin zu schlechten Klicks im UserService fortsetzte. Das ist der End-to-End-Traum, den wir verwirklichen wollen. Nicht nur die Ontologie bilden, sondern sie mit anderen, größeren Domänen verschmelzen und eine große Enterprise-Ontologie schaffen, die alles beschreibt. Das führt zurück zum ursprünglichen End-to-End-Rad, das Prasanna gezeigt hat. Diesen großen Zyklus finden, der alle kleineren Ontologien zu einer großen verbindet.

Kennt jemand diese Figur aus „Dark“? Sie sind tatsächlich Zeitreisende. Es gibt eine Clique, die es geschafft hat, die Zeit zu beherrschen. Sie konnten in die Zukunft reisen und tatsächlich auch Wissen. Die Inspiration hier ist, dass ich eines ihrer Mantra verwende. Es lautet: „Der Anfang ist das Ende und das Ende ist der Anfang.“ Das bedeutet: Beobachten, anreichern, folgern. Ich wollte mit dieser Analogie zu unserer Serie enden.

Teilnehmer 1: Wie geht ihr mit Deduplizierung und Disambiguierung im Graphen bei diesen Vorfällen um?

Renzo Sanchez-Silva: Im Moment lassen wir das LLM in diese offene Welt hinein. Es macht ein Lookup, und es wird die Tripel erstellen und sagen, nein, diese Beziehung existiert bereits, und wir lassen es eine erstellen. Es wird ein Zweig sein, der zusammengeführt werden muss, aber ich lasse es einfach durchlaufen, und es hängt weiter an die Ontologie an.

Möglicherweise kommen wir zu vielen ähnlichen Konzepten. Das haben wir nicht geprüft, aber im Idealfall ist der Prozess bei dieser kleineren Ontologie zum Stillstand gekommen, in dem Sinne, dass sie stabil wird. Ich sehe weniger PRs, die wir zusammenführen müssen und so weiter.

Sie wird letztendlich stabil. Es muss ein Mensch einbezogen werden. Zum Beispiel muss ein Ontologe sich das tatsächlich ansehen und genau prüfen.

Was ich sehe, ist, dass die Deduplizierung sehr kontrolliert verläuft. Das ist möglich.

Prasanna Vijayanathan: In Zukunft sehen wir auch die Notwendigkeit einer Musterextraktionsschicht, die Muster verallgemeinern kann, um bei der Deduplizierung zu helfen. So weit sind wir noch nicht. Wir können damit umgehen.

Teilnehmer 2: In diesen Graphen kann alles mit allem anderen in Beziehung treten. Wie optimiert ihr eure Infrastruktur, um mehr Signal statt Rauschen zu erhalten, sodass die Dinge, die sie ausgibt, tatsächlich nichts Halluziniertes oder nur Möglicherweise Verwandtes sind, sondern tatsächlich umsetzbar, real und ein Signal für den Nutzer sind.

Anand: Wie entfernt man falsche Korrelationen, ist das möglich?

Prasanna Vijayanathan: Wenn man auf alte Testsysteme zurueckblickt, haben wir ein Schweizer-Kaese-Modell. Wir moechten moeglichst genaue und umsetzbare Informationen liefern, und am besten koennte uns das derzeit der Nutzer selbst vermitteln. Wie Renzo erwaehnt hat, erstellt sich das System selbst und heilt sich auch selbst, also existiert das durchaus.

Wir verfolgen verschiedene Qualitaetsmetriken. Wir fuehren Online-Logs durch, ziehen daraus Metriken, und darueber hinaus haben wir evals-Systeme. Das bedeutet, wir frieren unsere Eingaben und Ausgaben ein und testen kontinuierlich, wie unser Modell abschneidet.

Dann haben wir noch Human-in-the-loop-Feedback. All diese Systeme fliessen in unser Modell zurueck, und obwohl wir das bisher noch nicht umfassend getan haben, wird es in irgendeine Form von reinforcement learning münden, um diese Signale zu nutzen und sich selbst zu verbessern.

Teilnehmer 3: Mich interessiert der Aspekt der Skalierung etwas genauer, denn offenbar befindet sich der gesamte Graph in Turtle, erstellt durch Pull Requests wie Code. Das waere dann nur eine kleine Teilmenge dieser 32 Millionen Abfragen pro Sekunde, und diese Elemente beziehen wir nicht aufeinander. Es ist ein viel hoeher abstrahiertes Konstrukt. Ist das richtig?

Renzo Sanchez-Silva: Die Idee ist, dass wir bei diesem hohen Durchsatz lediglich Metadaten erfassen, also Fingerabdruecke dafuer, dass etwas gestartet ist. Wir haben dieses Muster gefunden, aber wir werden nicht die Daten in Turtle bekommen. Das gibt es schlicht nicht. Wir werden den Fingerabdruck dessen erfassen, was geschieht, und das dann mit dem Rest des Graphen in Beziehung setzen. Dabei kontrollieren wir natuerlich stets auch die Kardinalitaet.

Teilnehmerin 4: Wie erkennt ihr, dass etwas Wichtiges nicht geschehen ist, anstatt nur etwas aufzugreifen, das tatsaechlich geschehen ist?

Renzo Sanchez-Silva: Die Ontologien verfuegen tatsaechlich ueber eine sehr leistungsfaehige formale Reasoning-Faehigkeit. Das ist nichts KI-bezogenes. Das ist vielmehr proportionale Logik. Sehr aufwendige Algorithmen, die tatsaechlich schlussfolgern koennen und etwas Inkongruentes, Transitives oder Widerspruechliches aufdecken koennen. Wir planen ausserdem, formales Reasoning einzusetzen, um solche Dinge zu erfassen, waehrend die Vorgaenge laufen. Nicht nur, um Inkonsistenzen in den Daten zu finden, sondern auch, um neue Verbindungen zu entdecken. Wir koennen formales Reasoning ohne KI betreiben, aber wir koennen auch KI nutzen, um dieses grundlegende Reasoning zu unterstuetzen.

Prasanna Vijayanathan: Ein Mensch in der Schleife hilft in diesem System ebenfalls sehr, etwa wenn ein Entwickler etwas bemerkt, das nicht erfasst wurde, oder wenn wir einen Vorfall oder ein Problem feststellen, das tatsaechlich geloest werden musste. Dann schauen wir uns an, warum das System es nicht erkannt hat. Tatsaechlich hatten wir kuerzlich einen Fall, in dem jemand es meldete und fragte, warum wir ihm das nicht mitgeteilt hatten. Daraufhin konnte sich das System selbst korrigieren und ein neues Paar anlegen. Das ist die andere Seite davon.

Teilnehmer 5: Koennen Sie mir sagen, wie haeufig Sie zulassen wuerden, dass sich Ihre Ontologie aendert? Und wie wirkt sich das auf den Neuaufbau Ihres Knowledge Graph aus?

Renzo Sanchez-Silva: Wir lassen es mit der open-world-Annahme laufen. Es scheint stabil zu sein, zumindest bei den Incidents, aber wir werden auch Verbindungen zu Alerts finden. Das ist eine sehr kleine Ontologie, denn alles, was wir erfassen wollen, sind die Metadaten der Alerts.

In einem Alert gibt es zum Beispiel nur sehr wenige Schluesselwoerter oder Konzepte, ebenso bei den Signalen. Bei den anderen, etwa Pipelines und Jobs und so weiter, gibt es ebenfalls eine Moeglichkeit, das zu kontrollieren. Das ist sehr uebersichtlich.

Schwieriger sind die Incidents, weil dort alles moegliche geschehen kann. Die Konzepte nehmen zu, aber wie gesagt, es wird stabil. Irgendwann muss man zurueckschauen, wir muessen das mit Menschen komprimieren, und dann bleibt es kontrolliert.

Wir brauchen definitiv den Menschen in der Schleife.

Teilnehmer 6: Gibt es Plaene fuer ein Open-Sourcing?

15. bis 16. Dezember 2026. Erfahren Sie, wie erfahrene Praktiker agents, evals, Model Serving und KI-unterstuetzte Entwicklung im Produktivbetrieb einsetzen, auch was fehlschlug und sich veraenderte. Jetzt registrieren.