← Neueste Arbeiten
🤖 AI

The Abstention Protocol: RCA for Clos Fabrics

Dieses Paper stellt CoreSec vor, ein Produktionssystem zur Ursachenanalyse für groß angelegte Clos-Fabrics, das instabile score-basierte Fusion durch eine deterministische PAM-ähnliche Abstentions-Algebra ersetzt, um eine stabile, erklärbare und monotone Fehlerattribution in verrauschten Telemetrieumgebungen zu erreichen.

Ursprüngliche Autoren: Madhava Gaikwad, Deepak Pandey

Veröffentlicht 2026-08-25
📖 6 Min. Lesezeit🧠 Tiefgang

Ursprüngliche Autoren: Madhava Gaikwad, Deepak Pandey

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

In der gewaltigen, summenden Architektur des modernen Cloud-Computings fließt der Datenstrom nicht durch ein einzelnes Rohr, sondern durch ein weit verzweigtes, vielschichtiges Geflecht von Verbindungen. Stellen Sie sich eine Stadt vor, in der jedes Gebäude mit einem lokalen Nachbarschafts-Switch verbunden ist, der wiederum mit einem Distrikt-Hub verbunden ist, welcher schließlich mit einer zentralen Wirbelsäule verknüpft wird. Diese Struktur, bekannt als Clos-Fabric, ermöglicht es Millionen von Servern, mit unglaublicher Geschwindigkeit und Redundanz miteinander zu kommunizieren. Wenn ein Pfad blockiert ist, findet der Verkehr einfach einen anderen Weg. Aufgrund dieses Designs ist das System unglaublich belastbar; es kann täglich tausende winziger, zufälliger Störungen absorbieren – wie ein loses Kabel, ein flackerndes Licht oder ein kurzes Software-Hickup – ohne dass der durchschnittliche Nutzer dies jemals bemerkt. Doch dieses ständige Hintergrundrauschen schafft ein tiefgreifendes Problem für die Ingenieure, die das System am Laufen halten. Wenn ein bestimmter Dienst für einen Kunden ausfällt, leuchtet das System mit Hunderten von Warnmeldungen auf. Die Herausforderung besteht nicht darin, die defekten Teile zu finden, sondern herauszufinden, welches dieser vielen defekten Teile tatsächlich den spezifischen Ausfall verursacht hat.

Jahrelang war der Standardweg, um dieses Rätsel zu lösen, jedem Warnsignal einen Score zuzuweisen. Wenn ein Kabel eine hohe Fehlerrate aufwies, erhielt es einen hohen Score. Wenn ein Switch neu startete, erhielt er einen Score. Das System addierte diese Scores auf, und die Entität mit der höchsten Gesamtsumme wurde für das Problem verantwortlich gemacht. Dieser Ansatz funktionierte gut genug, wenn das Netzwerk ruhig war, aber in einer Hyperscale-Umgebung versagte er oft. Da es immer ein gewisses Hintergrundrauschen gibt, fand das System häufig einen „Schuldigen“, selbst wenn eigentlich nichts wirklich falsch war, oder es beschuldigte das falsche Gerät, weil die Scores zu nah beieinander lagen, um sie zu unterscheiden. Die Ingenieure stellten fest, dass der Versuch, diese Scores fein abzustimmen, um einen bestimmten Fehlertyp zu beheben, versehentlich die Fähigkeit des Systems beeinträchtigte, einen anderen Typ zu erfassen. Das Ergebnis war ein Kreislauf der Unsicherheit, in dem automatisierte Korrekturen manchmal durch Fehlalarme ausgelöst wurden, was die Situation eher verschlimmerte als verbesserte.

Um dies zu lösen, entwickelte ein Team bei Microsoft ein neues System namens CoreSec, das die grundlegende Logik verändert, wie diese Entscheidungen getroffen werden. Anstatt Scores aufzusummieren, behandelt das neue System die Untersuchung wie eine Serie strenger, unabhängiger Prüfungen, ähnlich der Art und Weise, wie ein Sicherheitssystem die Identität einer Person verifiziert. In einem Hochsicherheitsgebäude könnte ein Wachmann ein Passwort, einen Fingerabdruck und eine Schlüsselkarte verlangen. Wenn das Passwort fehlt, rät der Wachmann nicht; er verweigert einfach den Zutritt und stoppt den Prozess. CoreSec wendet diese „Abstentionslogik“ (Enthaltungslogik) auf Netzwerkausfälle an. Es weist verschiedenen Arten von Daten spezifische Rollen zu. Einige Signale sind obligatorisch: Wenn ein kritisches Beweisstück fehlt oder veraltet ist, weigert sich das System, eine Entscheidung zu treffen. Andere Signale sind für sich genommen ausreichend: Wenn ein spezifischer, unbestreitbarer Fehler gefunden wird, stoppt das System die Suche und benennt den Grund sofort.

