In de uitgestrekte, zoemende architectuur van moderne cloud computing stroomt data niet door één enkele pijp, maar door een uitgespreid, meerlagig web van verbindingen. Stel je een stad voor waar elk gebouw is verbonden met een lokale buurt-switch, die op zijn beurt verbonden is met een districtshub, die uiteindelijk verboudigt met een centrale ruggengraat. Deze structuur, bekend als een Clos-fabric, stelt miljoenen servers in staat om met ongelooflijke snelheid en redundantie met elkaar te communiceren. Als één pad geblokkeerd is, vindt het verkeer simpelweg een andere weg. Dankzij dit ontwerp is het systeem ongelooflijk veerkrachtig; het kan duizenden kleine, willekeurige storingen per dag absorberen—zoals een losse kabel, een flikkerend lichtje of een korte softwarefout—zonder dat de gemiddelde gebruiker dit ooit merkt. Echter, deze constante achtergrondruis creëert een diepgaand probleem voor de engineers die het systeem draaiende houden. Wanneer een specifieke dienst voor een klant faalt, licht het systeem op met honderden waarschuwingen. De uitdaging is niet het vinden van de kapotte onderdelen, maar uitzoeken welk van die vele kapotte onderdelen daadwerkelijk de specifieke uitval heeft veroorzaakt.

Jarenlang was de standaardmanier om dit puzzelstuk op te lossen het toekennen van een score aan elk waarschuwingssignaal. Als een kabel een hoog foutenaantal had, kreeg deze een hoge score. Als een switch opnieuw opstartte, kreeg deze een score. Het systeem telde deze scores bij elkaar op, en de entiteit met de hoogste totaalscore kreeg de schuld van de problemen. Deze aanpak werkte goed genoeg wanneer het netwerk rustig was, maar in een hyperscale omgeving faalde het vaak. Omdat er altijd wel wat achtergrondruis is, vond het systeem regelmatig een "dader" zelfs wanneer er niets echt mis was, of gaf het de schuld aan het verkeerde apparaat omdat de scores te dicht bij elkaar lagen om te kunnen onderscheiden. De engineers ontdekten dat het finetunen van deze scores om één type fout te verhelpen, per ongeluk de capaciteit van het systeem om een ander type fout te detecteren, ondermijnde. Het resultaat was een cyclus van onzekerheid, waarbij geautomatiseerde reparaties soms werden getriggerd door valse alarmen, wat de situatie eerder verslechterde dan verbeterde.

Om dit op te lossen, ontwikkelde een team bij Microsoft een nieuw systeem genaamd CoreSec, dat de fundamentele logica van hoe deze beslissingen worden genomen, verandert. In plaats van scores bij elkaar op te tellen, behandelt het nieuwe systeem het onderzoek als een reeks strikte, onafhankelijke controles, vergelijkbaar met hoe een beveiligingssysteem de identiteit van een persoon verifieert. In een beveiligd gebouw kan een bewaker bijvoorbeeld een wachtwoord, een vingerafdruk en een toegangskaart vereisen. Als het wachtwoord ontbreekt, raadt de bewaker niet; hij weigert simpelweg toegang en stopt het proces. CoreSec past deze "onthoudingslogica" toe op netwerkstoringen. Het wijst specifieke rollen toe aan verschillende soorten data. Sommige signalen zijn verplicht: als een cruciaal stuk bewijs ontbreend of verouderd is, weigert het systeem een beslissing te nemen. Andere signalen zijn op zichzelf voldoende: als er een specifieke, onomstotelijke fout wordt gevonden, stopt het systeem met zoeken en benoemt het direct de oorzaak.

