Selbstfahrende Netzwerke brauchen einen Graphen: Kausale Root-Cause-AIOps

Rami Rahim, der das Netzwerkgeschäft von HPE führt, sagt, KI werde innerhalb von zwei bis drei Jahren jedes Netzwerk-Ticket ohne Menschen bearbeiten. Das klingt nach einer Aussage über Erkennung. Es ist in Wahrheit eine Aussage über Zurechnung — und Zurechnung ist ein Graph-Problem.

Die Behauptung ist größer, als sie zunächst klingt

HPEs Zahlen sind alles andere als bescheiden. Rahim beziffert 70–80% der Tickets als bereits ohne Menschen lösbar, mit Steigerung auf „alle" in zwei bis drei Jahren. SDxCentral meldete dieselbe Kurve von HPE-Seite: mehr als 80% der Vorfälle werden entweder vollständig selbst behoben oder sofort mit bekannter Ursache beantwortet — nach etwa 50%, dann 60%, dann 70% in den Jahren zuvor. Kundinnen und Kunden in HPE-Fallstudien berichten von einem Rückgang des Ticketvolumens um über 90%. Das britische Justizministerium wird mit rund 75% weniger Service-Desk-Tickets genannt, nachdem es etwa 15.000 Geräte wieder selbst betrieben hat.

Die Maschinerie hinter diesen Zahlen ist ein Geflecht aus „Marvis"-Assistenten, einem agentischen Framework, das HPE als agentic mesh bezeichnet, und OpsRamp-Observability, die in das Netzwerk-Fabric-Management integriert wurde. Interessant ist nicht die Größe des Modells, sondern worauf es schauen — und worauf es zugreifen darf.

„Das WLAN ist Mist" ist das ganze Problem in drei Worten

Fragen Sie ein beliebiges Netzwerkteam nach seinem häufigsten Ticket, und Sie bekommen irgendeine Variante einer WLAN-Beschwerde. Die Beschwerde gilt dem Erlebnis; der Fehler liegt fast nie im WLAN. Er liegt in einer Anwendung, einer WAN-Strecke, einer Cloud-Region, dem DNS, einem Identity-Provider oder einer ausgelasteten Uplink-Strecke tief hinter dem Access Point. Das Symptom der Nutzerin ist das ferne Ende einer Abhängigkeitskette.

Deshalb ist Erkennung die leichte Hälfte. Jeder Observability-Stack kann tausend Alarme auslösen, wenn eine einzelne Upstream-Strecke degradiert. Was ein Mensch in den nächsten dreißig Sekunden tut — und was ein autonomes System tun muss —, ist, diesen Sturm auf einen einzigen Ursprung zu reduzieren. Das ist kausale Zurechnung, und sie gelingt nur über die Abhängigkeitsstruktur, nicht über die Alarmliste.

Modellieren Sie das Netz als Graph, denn es ist einer

Ein Netzwerk ist bereits ein Graph: Access Points, Switches und Router als Knoten; Links, VLANs, Tunnel und Service-Chains als Kanten; und darüber eine zweite Ebene von Abhängigkeiten — dieser Access Point bedient diese Nutzer, dieser Dienst läuft auf jenem Cluster, diese App hängt an jener API. Gesundheit ist eine Eigenschaft von Knoten und Kanten; ein Fehler ist ein Knoten, der schlecht wird und seine Nachfahren mitreißt.

In diesem Modell wird Fehlerlokalisierung zu einer präzisen Frage: Finde die kleinste Knotenmenge, deren Ausfall die gesamte beobachtete Symptommenge erklärt. Die klassische Formulierung ist ein Bayes-Netz mit Noisy-OR-Gates; die moderne ist ein Graph-Neural-Network über der Topologie oder ein kausaler Graph, bewertet mit do-Kalkül. In jedem Fall ist der Graph das Substrat, und die Antwort ist ein Subgraph — kein Wert auf einem Dashboard.

Eine konkrete HPE-Demo macht die Schleife greifbar. Eine „bad user minutes"-Metrik stieg über 6%. Statt jemanden zu alarmieren, lokalisierte das System die Erlebnis-Regression auf eine Handvoll überlasteter Access Points, aktivierte das Dual-Band-5-GHz-Radio und drückte die Spitzenauslastung von 90% auf 54% — bevor eine einzige Person ein Ticket eröffnete. Erlebnis messen, im Graphen lokalisieren, den lokalisierten Knoten bearbeiten. Das ist das Muster, das sich lohnt zu kopieren, unabhängig vom Anbieter.

Korreliert ist nicht kausal, und Autonomie erhöht den Einsatz