Das System führt fünf verschiedene Untersuchungen parallel durch, die jeweils eine andere Schicht des Netzwerks betrachten, von den einzelnen Kabeln, die die Server verbinden, bis hin zu den massiven Spine-Switches, die das gesamte Fabric zusammenhalten. Jede Untersuchung nutzt ihren eigenen Satz von Regeln, um zu entscheiden, ob sie genügend Beweise hat, um für eine bestimmte Ursache zu stimmen. Wenn die Beweislage klar ist, stimmt sie ab. Wenn die Beweise fehlen oder widersprüchlich sind, enthält sie sich. Dies ist ein entscheidender Wandel. Im alten System war der Computer gezwungen, einen Gewinner zu wählen, selbst wenn er die Antwort nicht wusste. Im neuen System ist das Eingestehen von Unwissenheit ein valider und nützlicher Ausgang. Wenn sich das System enthält, sagt es den menschlichen Ingenieuren: „Ich bin mir noch nicht sicher“, und übergibt den Fall mit einer klaren Zusammenfassung dessen, welche Daten fehlten. Dies verhindert, dass das System selbstbewusste, aber falsche Vermutungen anstellt, die unnötige und potenziell schädliche automatische Reparaturen auslösen könnten.

Sob-gleich die fünf parallelen Untersuchungen abgeschlossen sind, tritt eine zweite Logikschicht ein, um deren Ergebnisse zu kombinieren. Diese Logik versteht die physische Form des Netzwerks. Sie weiß, dass der Ausfall eines einzelnen Switches zwar einige Server betreffen kann, aber der Ausfall eines höher gelegenen Hubs eine Kettenreaktion auslöst, die viele darunter liegende Switches gleichzeitig „krank“ aussehen lässt. Das System verwendet einfache, fest verdrahtete Regeln, um zu entscheiden, welche Ebene tatsächlich verantwortlich ist. Wenn beispielsweise ein High-Level-Switch vermutet wird, prüft das System, ob mindestens zwei Drittel der an ihn angeschlossenen kleineren Switches ebenfalls Probleme aufweisen. Wenn dies der Fall ist, schließt das System auf den High-Level-Switch als eigentliche Ursache und ignoriert die einzelnen Switches darunter. Dies verhindert, dass sich das System von den Symptomen ablenken lässt und die falsche Ebene des Netzwerks beschuldigt.

Die Ergebnisse des Einsatzes dieses Systems in über sechzig Regionen der Azure-Cloud sind beeindruckend. Im Laufe von drei Jahren verarbeitete das System mehr als 700.000 Vorfälle. Die Rate der Fehlalarme, bei denen das System ein gesundes Gerät beschuldigte, sank von fast zwanzig Prozent auf weniger als ein Prozent. Gleichzeitig stieg die Anzahl der Fälle, in denen das System das Problem korrekt identifizierte, ohne menschliche Hilfe zu benötigen, signifikant an. Vielleicht am wichtigsten ist, dass das System die Notwendigkeit eliminierte, drei Vollzeit-Ingenieure einzusetzen, die jeden Vorfall manuell überprüfen und widersprüchliche Daten abgleichen mussten. Die Ingenieure, die früher Stunden damit verbrachten, diese Knoten zu entwirren, erhalten nun einen klaren, strukturierten Bericht, der ihnen genau sagt, was das System gefunden hat, was es nicht entscheiden konnte und wo sie als Nächstes suchen sollten.

Der Erfolg von CoreSec liegt in seiner Weigerung zu raten. Indem es die Fusion verschiedener Datenquellen als ein Kompositionsproblem statt als ein Scoring-Spiel behandelt, erreicht das System eine Stabilität, die zuvor unmöglich war. Es verlässt sich nicht auf komplexe Machine-Learning-Modelle, die ihr Verhalten ändern könnten, wenn sich das Netzwerk weiterentwickelt. Stattdessen nutzt es einen festen Satz logischer Regeln, die sich ohne Neukalibrierung über verschiedene Hardware, unterschiedliche Verkehrsmuster und verschiedene Datacenter-Designs hinweg bewährt haben. Das System hat gezeigt, dass in einer Welt voller verrauschter, unvollständiger Informationen das mächtigste Werkzeug oft die Fähigkeit ist, zu sagen: „Ich weiß es nicht“, und auf bessere Beweise zu warten. Dieser Ansatz hat die Ursachenanalyse von einem Spiel der Wahrscheinlichkeit in einen zuverlässigen, erklärbaren Prozess verwandelt, der es der Cloud ermöglicht, stabil zu bleiben, auch während sie immer größer und komplexer wird.

Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?

Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.

Digest testen →