Het systeem voert vijf verschillende onderzoeken parallel uit, die elk naar een andere laag van het netwerk kijken, van de individuele kabels die servers verbinden tot de enorme spine-switches die de hele fabric bij elkaar houden. Elk onderzoek gebruikt zijn eigen set regels om te beslissen of het genoeg bewijs heeft om voor een specifieke oorzaak te stemmen. Als het bewijs duidelijk is, stemt het. Als het bewijs ontbreekt of tegenstrijdig is, onthoudt het zich. Dit is een cruciale verschuiving. In het oude systeem werd de computer gedwongen om een winnaar te kiezen, zelfs als hij het antwoord niet wist. In het nieuwe systeem is het toegeven van onwetendheid een geldige en nuttige uitkomst. Wanneer het systeem zich onthoudt, vertelt het de menselijke engineers: "Ik weet het nog niet zeker," en draagt het de zaak aan hen over met een heldere samenvatting van welke data ontbrak. Dit voorkomt dat het systeem zelfverzekerde maar foutieve gissingen doet die onnodige en potentieel schadelijke automatische reparaties kunnen triggeren.

Zodra de vijf parallelle onderzoeken zijn voltooid, komt er een tweede laag logica kijken om de resultaten te combineren. Deze logica begrijpt de fysieke vorm van het netwerk. Het weet dat als een enkele switch uitvalt, dit een paar servers kan beïnvloeden, maar als een hoger gelegen hub uitvalt, zal dit een rimpeleffect veroorzaken waardoor veel kleinere switches tegelijkertijd "ziek" lijken. Het systeem gebruikt eenvoudige, hardcoded regels om te beslissen welke laag werkelijk verantwoordelijk is. Bijvoorbeeld, als een hogere niveau switch wordt verdacht, controleert het systeem of ten minste twee derde van de kleinere switches die ermee verbonden zijn ook problemen vertonen. Als dat het geval is, concludeert het systeem dat de hogere niveau switch de hoofdoorzaak is en negeert het de individuele switches daaronder. Dit voorkomt dat het systeem wordt afgeleid door de symptomen en het verkeerde niveau van het netwerk de schuld geeft.

De resultaten van het implementeren van dit systeem in meer dan zestig regio's van de Azure cloud zijn opmerkelijk. Gedurende een periode van drie jaar verwerkte het systeem meer dan 700.000 incidenten. Het percentage valse alarmen, waarbij het systeem een gezond apparaat de schuld gaf, daalde van bijna twintig procent naar minder dan één procent. Tegelijkertijd nam het aantal keren dat het systeem het probleem correct identificeerde zonder menselijke hulp aanzienlijk toe. Misschien wel het belangrijkste is dat het systeem de noodzaak geëlimineerd heeft voor drie fulltime engineers om bij elk incident handmatig gegevens te beoordelen en tegenstrijdigheden te verzoenen. De engineers die vroeger uren besteedden aan het ontwarren van deze knopen, ontvangen nu een helder, gestructureerd rapport dat hen precies vertelt wat het systeem heeft gevonden, wat het niet kon beslissen en waar ze verder moeten kijken.

Het succes van CoreSec ligt in het weigeren om te gissen. Door de fusie van verschillende databronnen te behandelen als een compositieprobleem in plaats van een scorengame, bereikt het systeem een niveau van stabiliteit dat voorheen onmogelijk was. Het vertrouwt niet op complexe machine learning-modellen die hun gedrag kunnen veranderen naarmate het netwerk evolueert. In plaats daarvan gebruikt het een vaste set logische regels die bewezen hebben te werken over verschillende hardware, verschillende verkeerspatronen en verschillende datacenterontwerpen zonder dat ze opnieuw afgesteld hoeven te worden. Het systeem heeft aangetoond dat in een wereld van ruisige, onvolledige informatie, het krachtigste instrument vaak het vermogen is om te zeggen: "Ik weet het niet," en te wachten op beter bewijs. Deze aanpak heeft root cause analysis getransformeerd van een spel van waarschijnlijkheid naar een betrouwbaar, verklaarbaar proces, waardoor de cloud stabiel kan blijven terwijl deze groter en complexer blijft groeien.