Mean Time to Innocence: So beweisen Sie, dass es nicht am WiFi liegt

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und lockeren Ton - so wie ein erfahrener Netzwerkberater, der einen Kunden bei einem Kaffee informiert. Gemäßigtes Tempo, klare Aussprache, gelegentlicher trockener Humor. Kein Vortrag. Kein Verkaufsgespräch. Einfach Klartext von jemandem, der dieses Problem schon hundertmal gesehen hat: Willkommen beim technischen Briefing von Purple. Ich werde heute mit Ihnen über etwas sprechen, das jeder Netzwerkmanager im Urinstinkt spürt, selbst wenn er den offiziellen Begriff dafür noch nie gehört hat. Mean Time to Innocence. Oder MTTI. [kurze Pause] Die Zeit, die Sie damit verbringen, zu beweisen, dass es nicht Ihre Schuld ist. Hier ist das Szenario. Es ist neun Uhr morgens. Die Bewohner eines Mietshauses rufen an der Rezeption an. Das WiFi ist kaputt. Der Hausverwalter ruft den Managed WiFi Anbieter an. Der Managed WiFi Anbieter ruft den ISP an. Der ISP sagt, prüfen Sie den Router. Das Router-Team sagt, prüfen Sie die Access Points. Der Access-Point-Hersteller sagt, prüfen Sie die Client-Geräte. Und irgendwo in der Mitte von all dem sind fünfundvierzig Minuten vergangen, und niemand hat tatsächlich etwas repariert. Das genau ist Mean Time to Innocence in Aktion. [kurze Pause] Und es kostet Sie mehr, als Sie denken. Lassen Sie mich das richtig definieren. Mean Time to Innocence ist die durchschnittliche Zeitspanne zwischen dem Erkennen eines Problems und dem Zeitpunkt, an dem ein bestimmtes Team mit Beweisen nachweisen kann, dass sein Bereich nicht die Ursache ist. Es ist nicht dasselbe wie die Mean Time to Identify, die die unternehmensweite Metrik für das Finden der tatsächlichen Ursache ist. MTTI ist isoliert. Es ist persönlich. Es ist das Netzwerkteam, das sagt: Hier sind die Daten, wir sind es nicht, sucht woanders. Das Problem ist, dass dieser Nachweis ohne die richtigen Tools Zeit kostet. Und jede Minute MTTI ist eine Minute, die direkt zu Ihrer Mean Time to Resolution, Ihrer MTTR, hinzugerechnet wird. Die beiden sind untrennbar miteinander verbunden. Warum wird also dem WiFi immer zuerst die Schuld gegeben? [kurze Pause] Drei Gründe. Erstens: WiFi ist sichtbar. Wenn etwas kaputt geht, schauen die Leute auf das, was sie sehen können, und die WiFi Signalbalken auf ihrem Telefon sind der sichtbarste Indikator für Konnektivität. Zweitens: WiFi ist der letzte Hop vor dem Gerät, also ist es das Erste, das verdächtig aussieht, wenn ein Gerät das Internet nicht erreichen kann. Drittens - und das ist der unangenehme Teil - können WiFi Teams ihre Unschuld oft nicht schnell beweisen, weil ihnen die passende Telemetrie fehlt. Wenn Sie den einwandfreien Zustand der Funkschicht nicht in weniger als zwei Minuten nachweisen können, werden Sie die nächste Stunde damit verbringen, sich selbst zu verteidigen. In einer Single-Tenant-Unternehmensumgebung ist das lästig. In einer Multi-Tenant-Umgebung ist es jedoch absolut geschäftsschädigend. Denken Sie an ein Hotel wie Premier Inn, ein Mietwohnungsgebäude oder ein Konferenzzentrum, in dem eine Veranstaltung nach der anderen stattfindet. Sie haben einen Objektmanager, dem das Netzwerk nicht gehört. Sie haben Bewohner oder Gäste, die das Netzwerk nicht verstehen. Und Sie haben einen Managed-WiFi-Anbieter, der für die Wireless-Ebene verantwortlich ist, aber nicht für die ISP-Leitung, nicht für die Gebäudeverkabelung und nicht für die Endgeräte. Wenn etwas nicht funktioniert, gibt der Objektmanager dem WiFi-Anbieter die Schuld, weil das der Vertragspartner ist, an den er sich halten kann. Der Bewohner gibt dem Gebäude die Schuld, weil er dorthin seine Miete zahlt. Und der WiFi-Anbieter muss das Netzwerk schnell entlasten, da sonst die Beziehung leidet. [kurze Pause] MTTI ist in diesem Zusammenhang nicht nur eine technische Kennzahl. Es ist eine kommerzielle. Sprechen wir also über die Methodik, die diese Zeit tatsächlich verkürzt. Es gibt fünf Ebenen, und Sie benötigen alle fünf. Ebene eins: kontinuierliche synthetische Tests. Noch bevor ein Ticket erstellt wird, sollten automatisierte Prüfungen direkt über das Netzwerk laufen, um die DNS-Auflösung, die HTTP-Erreichbarkeit, die Latenz zu bekannten Endpunkten und die Authentifizierungsabläufe zu testen. Tools wie Juniper Mist's Marvis oder die in Plattformen wie ThousandEyes integrierten synthetischen Tests führen diese Prüfungen alle paar Minuten durch. Wenn ein Vorfall auftritt, können Sie ein Diagramm aufrufen und genau zeigen, wann die WiFi-Ebene das letzte Mal eine fehlerfreie synthetische Prüfung hatte und ob sie zum Zeitpunkt der Beschwerde einwandfrei oder beeinträchtigt war. Das allein verkürzt die MTTI drastisch, da Sie entweder bestätigen, dass das WiFi funktionierte, oder dass dies nicht der Fall war - und Sie beenden die Diskussion darüber. Ebene zwei: Hop-by-Hop-Pfadtransparenz. Hier scheitern die meisten Teams. Sie können beweisen, dass der Access Point einwandfrei funktioniert. Sie können beweisen, dass der Switch einwandfrei funktioniert. Aber können Sie beweisen, dass der Pfad vom Switch bis zur ISP-Übergabe einwandfrei ist? In einem Multi-Tenant-Gebäude gibt es oft Hops, die Ihnen nicht gehören. Das Verteilernetz im Gebäude, der Core-Switch des Vermieters, der Demarkationspunkt zum ISP. Sie benötigen Pfad-Traceroute-Daten, die diese Grenzen überschreiten. Nicht nur einen Ping an acht-acht-acht-acht. Eine echte Traceroute-Transparenz, die Ihnen jeden Hop, seine Latenz und eventuelle Paketverluste anzeigt. Wenn Sie zeigen können, dass die Hops eins bis vier einwandfrei sind und Hop fünf, der Edge-Router des ISP, vierzig Prozent Paketverlust aufweist, ändert sich das Gespräch sofort. Ebene drei: Flow-Daten mit On-Demand-Paketerfassung. NetFlow und IPFIX bieten Ihnen eine Ansicht auf Konversationsebene darüber, wer im Netzwerk womit kommuniziert. Wenn ein Bewohner sagt, dass der Streaming-Dienst nicht funktioniert, zeigen Ihnen die Flow-Daten, ob der Datenverkehr zu den IP-Bereichen dieses Dienstes das Netzwerk überhaupt verlässt. Wenn er das Netzwerk sauber verlässt und das Problem dahinter liegt, haben Sie Ihren Beweis. Wenn er das Netzwerk überhaupt nicht verlässt, wissen Sie, wo Sie suchen müssen. Die On-Demand-Paketerfassung, die auf Plattformen wie Cisco Meraki und HPE Aruba verfügbar ist, ermöglicht es Ihnen, eine gezielte Erfassung für einen bestimmten Client oder ein bestimmtes VLAN durchzuführen, ohne die Hardware zu berühren. Das ist Ihre forensische Ebene. Sie nutzen sie sparsam, aber wenn Sie sie brauchen, ist sie definitiv. Ebene vier: Topologie- und Abhängigkeitszuordnung. In einer mandantenfähigen Umgebung benötigen Sie eine Live-Karte, die zeigt, welche Access Points welche Mandanten bedienen, mit welchen Switches diese APs verbunden sind, welche Uplinks diese Switches nutzen und welche ISP-Leitung jeden Uplink bedient. Wenn ein Vorfall auftritt, können Sie den Schadensradius sofort bestimmen. Betrifft dies einen Mandanten oder alle Mandanten? Eine Etage oder das gesamte Gebäude? Ein VLAN oder alle VLANs? Diese Frage zur Eingrenzung, die in dreißig Sekunden anhand einer Topologiekarte beantwortet werden kann, zeigt Ihnen, ob das Problem in der WiFi Ebene, im Gebäudenetzwerk oder im WAN liegt. Sie sagt Ihnen auch, wen Sie noch einbeziehen müssen und wen Sie sofort ausschließen können. Ebene fünf: Ereigniskorrelation. Dies ist der Teil, der alles miteinander verbindet. Änderungsprotokolle, ISP-Wartungsmeldungen, Geräte-Firmware-Updates, Stromereignisse und Benutzerbeschwerden müssen alle auf derselben Zeitachse liegen. Wenn Sie eine Spitze bei den Verbindungsfehlern von Clients mit einem Firmware-Push überlagern, der zwölf Minuten zuvor stattgefunden hat, haben Sie Ihre Ursache. Wenn Sie eine Latenzspitze mit einem ISP-Wartungsfenster überlagern, das Ihnen nicht mitgeteilt wurde, haben Sie Ihren Beweis für die Eskalation. Ereigniskorrelation ist nicht glamourös, aber sie macht den Unterschied zwischen einem 45-minütigen Schuldzuweisungsspiel und einer Entlastung in vier Minuten aus. Nun noch ein Wort zur kulturellen Dimension, denn hier machen viele Teams Fehler. Das Ziel bei der Reduzierung der MTTI ist nicht, das Schuldzuweisungsspiel schneller zu gewinnen. Es geht darum, das Schuldzuweisungsspiel ganz zu beenden. [kurze Pause] Gemeinsame Beweise verändern die Dynamik. Wenn der WiFi Anbieter dem Property Manager einen Link zu einem Dashboard senden kann, das Grün auf der Wireless-Ebene, Gelb auf dem gebäudeinternen Switch und Rot auf der ISP-Leitung anzeigt, ist das Gespräch nicht mehr konfrontativ. Es wird kollaborativ. Der Property Manager ruft den ISP an. Der ISP repariert die Leitung. Die Bewohner haben wieder Verbindung. Und der Vertrag des WiFi Anbieters wird verlängert, weil er derjenige war, der das Problem gefunden hat. Das ist das kommerzielle Argument für die Investition in Observability-Tools. Nicht nur eine schnellere Fehlerbehebung, sondern bessere Beziehungen zu den Menschen, die Sie bezahlen. Lassen Sie mich kurz zwei Szenarien durchgehen, um dies konkret zu machen. Szenario eins: ein Hotel mit 350 Zimmern. Gäste in einer Unterkunft im Stil von Premier Inn melden, dass das WiFi auf den Zimmern langsam ist. Die Rezeption erstellt ein Ticket beim Managed WiFi Provider. Durch die Ausführung synthetischer Tests kann der Anbieter sehen, dass die DNS-Auflösungszeiten um sieben Uhr dreiundvierzig morgens von zwölf Millisekunden auf vierhundert Millisekunden angestiegen sind. Die WiFi-Ebene ist stabil. Die Pfadverfolgung zeigt, dass die Latenz beim dritten Hop entsteht, dem Aggregations-Router des ISP. Der Anbieter sendet dem Hotelmanager einen Screenshot der Pfadverfolgung, auf dem der beeinträchtigte Hop rot markiert ist, zusammen mit dem Diagramm des synthetischen Tests, das zeigt, dass die WiFi-Ebene durchgehend fehlerfrei war. Der ISP wird kontaktiert. Der ISP bestätigt ein Routing-Problem auf seiner Seite. Gesamtzeit von der Beschwerde bis zur Entlastung der WiFi-Ebene: sechs Minuten. MTTR für den gesamten Vorfall: zweiundzwanzig Minuten, da die Behebung durch den ISP sechzehn Minuten dauerte. Ohne die Observability-Tools hätte diese sechsminütige Entlastung vierzig Minuten Hin und Her bedeutet, und die MTTR hätte über eine Stunde betragen. Szenario zwei: eine Einzelhandelskette. Ein nationaler Einzelhändler mit WiFi in zweihundert Filialen stellt fest, dass die Point-of-Sale-Terminals in einer Region zeitweise die Verbindung zum Zahlungsabwickler verlieren. Die Schuld wird sofort dem Netzwerkteam zugeschoben. Flow-Daten zeigen, dass der Datenverkehr zum IP-Bereich des Zahlungsabwicklers das Filialnetzwerk fehlerfrei verlässt. Das Problem liegt nicht am Netzwerk. Eine Paketerfassung im Zahlungsabwickler-VLAN zeigt einen sprunghaften Anstieg von TCP-Neuübertragungen, was auf ein serverseitiges Problem beim Zahlungsabwickler hindeutet. Das Netzwerkteam teilt die Flow-Daten und die Erfassungszusammenfassung mit dem Support-Team des Zahlungsabwicklers. Der Zahlungsabwickler identifiziert einen falsch konfigurierten Load-Balancer auf seiner Seite. Die MTTI des Netzwerkteams: acht Minuten. Die Behebungszeit des Zahlungsabwicklers: fünfunddreißig Minuten. Ohne die Flow-Daten hätte das Netzwerkteam diese fünfunddreißig Minuten damit verbracht, VLANs neu bereitzustellen und Switches neu zu starten, die einwandfrei funktionierten. Gut. Lassen Sie mich Ihnen die Schnelldurchlauf-Version der wichtigsten Fragen geben, die mir zu diesem Thema gestellt werden. Liegt es am WiFi oder am Gerät? Führen Sie einen synthetischen Test direkt vom AP aus. Wenn der AP das Internet fehlerfrei erreichen kann und das Gerät nicht, liegt es am Gerät. Wenn der AP das Internet nicht erreichen kann, liegt das Problem vor dem Gerät. Liegt es am WiFi oder am ISP? Führen Sie eine Pfadverfolgung zum Internet durch. Wenn die Latenz oder der Paketverlust an einem Hop außerhalb Ihrer Netzwerkgrenze entsteht, liegt es am ISP. Was ist der Unterschied zwischen MTTI und Mean Time to Identify? MTTI ist die Zeit, die Ihr Team benötigt, um seine Unschuld zu beweisen. Mean Time to Identify ist die Zeit, die das Unternehmen benötigt, um den tatsächlichen Verursacher zu finden. MTTI ist eine Teilmenge der Mean Time to Identify. Wie reduziere ich die MTTI, ohne neue Tools zu kaufen? Beginnen Sie mit dem, was Sie bereits haben. Die meisten Enterprise-Access-Point-Plattformen, einschließlich Cisco Meraki, HPE Aruba und Juniper Mist, verfügen über integrierte synthetische Tests und Client-Diagnosen. Nutzen Sie diese. Dokumentieren Sie Ihre Topologie. Erstellen Sie ein gemeinsames Dashboard, das der Objektleiter oder das Betriebsteam einsehen kann. Transparenz ist das kostengünstigste Tool zur MTTI-Reduzierung, das es gibt. Zusammenfassend lässt sich sagen: Die Mean Time to Innocence ist die versteckte Steuer für jeden Netzwerkvorfall. In Multi-Tenant-Umgebungen, in denen die Verantwortung auf Anbieter, Vermieter und ISPs aufgeteilt ist, ist dies die Kennzahl, die darüber entscheidet, ob Sie Verträge behalten oder verlieren. Die Methodik zu ihrer Reduzierung ist nicht kompliziert: synthetische Prüfungen, Pfadsichtbarkeit, Flussdaten, Topologie-Mapping und Event-Korrelation. Das Ziel ist nicht, das Schuldzuweisungsspiel zu gewinnen. Es geht darum, das Schuldzuweisungsspiel durch gemeinsame Beweise zu ersetzen, damit sich jedes Team auf die Behebung des Problems konzentrieren kann, anstatt das eigene Revier zu verteidigen. [kurze Pause] Denn jede Minute, die mit dem Nachweis der Unschuld verbracht wird, ist eine Minute mehr, die Ihre Bewohner, Gäste oder Käufer ohne Verbindung verbringen. Und das ist die Zahl, auf die es wirklich ankommt. Vielen Dank fürs Zuhören. Wenn Sie sehen möchten, wie die Multi-Tenant WiFi Plattform von Purple diese Art von Observability-Daten in über 80.000 Live-Standorten bereitstellt, besuchen Sie purple.ai.