Ist es Zscaler oder das WLAN? Root-Cause-Analyse in Minuten

Ein Teams-Call ruckelt, und der erste Satz im Ticket lautet fast immer gleich: „Das liegt bestimmt an Zscaler." Oft stimmt das nicht. Doch das Gegenteil zu beweisen kostet den Helpdesk Stunden. Es geht schneller.

Die Szene kennt jedes IT-Team. Ein Mitarbeitender ruft an, der Videocall stockt, die Cloud-App lädt zäh. Weil Zscaler als Sicherheits-Layer inline im Datenstrom sitzt und den gesamten Verkehr prüft, ist es das sichtbarste Element der Kette, und damit der erste Verdächtige. Der Reflex „es ist Zscaler" ist verständlich, aber er ist eine Vermutung, keine Diagnose.

In der Realität ist die Ursache genauso oft ein überlastetes Heim-WLAN, eine schwächelnde ISP-Strecke, ein CPU-lastiges Notebook oder eine Anwendung, die selbst gerade Probleme hat. Nur: Das muss der Helpdesk erst mühsam nachweisen. Und bis der Nachweis steht, hängt der Verdacht am Sicherheits-Gateway, das objektiv gar nichts falsch macht.

Warum die Schuldfrage so teuer ist

Der klassische Ablauf frisst Zeit an mehreren Stellen gleichzeitig. Der First-Level nimmt das Ticket auf, kann die Netzwerkkette aber nicht selbst einsehen und eskaliert. Der Second-Level öffnet mehrere Konsolen: das ZDX-Dashboard, vielleicht ein separates Netzwerk-Monitoring, die Geräteinventarisierung. Er korreliert Zeitstempel von Hand, prüft, ob zum Zeitpunkt des Vorfalls eine Policy griff, und formuliert am Ende eine Einschätzung, die er dem Nutzer erklären muss.

Jede dieser Übergaben kostet Minuten bis Stunden. Und weil der Verdacht ohne harten Befund im Raum steht, landet er im Zweifel beim Sicherheits-Team, das dann seinerseits belegen muss, dass alles korrekt läuft. Am Ende war es das WLAN im Homeoffice, aber vier Personen haben daran gearbeitet.

Zscaler liefert die Daten bereits: ZDX

Zscaler Digital Experience, kurz ZDX, misst die digitale Nutzererfahrung Ende zu Ende. Es erfasst Geräte-Kennzahlen (CPU, Speicher, WLAN-Signal), die lokale Netzstrecke, den Weg über den Internet-Provider und den Pfad durch die Zscaler-Cloud bis zur Ziel-Anwendung. Der ZDX Deep Trace zeigt jeden einzelnen Hop mit Latenz und Paketverlust. Damit ist die Information, wo genau es klemmt, technisch vorhanden.

Der Haken liegt nicht bei den Daten, sondern beim Zugriff und der Interpretation. Der Deep Trace ist ein Werkzeug für Fachleute. Er zeigt Rohwerte über die gesamte Strecke, aber er sagt nicht in einem Satz: „Das WLAN des Nutzers ist der Engpass, Zscaler ist unauffällig." Genau diese Übersetzung vom Messwert zur Aussage ist der Schritt, der im Alltag Zeit frisst und Admin-Rechte voraussetzt, die der Helpdesk oft nicht hat.

Connectivity Triage Map: die Kette zusammenziehen, die Ursache benennen

Hier setzt Connectivity Triage Map von CentaurNexus an. Das Modul zieht über die offizielle Zscaler OneAPI die vollständige ZDX-Kette zusammen und ergänzt sie um den aktuellen Policy-Status für den betroffenen Nutzer und die betroffene Anwendung. Aus diesen Signalen bildet es ein Verdikt im Klartext: Die Ursache liegt beim ISP, beim WLAN, am Gerät oder bei Zscaler.

Der Unterschied ist nicht der Zugang zu neuen Daten, sondern die Diagnose statt der Rohdaten. Statt fünf Reiter zu öffnen und Zeitstempel zu vergleichen, sieht der Bearbeiter einen benannten Befund und darunter, aufklappbar, den ZDX Deep Tracing-Beleg Hop für Hop. Wer tiefer prüfen will, sieht die Kette; wer nur handeln muss, sieht das Urteil.

Klartext auch für den First-Level

Der praktische Hebel liegt darin, wer die Analyse fahren kann. Weil Connectivity Triage Map das Ergebnis in verständlicher Sprache formuliert, muss nicht jeder Fall an einen Netzwerk-Spezialisten eskalieren. Ein First-Level-Mitarbeitender liest „Engpass im lokalen WLAN, Zscaler unauffällig" und kann direkt die richtige Empfehlung geben: näher an den Router, Bandbreite prüfen, Gerät entlasten. Die Eskalation entfällt in genau den Fällen, in denen sie nie nötig gewesen wäre.

Der Befund als Beweis

Ein oft unterschätzter Punkt: Wenn die Ursache außerhalb des eigenen Einflussbereichs liegt, etwa bei einem Internet-Provider oder in einem Homeoffice-Anschluss, braucht die IT einen belastbaren Nachweis, um das Thema weiterzugeben. Ein exportierbarer Connectivity Triage Map-Befund mit ZDX Deep Tracing-Beleg ist genau dieser Nachweis. Er dokumentiert nachvollziehbar, an welcher Stelle der Kette die Latenz oder der Paketverlust auftrat, und nimmt der Diskussion die Spekulation.

CentaurNexus trennt Mandantenkontexte, vergibt Rechte rollenbezogen und protokolliert Vorgänge nachvollziehbar. Der Helpdesk sieht seinen freigegebenen Bereich ohne breite Zscaler-Adminrechte. Für EU-Kunden läuft der Produktivbetrieb vollständig auf STACKIT in der EU; Datenschutz- und Datenwege sind in der Datenschutzerklärung dokumentiert.

ZDX und NexusAgent ergänzen sich

ZDX liefert die digitale Erfahrung über Anwendung, Netzwerkpfad und Gerät. NexusAgent ergänzt diesen Blick um die für den unterstützten CentaurNexus-Ablauf benötigten Endgerätesignale, wenn diese Informationen nicht über OneAPI verfügbar sind. NexusAgent ergänzt den ZDX-Kontext um Endgerätesignale für unterstützte CentaurNexus-Arbeitsabläufe.

Die Cause Map verbindet die vorhandenen Signale zu einer nachvollziehbaren Ursache-Wirkungs-Kette. Sie zeigt, ob der stärkste Hinweis am Gerät, im lokalen Netzwerk, auf dem Zscaler-Pfad oder bei der Anwendung liegt. Quelle, Datenalter und Coverage bleiben Teil des Ergebnisses.

Ein Befund muss zur nächsten Aktion führen

Eine Diagnose ist für den Helpdesk erst dann nützlich, wenn sie den nächsten Prüfschritt erklärt. Ein lokales WLAN-Signal führt zu einer anderen Maßnahme als ein nicht erreichbarer App Connector oder eine zentrale Dienststörung. Der Bearbeiter sieht die begründete Einordnung und kann gezielt lösen oder übergeben.

Bei der Abnahme werden vollständige, teilweise verfügbare und bewusst fehlende Quellen getestet. Dadurch bleibt die Cause Map auch dann verständlich, wenn ein Tenant nicht jede ZDX- oder Agentquelle bereitstellt.