Die Falle ist das Handeln auf Korrelation. Zwei Symptome können sich gemeinsam bewegen, weil ein dritter, verborgener Faktor beide treibt; ein Eingriff an einem der Symptome beruhigt den Alarm und lässt den Fehler stehen. Auf einem Dashboard ist das bloß lästig. Für einen Agenten mit der Befugnis, Konfiguration zu ändern, ist es ein selbstverschuldeter Ausfall, der darauf wartet zu passieren.

Die entscheidende Unterscheidung ist interventionell: Ändert das Setzen von A auf einen neuen Wert das Verhalten von B, oder variieren A und B nur gemeinsam? Genau das kodiert ein kausaler Graph und kann eine Korrelationstabelle nicht. Bevor Sie Autonomie gewähren, sollte der Graph Richtung und Confounding tragen, nicht nur Ko-Auftreten.

Blast Radius ist eine Graph-Traversierung — und die Sicherheitsbremse

Autonomie sollte nach Konsequenz bemessen werden, und Konsequenz ist aus dem Graphen berechenbar. Bevor ein Agent handelt, stellen Sie eine Traversierungsfrage: Was liegt stromabwärts von diesem Knoten? Eine Funk-Timing-Änderung an einem Edge-Access-Point hat einen kleinen Blast Radius. Dieselbe Art Änderung an einer Core-Aggregationsstrecke kann ein Stockwerk offline nehmen.

Das ist die Substanz hinter HPEs „Marvis Trust List", mit der eine Betreiberin einzelne Maßnahmen — einen toten Kamera-Port wiederherstellen, ein fehlendes VLAN reparieren — zur vollautonomen Ausführung freigibt, während alles andere beratend bleibt. Koppeln Sie Autonomie an Blast Radius und Konfidenz, wird aus dem Schalter eine Prinzipienfrage statt eines Vertrauenssprungs. HPEs eigene Formulierung — die Ursache, die erwogenen Optionen und den Grund der Wahl zeigen, mit Verantwortung, die bei der IT bleibt — ist eine Vertrauens-Schnittstelle auf demselben Graphen.

// Aus einer Symptommenge Kandidaten für die Ursache finden, nach Blast Radius bewertet.
MATCH (s:Symptom) WHERE s.id IN $symptomIds
MATCH (s)<-[:CAUSES*1..4]-(cause:Node)
WITH cause, count(DISTINCT s) AS explained
MATCH (cause)-[:UPSTREAM_OF*1..6]->(affected:Node)
RETURN cause.name              AS kandidat,
       explained               AS erklaerteSymptome,
       count(DISTINCT affected) AS blastRadius
ORDER BY erklaerteSymptome DESC, blastRadius ASC
LIMIT 5

Die CAUSES-Kanten müssen aus einem kausalen Modell stammen — einem Injektionsexperiment, einem topologiebewussten Simulator oder historischer Zurechnung — nicht aus roher Ko-Okkurrenz, sonst zerfällt das Ranking zu „welcher Alarm am lautesten feuerte".

Wo die 100%-Behauptung auf Reibung stoßen wird

Drei Fehlermodi verdienen Ehrlichkeit.

• Veraltete Topologie. Ein Graph ist nur so gut wie seine Aktualität. Driftet das Abhängigkeitsmodell von der Realität ab, zeigt die Zurechnung auf einen Knoten, den es nicht mehr gibt, oder verpasst einen, der letzte Woche hinzukam.
• Dünne Domänen. Die leichten 80% sind vertraute, gut instrumentierte Fehler. Die letzten 20% sind neuartig, domänenübergreifend und genau dort, wo der Graph am dünnsten und die Trainingsdaten abwesend sind.
• Auto-Remediation ohne Radius-Grenze. Der schädlichste Vorfall, den ein autonomes Netzwerk haben kann, ist die Änderung, die es selbst vorgenommen hat. Begrenzen Sie jede Aktion durch Blast Radius und einen getesteten Rollback.

Fazit

HPE hat wahrscheinlich recht, dass die meisten Tickets maschinell bearbeitet werden — nicht weil Modelle besser darin wurden, Alarme zu lesen, sondern weil das Netzwerk ein Graph ist und der Graph die richtige Frage stellbar macht: Welcher Knoten erklärt, wenn er gestört wird, alles, was gerade sichtbar ist, und was passiert, wenn wir ihn anfassen? Verdrahten Sie Topologie- und Abhängigkeitsdaten zu einem kausalen Graphen, den Sie traversieren können, hängen Sie jede automatisierte Aktion an einen Blast Radius, und halten Sie bei den wichtigen Aktionen einen Menschen im Boot. Erkennung kann man kaufen. Zurechnung ist der Teil, den Sie modellieren müssen.