Mist AI und Mist-Analysen
Sie sammeln, normalisieren und korrelieren Telemetrie. Insights liefern zeit- und objektbezogene Details; SLEs messen die Nutzererfahrung gegen Schwellenwerte und Classifier ordnen Fehlschläge Ursachenklassen zu.
1. Lernziele
- Mist AI, Insights, SLEs und Marvis sauber unterscheiden
- Messwert, Klassifikation, Schlussfolgerung und Aktion auseinanderhalten
- natürliche Sprache und strukturierte Marvis Queries gezielt einsetzen
- Marvis Actions nach Wirkung, Status und Risiko bewerten
- Driver-Assist von freigegebener Self-Driving-Automation unterscheiden
- Marvis Minis als aktive synthetische Tests einordnen
- Wireless-, Wired- und WAN-Indizien in einer Beweiskette verbinden
- AI-Ergebnisse gegen Telemetrie, Konfiguration und reale Tests validieren
Leitfrage: Sehe ich Rohdaten, eine bewertete Nutzererfahrung, eine AI-Schlussfolgerung, eine empfohlene Handlung oder einen aktiven Test?
2. Die Kurzantwort
Marvis
Marvis ist die virtuelle Assistenz- und AIOps-Schicht auf dieser Datenbasis. Sie beantwortet Fragen, priorisiert Probleme als Actions, empfiehlt oder führt ausgewählte Korrekturen aus und validiert Dienste aktiv mit Minis.
Mist AI erzeugt verwertbare Evidenz – Marvis macht daraus Dialog, Priorität, Handlung und aktive Verifikation.
Die beiden sind keine konkurrierenden Produkte. Marvis nutzt die Analytik der Mist-Plattform und erweitert den Bedien- und Automatisierungsumfang.
3. Begriffe ohne Marketingnebel
| Begriff | Präzise Bedeutung | Typische Frage |
|---|---|---|
| Mist Cloud | Management-, Telemetrie- und Analyseplattform | Wo werden Daten und Konfiguration zusammengeführt? |
| Mist AI | AI-/ML- und Data-Science-Funktionen innerhalb der Plattform | Welche Muster und Ursachen sind erkennbar? |
| Insights | Detailansicht für Sites, Geräte, Clients, Anwendungen, Ereignisse und Zeitverläufe | Was geschah mit diesem Objekt in diesem Zeitraum? |
| SLE | quantifizierte Service Level Expectation für Nutzererfahrung | Wie viele Vorgänge erfüllten das Ziel? |
| Classifier | Zuordnung nicht erfolgreicher Vorgänge zu Ursachenklassen | Warum wurde das Ziel verfehlt? |
| Marvis | virtueller Netzwerkassistent und AIOps-Funktionsfamilie | Was ist wichtig und was soll ich tun? |
| Marvis Minis | synthetische, proaktive Diensttests auf APs oder unterstützten EX Switches | Funktioniert der Dienst auch ohne aktiven Benutzer? |
Sprachregel dieser Unterlage: „Mist-Analysen“ bezeichnet Insights, SLEs, Classifier, Ereignisse und Anomalieerkennung. Das ist kein eigener Produktname.
4. Der Analyse-Stack
Geräte- und Clienttelemetrie→Normalisierung→SLE / Events / Insights→AI-Korrelation→Marvis→Aktion & Validierung
| Ebene | Ergebnis | Fehler bei falscher Interpretation |
|---|---|---|
| Beobachtung | RSSI, DHCP-Zeit, Portstatus, WAN-Latenz, Ereignis | Ein Einzelwert wird vorschnell als Ursache bezeichnet. |
| Bewertung | SLE erfüllt oder verletzt | Schwellenwert wird mit Ausfall gleichgesetzt. |
| Klassifikation | z. B. Coverage, DHCP, Interference | Kategorie wird ohne Detailbeleg als Root Cause akzeptiert. |
| Korrelation | Zusammenhang über Clients, Geräte und Domains | Korrelation wird mit Kausalität verwechselt. |
| Handlung | empfohlene oder erlaubte automatische Korrektur | Risiko, Scope oder Change-Fenster werden ignoriert. |
| Validierung | kein Wiederauftreten oder erfolgreicher Mini-Test | „grün“ wird ohne ausreichende Testabdeckung als Vollbeweis gelesen. |
5. Die wichtigste Vergleichsmatrix
| Funktion | Frage | Modus | Output |
|---|---|---|---|
| Insights | Was ist wann passiert? | explorativ, überwiegend reaktiv | Timeline, Statistik, Events, Traffic |
| SLEs | Wie gut war die Erfahrung? | kontinuierliche Bewertung | Erfolgsrate und betroffene Nutzer |
| Classifier | Warum wurde ein Ziel verfehlt? | analytische Zuordnung | Ursachenklassen und Anteile |
| Potential Anomalies | Was weicht auffällig vom Verhalten ab? | proaktive Erkennung | Hinweis und mögliche Optimierung |
| Marvis Dialog | Kannst du meine Frage verstehen und eingrenzen? | natürliche Sprache | Antwort, Rückfrage, Drill-down |
| Marvis Query Language | Welche Objekte/Ereignisse passen exakt? | strukturierte Abfrage | Liste, Count, Rank, Status, Graph |
| Marvis Actions | Was sollte zuerst behoben werden? | priorisierte AIOps | Problem, Scope, Empfehlung, Verlauf |
| Self-Driving Actions | Darf Marvis ausgewählte Probleme selbst beheben? | freigegebene Automation | Change plus AI-Validierung |
| Marvis Minis | Funktioniert der Service ohne echten Client? | synthetischer aktiver Test | DHCP/DNS/ARP/RADIUS/App-Ergebnis |
6. Gemeinsame Datenbasis
Die Qualität aller Analysen hängt von Reichweite, Aktualität und Semantik der Telemetrie ab. Mist kann unter anderem Daten aus APs, Juniper Switches, WAN Edges, Mist Edge, Clientverbindungen, Anwendungen und BLE-Assets zusammenführen.
| Quelle | Beispiele | Analytischer Wert |
|---|---|---|
| Wireless | Association, Auth, DHCP, RSSI/SNR, Roaming, Retry, Durchsatz | Clienterfahrung und RF-Ursachen |
| Wired | Port, VLAN, PoE, LLDP, Kabel, Loop, Auth | Zugangspfad und Infrastrukturfehler |
| WAN | Pfad, Latenz, Jitter, Verlust, Anwendung | Client-to-Cloud-Einordnung |
| Konfiguration | WLAN, VLAN, Switchport, Firmware, Site | Intent gegen beobachteten Zustand |
| Synthetisch | Minis für DHCP, DNS, RADIUS, App | Test ohne reale Nutzeraktivität |
Fehlt eine Domain, ein Gerät, eine Lizenz oder die passende Zeitspanne, kann die Analyse lokal korrekt und trotzdem Ende-zu-Ende unvollständig sein.
7. Mist Insights: die Belegansicht
Insights ist die richtige Startfläche, wenn ein konkreter Client, AP, Switch, WAN Edge, Standort oder Zeitraum untersucht werden soll. Sie verbindet Status, Zeitverlauf, Events, Traffic und weiterführende Details.
Stärken
- zeitliche Korrelation
- objektbezogener Drill-down
- sichtbare Einzelereignisse
- Wireless, Wired und WAN im Full-Stack-Kontext
Grenzen
- Operator muss Scope und Zeitraum sinnvoll wählen
- viele Events sind noch keine Root Cause
- fehlende Telemetrie bleibt fehlende Telemetrie
- Retention hängt von Funktion und Subscription ab
| Insights beantwortet gut | Insights beantwortet allein schlecht |
|---|---|
| Wann verlor der Client die Verbindung? | Welches Problem hat organisationsweit höchste Priorität? |
| Welche Events hatte AP-17? | Welche freigegebene Maßnahme soll automatisch laufen? |
| Wie verlief Traffic im Zeitraum? | Ist ein Dienst ohne reale Benutzer verfügbar? |
8. SLEs: Nutzererfahrung wird messbar
Service Level Expectations bewerten, wie viele relevante Vorgänge einen konfigurierten oder vorgegebenen Erfolgsmaßstab erfüllen. Ein Wert von 96 % bedeutet: 96 % der betrachteten Vorgänge lagen innerhalb der Definition von Erfolg – nicht, dass das Netzwerk pauschal „zu 96 % gesund“ ist.
SLE-Erfolg = erfolgreiche relevante Vorgänge ÷ alle relevanten Vorgänge im gewählten Scope und Zeitraum
| Dimension | Beispiele | Prüffrage |
|---|---|---|
| Verbindung | Successful Connect, Time to Connect | Association, Auth und DHCP getrennt betrachten? |
| RF | Coverage, Capacity | Client, Band, AP und Standort berücksichtigt? |
| Leistung | Throughput | Erwartung und Messvoraussetzung passend? |
| Mobilität | Roaming | Cliententscheidung und Infrastrukturanteil getrennt? |
Wichtig: Ein SLE ist ein Outcome-Maß. Es ersetzt weder Design-Review noch Spektrumanalyse, Paketmitschnitt oder Applikationsmonitoring.
9. Classifier: vom Symptom zur Ursachenklasse
Classifier teilen den nicht erfolgreichen Anteil eines SLE in Kategorien auf. Beim Capacity SLE sind etwa Wi-Fi Interference, Non-Wi-Fi Interference, Client Usage und Client Count möglich.
SLE-Verletzung→Classifier→betroffene Clients/APs→Insights & Ereignisse→technischer Beweis
| Classifier ist … | Classifier ist nicht … |
|---|---|
| eine datenbasierte Eingrenzung | automatisch ein vollständiger Root-Cause-Beweis |
| eine Hilfe zur Priorisierung des Drill-downs | eine Garantie, dass nur eine Ursache existiert |
| vom gewählten Scope abhängig | unabhängig von Zeitraum und Datenabdeckung |
10. Potenzielle Anomalien und Optimierungen
Mist kann Echtzeitdaten, Telemetrie, Logs und Performance auf auffällige Abweichungen untersuchen. Potenzielle Anomalien erscheinen im Site-Insights-Ereigniskontext und können Empfehlungen enthalten.
| Nutzen | Risiko | Operatorhandlung |
|---|---|---|
| früher Warnhinweis | auffällig ist nicht automatisch schädlich | Baseline, Scope und Auswirkung prüfen |
| site- oder gerätebezogene Eingrenzung | kurzes Wartungsereignis kann auffallen | Change-Kalender korrelieren |
| Optimierungsvorschlag | Empfehlung kennt nicht jeden lokalen Prozess | Impact und Rollback planen |
11. Was Marvis zusätzlich leistet
Übersetzen
Natürliche oder strukturierte Fragen werden in passenden Scope und Analysepfad übersetzt.
Priorisieren
Hochwirksame Probleme werden organisations-, site- und domainübergreifend als Actions gebündelt.
Operationalisieren
Marvis empfiehlt Maßnahmen, automatisiert ausgewählte erlaubte Fälle und validiert Ergebnisse.
Marvis ist deshalb mehr als eine hübsche Suchmaske, aber keine magische zweite Wahrheit. Die Antworten beruhen auf den verfügbaren Mist-Daten, Produktmodellen, Berechtigungen und dem gewählten Scope.
12. Marvis Conversational Assistant
Der Dialog verwendet Natural Language Processing und Natural Language Understanding. Er kann Informationen zu Sites, Geräten, Clients und Anwendungen liefern, Probleme untersuchen, Dokumentation finden und zu Actions führen.
| Gute Frage | Warum gut? |
|---|---|
| „Welche Benutzer hatten heute am Standort Berlin Verbindungsprobleme?“ | Objekt, Problem, Zeit und Scope sind enthalten. |
| „Troubleshoot Client 8c:… in den letzten zwei Stunden.“ | eindeutige Identität und Zeitraum |
| „Warum war die Teams-Sitzung von Nutzer A schlecht?“ | anwendungsbezogene Ende-zu-Ende-Frage |
| „Wie viele Switches sind am Standort verbunden?“ | zählbare, klar begrenzte Frage |
Prompt-Regel: Entität + Scope + Zeitraum + Symptom + gewünschtes Ergebnis. Rückfragen von Marvis sind sinnvoll, wenn Namen oder Scope mehrdeutig sind.
13. Marvis Query Language
Die strukturierte Abfragesprache ist nützlich, wenn Reproduzierbarkeit und ein exakt definierter Ergebnistyp wichtiger sind als freie Konversation.
| Query | Zweck | Beispiel |
|---|---|---|
LIST | Objekte oder Events auflisten | LIST WiredClients WITH Site Berlin |
COUNT | passende Objekte/Ereignisse zählen | Anzahl Events im Zeitraum |
STATUSOF | problematische Clients priorisieren | STATUSOF Clients WITH Site Berlin |
TROUBLESHOOT | Site, Client oder AP analysieren | TROUBLESHOOT Client-A WITH Problem UnableToConnect |
ROAMINGOF | Roaming grafisch darstellen | Client plus Zeitraum |
LOCATE | Site, AP oder Client lokalisieren | Floorplan-/Map-Kontext |
UTILIZATIONOF | Kanalauslastung eines AP anzeigen | 2,4/5/6-GHz-Aufschlüsselung |
Unterstützte Entitäten und Syntax entwickeln sich weiter. Die Vorschläge im Portal und die aktuelle Dokumentation sind maßgeblich.
14. Marvis Actions: priorisierte Betriebsarbeit
Actions bündeln Probleme mit hohem Einfluss und liefern Ursache, betroffene Objekte, Zeitverlauf und empfohlene Schritte über Wireless, Wired und WAN.
| Beispiel | Domain | Mögliche Handlung |
|---|---|---|
| Bad Cable | Wired | Kabel/Port prüfen und ersetzen |
| Missing VLAN | Wired | VLAN-Pfad und Konfiguration korrigieren |
| Layer-2 Loop | Wired | Topologie und Loop-Ursache beseitigen |
| WAN Outage | WAN | Pfad/Provider/Edge untersuchen |
| Firmware Compliance | Infrastructure | Upgrade gegen Change-Prozess planen |
| Rogue DHCP | Wired/Security | Switch, Port und VLAN identifizieren; Portmaßnahme prüfen |
Eine Action ist stärker operationalisiert als ein Insight: Sie beantwortet nicht nur „was geschah?“, sondern „welcher Fall ist relevant und welche Maßnahme ist vorgesehen?“
15. Lifecycle einer Marvis Action
Problem ist aktiv und wartet auf Bearbeitung.
Bearbeitung oder Validierungsphase läuft.
Operator kennzeichnet die manuelle Lösung.
Eine freigegebene automatische Maßnahme wurde ausgeführt.
Das Problem trat im vorgesehenen Validierungszeitraum nicht erneut auf.
Der Fall öffnet erneut, wenn das Problem wiederkehrt.
AI Validated bedeutet: Das erkannte Problem wurde während der Validierungsphase nicht erneut beobachtet. Es bedeutet nicht, dass jede denkbare Nutzerreise oder Ursache geprüft wurde.
16. Driver Assist und Self-Driving
| Modell | Marvis | Mensch | Risiko |
|---|---|---|---|
| Driver Assist | erkennt, priorisiert und empfiehlt | entscheidet und ändert | langsamer, dafür maximale Prozesskontrolle |
| Self-Driving | führt ausgewählte erlaubte Korrekturen aus und validiert | erteilt vorab Berechtigung und überwacht | größere Geschwindigkeit, benötigt Guardrails |
- nur unterstützte Actions sind automatisierbar
- Self-Driving muss für den betreffenden Fall erlaubt sein
- Berechtigung, Subscription und Plattformunterstützung prüfen
- kritische Sites zunächst ausnehmen oder eng begrenzen
- Change-, Audit- und Rollback-Prozess definieren
- Erfolg an Nutzerwirkung statt nur Config-Änderung messen
17. Marvis Minis: aktives Testen
Minis bilden eine synthetische Nutzerreise nach. Sie prüfen wesentliche Netzwerkdienste auch dann, wenn kein echter Client aktiv ist. Damit ergänzen sie passive Telemetrie um aktive Evidenz.
Mini startet→Clientverhalten simulieren→DHCP / ARP / DNS / RADIUS→Application Reachability→Ergebnis an Marvis
| Passive Analyse | Mini-Test |
|---|---|
| benötigt beobachtete reale Aktivität | kann ohne echten Benutzer laufen |
| zeigt tatsächliche Nutzererfahrung | zeigt synthetische Testreise |
| Clientvielfalt und reale Randfälle | kontrollierter, wiederholbarer Ablauf |
| Problem eventuell erst nach Beschwerde sichtbar | kann Fehler vor Benutzerbeginn finden |
18. Wireless Minis
Ein Access Point simuliert einen Wireless Client. Marvis lernt aktive APs, WLANs, Switches und VLANs, um relevante Pfade zu testen, statt blind jede Kombination zu prüfen.
| Eigenschaft | Bedeutung |
|---|---|
| Ausführung | auf dem AP |
| Tests | unter anderem DHCP, DNS, ARP, RADIUS und Anwendungserreichbarkeit |
| Rhythmus | periodisch, laut Juniper typischerweise stündlich; zusätzlich On-Demand-Wireless-Test |
| Fehlerfall | erneute Validierung und mögliche Ausweitung auf weitere APs/Switches |
| Weiterverarbeitung | zusätzliche Datenquelle; kann zu Marvis Actions beitragen |
Ein erfolgreicher AP-Mini beweist nicht das Verhalten jedes Clienttreibers. Er belegt den getesteten Infrastruktur- und Dienstpfad aus Sicht des simulierten Clients.
19. Wired Minis
Wired Minis laufen auf unterstützten EX Switches und emulieren einen kabelgebundenen Client. Sie prüfen unter anderem DHCP, ARP, DNS, CURL/Application Reachability und RADIUS.
| Aspekt | Einordnung |
|---|---|
| Ausführung | unterstützter EX Switch |
| VLAN-Auswahl | bis zu 16 VLANs mit hoher Clientaktivität je unterstütztem Switch |
| EVPN | Tests auf Access Switches |
| Überlappung | Wireless-getestete VLANs werden aus Wired-Validierungen ausgeschlossen |
| Standardanwendungen | unter anderem Teams, Office sowie Connectivity-Checks; eigene Apps konfigurierbar |
| Subscription | Wired Minis benötigen die passende Marvis-for-Wired-Berechtigung |
20. Empfohlener Ende-zu-Ende-Workflow
Wer, wo, wann, welches Gerät, welches WLAN/LAN und welche Anwendung?
Ist die Nutzererfahrung im Scope messbar schlechter?
Welche Ursachenklasse erklärt den größten Fehlanteil?
Timeline, Events, Client, AP, Switch und WAN-Pfad prüfen.
Scope eingrenzen, ähnliche Betroffene und Ende-zu-Ende-Zusammenhang suchen.
Priorität, Empfehlung, Blast Radius und Berechtigung kontrollieren.
manuell oder – nur wenn freigegeben – Self-Driving.
SLE-Erholung, keine Wiederkehr, Mini-Test und realer Benutzerpfad.
Ursache, Beweis, Änderung, Ergebnis und Prävention festhalten.
21. Praxisfall: „Teams war schlecht“
| Schritt | Werkzeug | Feststellung |
|---|---|---|
| Scope | Marvis Dialog | Nutzer, Sitzung, Site und Zeit werden konkretisiert. |
| Outcome | Application-/WAN-SLE | Jitter oder Verlust überschreitet den Erfahrungsmaßstab. |
| Pfad | Marvis/Insights | Client → AP → Switch → WAN Edge → Cloud wird korreliert. |
| Ursache | Classifier und Telemetrie | Wireless ist stabil; WAN-Pfad zeigt zeitgleich hohen Jitter. |
| Priorität | Marvis Action | weitere Sitzungen und Sites sind betroffen. |
| Beweis | Provider-/Edge-Daten plus Wiederholung | Jitter sinkt nach Pfadkorrektur; Sitzungen erholen sich. |
Der Mehrwert von Marvis liegt in der Verkürzung der Suchkette. Der technische Beweis bleibt eine Kombination aus korrelierten Messwerten, zeitlicher Übereinstimmung und erfolgreicher Nachprüfung.
22. Von der AI-Aussage zum belastbaren Beweis
| Aussage | Benötigter Nachweis |
|---|---|
| „Coverage ist schlecht.“ | betroffene User-Minutes, RSSI/SNR, AP-Verteilung, Clientfähigkeit und Standort |
| „DHCP ist Ursache.“ | Discover/Offer/Request/Ack-Zeiten, VLAN, Relay, Server und Gegenprobe |
| „Kabel ist fehlerhaft.“ | Portfehler, Linkflaps, Cable Diagnostics und physischer Tauschtest |
| „WAN verursacht die App-Probleme.“ | zeitgleicher Jitter/Loss auf Pfad, Wireless/Wired unauffällig, App-Recovery |
| „Action ist gelöst.“ | kein Wiederauftreten, SLE-Erholung und betroffener Use Case erfolgreich |
| „Mini ist grün.“ | Testscope bekannt; bei Bedarf realen Client und Anwendung zusätzlich testen |
Belastbare Root Cause = AI-Hypothese + passende Telemetrie + zeitliche Korrelation + Gegenprobe + erfolgreiche Wiederherstellung
23. Grenzen und Fehlinterpretationen
| Fehlannahme | Richtigstellung |
|---|---|
| „Marvis sieht alles.“ | Marvis sieht nur integrierte, lizenzierte und verfügbare Datenquellen. |
| „Hohe Confidence ist ein Beweis.“ | Confidence stärkt eine Hypothese; Kausalität benötigt Validierung. |
| „Kein Action-Eintrag heißt kein Problem.“ | Das Problem kann außerhalb der Erkennung, des Scopes oder der Datenabdeckung liegen. |
| „Grüner SLE heißt jeder Nutzer ist zufrieden.“ | Aggregate können einzelne Clients oder kurze Peaks verdecken. |
| „Ein Mini ersetzt reale Clients.“ | Minis prüfen definierte Infrastrukturpfade, nicht jede Treiber- oder App-Besonderheit. |
| „Self-Driving ist überall aktiv.“ | Nur ausgewählte, unterstützte und ausdrücklich erlaubte Actions werden automatisiert. |
| „Insights und Marvis liefern getrennte Wahrheiten.“ | Marvis baut auf derselben Mist-Daten- und Analyseschicht auf. |
24. Sicherheit, Datenschutz und Berechtigungen
- Least Privilege für Portal, API und Marvis-Zugriff
- Site- und Organisationsscope von Operatoren dokumentieren
- Clientnamen, Identitäten und Standortdaten datenschutzgerecht behandeln
- Self-Driving nur mit freigegebenen Guardrails aktivieren
- kritische Actions mit Change- und Rollbackprozess verbinden
- Auditlogs und Action-Verlauf regelmäßig prüfen
- Support-Exports und Screenshots auf personenbezogene Daten kontrollieren
- Subscriptions und Rollen regelmäßig rezertifizieren
Juniper nennt für den Conversational Assistant neben der Subscription auch ein Benutzerkonto mit Zugriff auf alle Sites der Organisation als Anforderung. In produktiven Umgebungen ist deshalb besonders zu prüfen, ob Rolle und gewünschter Marvis-Funktionsumfang zusammenpassen.
25. Betriebsmodell und Eskalation
| Stufe | Operator | Werkzeug | Exit-Kriterium |
|---|---|---|---|
| L1 | Service Desk | Marvis Dialog, Clientstatus, bekannte Actions | Scope klar oder Standardlösung erfolgreich |
| L2 | Network Operations | SLE, Classifier, Insights, MQL, Minis | Ursachendomäne bewiesen und Maßnahme definiert |
| L3 | Engineering | Packet Capture, Configdiff, API, RF/WAN-Analyse | Root Cause und dauerhafte Korrektur |
| Vendor | Juniper/Partner | Supportbundle, Zeitfenster, Org/Site/Device IDs | Defect, Plattformgrenze oder Herstellerlösung |
Eskalationen enthalten nicht nur Screenshots, sondern exakte Zeit inklusive Zeitzone, Entitäten, SLE/Classifier, Events, bereits getestete Hypothesen und reproduzierbare Wirkung.
26. Produktionscheckliste
Analyse
- Organisation und Site korrekt
- Zeitraum und Zeitzone korrekt
- betroffene Entitäten eindeutig
- SLE statt Bauchgefühl
- Classifier geöffnet
- Insights-Timeline korreliert
- Ende-zu-Ende-Domains geprüft
- Gegenprobe durchgeführt
Aktion
- Action-Scope verstanden
- Blast Radius bewertet
- Subscription/Support geprüft
- Self-Driving bewusst freigegeben
- Rollback vorhanden
- Mini- und Realtest geplant
- SLE nach Änderung geprüft
- Beweis und Ergebnis dokumentiert
Häufige Entscheidungsfragen
| Situation | Erster Einstieg | Danach |
|---|---|---|
| Ein Client hatte gestern Probleme. | Client Insights | SLE, Events, Marvis Troubleshoot |
| Ist die Site generell gesund? | Site SLEs / Full-Stack Insights | Classifier und Anomalien |
| Was soll NOC heute zuerst tun? | Marvis Actions | Impact, Empfehlung, Change |
| Ich brauche schnell eine Antwort. | Conversational Assistant | Drill-down in Belegdaten |
| Ich brauche eine reproduzierbare Liste. | Marvis Query Language | Export/API oder Insights |
| Funktioniert DHCP nachts ohne Nutzer? | Marvis Minis | Action/Insights bei Fehlschlag |
| Darf die Plattform selbst korrigieren? | Self-Driving Governance | nur ausgewählte Actions plus Validierung |
Merksätze
- Insights zeigt Belege; SLEs bewerten Erfahrung.
- Classifier grenzen Ursachen ein.
- Marvis übersetzt, priorisiert und operationalisiert.
- Queries beantworten Fragen; Actions organisieren Arbeit.
- Self-Driving benötigt ausdrückliche Erlaubnis.
- Minis liefern aktive Evidenz ohne reale Nutzer.
- Ein grünes Aggregat schließt Einzelfälle nicht aus.
- Korrelation ist noch keine Kausalität.
- Scope, Zeitraum und Datenabdeckung bestimmen die Aussage.
- Die beste AI-Antwort endet mit einem überprüfbaren technischen Beweis.
27. Offizielle Grundlagen
- Insights Overview
- Using SLEs for Troubleshooting
- Marvis Virtual Network Assistant Overview
- Marvis Conversational Assistant
- Troubleshoot Using Marvis Query Language
- Marvis Actions Overview
- Self-Driving Marvis Actions
- Marvis Minis Overview
- Wireless Marvis Minis
- Wired Marvis Minis
- Site Insights und Potential Anomalies Update
Stand der fachlichen Prüfung: August 2026. Menüs, Query-Syntax, Retention, unterstützte Actions, Plattformen und Subscription-Anforderungen können sich ändern. Für den produktiven Einsatz gelten die aktuelle Juniper-Dokumentation, der konkrete Cloudrelease und Tests in der eigenen Organisation.