Erkennen
Modelle und Regeln bewerten Telemetrie, Ereignisse, Baselines, Schwere und Dauer.
1. Lernziele
- Marvis Action, Event, Alert, Anomaly und SLE fachlich unterscheiden,
- Model Input Feature, Trigger Condition und Validation Time erklären,
- Action-Scope und Nutzerwirkung aus dem Dashboard ableiten,
- Driver Assist und Self-Driving sicher auseinanderhalten,
- Open, Marvis Self Driven und AI Validated interpretieren,
- Wireless-, Wired-, WAN- und Application-Actions einordnen,
- automatische Änderungen mit Guardrails betreiben,
- Action, Ursache, Korrektur und Wirkung nachvollziehbar dokumentieren.
Leitfrage: Welche Messdaten und Bedingungen erzeugten die Action, welchen realen Impact besitzt sie, welche Korrektur ist zulässig – und wodurch wird ihr Erfolg bewiesen?
2. Was sind Marvis Actions?
Marvis Actions sind von Mist AI priorisierte, handlungsorientierte Probleme und Empfehlungen. Sie fassen relevante Statistik-, Event- und Kontextdaten zusammen, grenzen den Scope ein und stellen – abhängig von Action und Freigabe – eine manuelle oder automatische Korrektur bereit.
Erklären
Dashboard und View More zeigen betroffene Objekte, Ursache, Timeline und Empfehlung.
Beheben
Driver Assist führt den Admin; unterstützte Self-Driving Actions können selbst korrigieren und validieren.
Actions existieren für Wireless, Wired und WAN sowie – bei entsprechender Integration – Data Center/Application. Sichtbarkeit und Umfang hängen von Subscriptions, Plattform, Rolle, Firmware und vorhandenen Daten ab.
Action = erkannter Impact + eingegrenzter Scope + empfohlene beziehungsweise automatische Remediation
3. Marvis Actions, Alerts, Events und SLEs
| Objekt | Zweck | Zeitverhalten | Beispiel |
|---|---|---|---|
| Event | beobachtete Zustandsänderung | beim Auftreten | Port down |
| Alert | Benachrichtigung bei definierter Bedingung | nahe Echtzeit nach Regel/Threshold | Switch offline |
| SLE | quantifiziert Nutzererfahrung | fortlaufend aggregiert | Successful Connects |
| Anomaly | Abweichung von erwarteter Baseline | nach ausreichender Beobachtung | ungewöhnlicher Traffic |
| Marvis Action | hochwirksames, handlungsfähiges Problem | nach Trigger-, Schwere- und Kontextbewertung | Missing VLAN |
Juniper-Abgrenzung: Marvis Actions ersetzen Alerts nicht. Wer jeden Port-Up-/Down-Vorgang unmittelbar melden möchte, benötigt passende Alerts; eine Action soll relevante, handlungswürdige Muster herausfiltern.
4. Wie eine Action entsteht
Juniper beschreibt drei zentrale Begriffe für die Backend-Bewertung:
| Begriff | Bedeutung | Beispiel |
|---|---|---|
| Model Input Feature | Daten beziehungsweise Merkmale, die das Modell verarbeitet | Switch-Port-Statistiken und Events |
| Trigger Conditions | Bedingungen, unter denen eine Action erzeugt wird | wiederholte Abweichung vom gelernten Muster |
| Validation Time | Zeit, nach der eine offene Action ohne weiter beobachtetes Symptom als gelöst gilt | 30 Minuten, 1 Tag oder 7 Tage je Action |
Telemetrie→Feature→Baseline/Regel→Schwere + Dauer→Action
Starke Abweichungen können schneller eine Action erzeugen als schwache, länger anhaltende Muster. Einige Actions verwenden statistische Baselines oder LSTM-basierte Modelle; andere beruhen auf klaren Zuständen, Events oder Konfigurationsvergleichen.
Validation Time ≠ Detection Time: Die Validierungszeit beschreibt die Auflösung nach ausbleibenden Symptomen, nicht zwingend die Zeit bis zur erstmaligen Erkennung.
5. Der Action-Lebenszyklus
Geräte, Clients und Cloud liefern Statistik, Zustände und Events.
Marvis verknüpft zeitliche, topologische und Experience-bezogene Merkmale.
Action-spezifische Bedingungen, Schwere und Dauer sind erfüllt.
Site, Gerät, Port, VLAN, Client, Tunnel oder Anwendung wird zugeordnet.
Details, Grund und Korrekturmöglichkeit werden dargestellt.
Administrator oder Self-Driving führt die Korrektur aus.
Marvis beobachtet im action-spezifischen Zeitraum das Wiederauftreten.
Kehrt das Problem zurück, wird die Action wieder Open.
6. Das Marvis Actions Dashboard
Die Ansicht kann abhängig vom Scope auf MSP-, Organization- oder Site-Ebene verwendet werden. Kategorien bündeln Wireless, Wired, WAN und Data Center/Application.
| Element | Prüfung |
|---|---|
| Kategorie | Welche Netzwerkdomäne ist betroffen? |
| Action Count | Wie viele offene oder gefilterte Probleme existieren? |
| Details / View More | Welche Geräte, Ports, Clients, Gründe und Zeitreihen? |
| Recommended Action | Welche Änderung oder Untersuchung wird vorgeschlagen? |
| Ask Marvis | Welche Zusammenfassung, Ursachen und Folgefragen stehen bereit? |
| Statusfilter | Open, Marvis Self Driven, AI Validated oder Gesamtsicht? |
| Download | CSV-Liste für Organization oder Site dokumentieren |
Die zeitbezogene Self-Driven-Grafik zeigt historische Muster automatischer Actions auf Site- oder Organization-Ebene. Für Actions ohne Self-Driving-Fähigkeit wird der entsprechende Filter nicht angezeigt.
7. Driver Assist
Driver-Assist-Actions liefern Evidenz und Empfehlung, benötigen aber eine bewusste Handlung des Administrators. Dazu gehören Diagnose, Change-Bewertung, Freigabe, Durchführung und Erfolgskontrolle.
Action→Evidence Review→Change Decision→Admin Action→Validation
Typische Driver-Assist-Maßnahmen
- Kabel, Optik oder Endgerät physisch prüfen
- fehlendes VLAN auf dem richtigen Port ergänzen
- MTU, Native VLAN, Allowed VLAN oder Duplex angleichen
- AP-Platzierung beziehungsweise RF-Design korrigieren
- ISP- oder Upstream-Störung eskalieren
- Firmwareupgrade bewusst starten
Eine Schaltfläche im Action-Dialog ist keine pauschale Change-Freigabe. Zuständigkeit und Betriebsprozess bleiben wirksam.
8. Self-Driving Actions
Self-Driving führt für ausgewählte Actions definierte Korrekturen autonom aus. Juniper dokumentiert aktuell folgende unterstützte Gruppen:
| Domäne | Self-Driving-fähige Action | Automatische Korrektur | Default |
|---|---|---|---|
| Wireless | Non-Compliant | AP-Firmwareupgrade im verkehrsarmen Zeitraum | deaktiviert |
| Wireless | Dynamic Capacity Optimization | Band-/Radiomodus und Bandbreite optimieren | deaktiviert |
| Wireless | DFS Optimization | RRM-/DFS-Optimierung und siebentägige Sicht | aktiv, nicht deaktivierbar |
| Wired | Port Stuck | Port Bounce, maximal drei Versuche | aktiv |
| Wired | Rogue DHCP Server Detected | erkannten Access-Port deaktivieren | deaktiviert |
| WAN | Non-Compliant | SRX Snapshot für Backup-Partition | deaktiviert |
| WAN | Intermittent WAN Connectivity | Uplink-Port bei ISP-ARP/DHCP-Fehler bouncen, maximal drei Versuche | aktiv |
Der Katalog kann sich ändern. Vor produktiver Governance gelten stets aktuelle Portalansicht und Juniper-Dokumentation.
9. Statusmodell und Wiederauftreten
Open→In progress / Remediation→Resolved by User oder Marvis Self Driven→Validation Time→AI Validated
| Status | Fachliche Bedeutung |
|---|---|
| Open | Problem ist aktiv, ungelöst oder nach Korrektur erneut aufgetreten |
| In progress | Ein Benutzer bearbeitet das Problem; Marvis überwacht es weiter |
| Resolved by User | Benutzer hat eine Driver-Assist-Action manuell als gelöst markiert |
| Marvis Self Driven | Marvis hat die definierte Korrektur automatisch ausgeführt |
| AI Validated | Das erkannte Symptom wurde im Validierungszeitraum nicht erneut beobachtet |
Auch ohne manuelles Setzen von Resolved by User kann Marvis eine nicht mehr beobachtete Action nach Prüfung als AI Validated einstufen. AI Validated beweist jedoch nicht, dass jede denkbare Ursache dauerhaft beseitigt ist. Die Action-spezifische Beobachtung wird durch eigene SLE-, Service- und Change-Kontrollen ergänzt.
10. Organization- und Site-Berechtigungen
Self-Driving kann über Marvis Self Driven auf Organization- oder Site-Ebene freigegeben werden. Organization-Berechtigungen gelten für alle Sites; eine Site kann diese Vorgabe überschreiben.
Organization Default→Site Override→Action Toggle→effektive Berechtigung
- Action-spezifischen Toggle prüfen
- Organization- und Sitewert gemeinsam auflösen
- kritische Sites mit abweichendem Change-Regime ausnehmen
- Verantwortung für Freigabe und Review benennen
- Audit-/Eventnachweis der ausgeführten Korrektur sichern
Wird Self-Driving deaktiviert, dürfen bereits laufende Aufgaben laut Juniper noch abgeschlossen werden; neue Aufgaben starten anschließend nicht mehr automatisch.
Kein globales „AI an“: Die wirksame Automatisierung ergibt sich aus Actionfähigkeit, Default, Organization-/Site-Freigabe, Plattform und aktuellem Zustand.
11. Wireless Actions – Betrieb und Verfügbarkeit
| Action | Erkennung | Validierungs-/Betriebshinweis |
|---|---|---|
| Offline | AP lokal up/down; Korrelation zu Switch-, Site-, Region- oder ISP-Ausfall | Backend-Doku: 15 Minuten Validation Time; Alerts für Sofortmeldung |
| Health Check Failed | AP oder Radios bleiben nach Auto-Recovery wiederholt inoperabel | Firmware oder Austausch; bis zu 24 Stunden Anzeigeauflösung möglich |
| Non-Compliant | Firmwareabweichung zur Compliance-/Sitebewertung | Self-Driving optional; dokumentierte Auflösung nach Upgrade ca. 30 Minuten |
| Coverage Hole | wiederholt niedriger RSSI mehrerer Clients und Baseline-Anomalie | Floorplan erforderlich; RF-Design/Placement prüfen |
| Insufficient Capacity | wiederholte, längere, nicht saisonale Kapazitätsengpässe | Floorplan und reale Last-/Clientdaten prüfen |
| AP Loop Detected | AP empfängt reflektiertes, zuvor gesendetes Paket | VLAN-/Tunnelpfad und STP prüfen |
| Mist Edge Anomaly | Traffic-, Link-/Port- oder Tunnelabweichungen | Edge, Underlay und Tunnel gemeinsam untersuchen |
Coverage Hole und Insufficient Capacity werden nicht aus einem einzelnen schlechten Messwert abgeleitet. Wiederholung, Impact, Baseline und räumlicher Kontext sind Teil der Bewertung.
12. Wireless Actions – RF-Optimierung
Dynamic Capacity Optimization
Wird bei mehreren APs mit unzureichender Kapazität oder einem dauerhaft überlasteten AP ausgelöst. Kann Dual-Band-/Radiomodus und Kanalbreite anpassen.
DFS Optimization
Zeigt, wie RRM Radarhistorie verarbeitet und Kanalzuweisungen beeinflusst. Self-Driving ist aktiviert und laut aktueller Dokumentation nicht deaktivierbar.
Vor Freigabe von Capacity Optimization
- betroffene Top-APs und erwartete Peak-Throughput-Verbesserung prüfen
- Clientmix und Bandfähigkeit berücksichtigen
- 2,4-GHz-Coverage bei Radio-Conversion absichern
- Kanalwiederverwendung bei breiteren Kanälen bewerten
- RRM-Constraints und Overrides auflösen
- Capacity-, Coverage- und Throughput-SLE danach vergleichen
Optimierung ist ein RF-Change: Mehr Bandbreite oder ein zusätzlicher 5-/6-GHz-Radiomodus kann Durchsatz steigern, aber Kanalwiederverwendung und Coverage verändern.
13. Wired Actions – Layer 2 und Konfiguration
| Action | Erkannter Zusammenhang | Erste technische Prüfung |
|---|---|---|
| Missing VLAN | aktives Client-VLAN fehlt am AP-Switchport; Korrelation über mehrere APs | AP-Traffic, Portprofil, Tagged VLANs, DHCP |
| Negotiation Incomplete | Autonegotiation scheitert | Speed, Duplex, Kabel/Optik, Gegenstelle |
| MTU Mismatch | Port und Gegenstelle mit unterschiedlicher MTU | beide Enden und Pfad-MTU |
| Loop Detected | schnelle oder anhaltende STP-Topologieänderungen | Root, Ports, LAG, VLAN und Verkabelung |
| Misconfigured Port | Uplinkunterschied bei Speed, Duplex, Native/Allowed VLAN, MTU, Mode oder STP | effektive Konfiguration beider Ports |
Missing VLAN kann auch bei Third-Party-Switches erkannt werden. Die verfügbare Remediation unterscheidet sich jedoch nach Plattform und Managementintegration.
14. Wired Actions – Zustand und Anomalien
| Action | Logik | Hinweis |
|---|---|---|
| Network Port Flap | anhaltendes Flapping eines Trunk-Ports nach Frequenz und Dauer | langsame Flaps können später eskalieren |
| Access Port Flap | wiederholtes Up/Down auf Access-Port | Endgerät, Kabel, PoE und Treiber prüfen |
| High CPU | durchgehend durchschnittlich über 90 % im beobachteten Datensatz | Prozess, Loop, Multicast, Optik, Temperatur |
| Port Stuck | plötzliche Abweichung im Traffic eines Access-Endpunkts | automatischer Bounce; Action bleibt bei Misserfolg/Wiederholung |
| Traffic Anomaly | Abweichung bei Broadcast-/Multicast- und Fehlerzählern | Baseline, Severity und betroffene Ports prüfen |
| Switch Offline | mehr als drei Minuten ohne Mist-Cloudverbindung | Event/Alert erscheint früher; Power, Kabel, Firewall, Config |
Beim Port Stuck kann die automatische Korrektur bereits vor der sichtbaren offenen Action erfolgen. Erst wenn der Endpoint nach dem Bounce nicht zurückkehrt oder das Muster wiederholt auftritt, bleibt die Action offen.
15. Rogue DHCP Server Detected
Die Action setzt einen EX Switch mit DHCP Snooping voraus. Marvis beobachtet Offers eines unbekannten Servers, ordnet sie Switch, Port, VLAN oder Site zu und verlangt wiederholte Aktivität, bevor eine fortlaufende Störung angenommen wird.
Unknown DHCP Offer→Port/VLAN Mapping→Wiederholung→Action→Port Disable
| Modus | Verhalten |
|---|---|
| Self-Driving deaktiviert | Administrator kann den erkannten Port manuell deaktivieren |
| Self-Driving aktiviert | Marvis deaktiviert den Access-Port automatisch |
| Rogue Server am Trunk | automatische Port-Deaktivierung wird nicht angewendet |
Disruptive Security Action: Vor Freigabe werden Fehlzuordnungsrisiko, Uplinkschutz, autorisierte DHCP-Server, DHCP-Snooping-Design und Incident-Reaktion geprüft.
16. WAN Actions
| Action | Aktuelle fachliche Bedeutung | Reaktion |
|---|---|---|
| MTU Mismatch | WAN-Edge-Port und direkt verbundenes Gerät verwenden abweichende MTU | beide Ports/Pfad korrigieren |
| Intermittent WAN Connectivity | ISP-ARP zum Gateway oder ISP-DHCP schlägt fehl | Self-Driving-Port-Bounce, maximal drei Versuche |
| Bad WAN Uplink | schlechte LTE-Konnektivität mit RSSI, RSRP oder SNR | Signal, Antenne, Provider und Standort prüfen |
| VPN Path Down | Overlay-/Peerpfad zu oder von Hub/Spoke ist down | Interface, Gateway, Tunnel und betroffene Apps/Sites |
| Non-Compliant | SRX Primary-/Backup-Partition mit unterschiedlicher Junos-Version | Snapshot Device optional self-driving |
| Negotiation Incomplete | Autonegotiation-/Duplexproblem am WAN-Port | Port und Gegenstelle prüfen |
Die Bedeutung von Bad WAN Uplink wurde gegenüber älterer Dokumentation verengt. Für aktuelle Betriebsentscheidungen gilt die heutige WAN-Actions-Seite: ISP-ARP-/DHCP-Unterbrechungen gehören zu Intermittent WAN Connectivity, schlechte LTE-Signale zu Bad WAN Uplink.
17. Data Center/Application Actions
Data Center Actions
Bei verknüpfter Mist- und Apstra-Cloud-Organisation öffnet die Kategorie die Marvis-Actions-Ansicht in Apstra Cloud Services. Passende Rollen und Konfiguration sind erforderlich.
Reachability Failure
Marvis Minis erkennt fehlgeschlagene Anwendungsreichbarkeit und hebt sie proaktiv als Action hervor.
Minis validieren neben Application Reachability auch DHCP, ARP und DNS. Die Reachability-Failure-Action konzentriert sich auf den Anwendungsfehler, damit er vor realer Benutzerbeeinträchtigung sichtbar werden kann.
Application Failure ist noch keine Fehlerdomäne: DNS, Routing, Firewall, WAN, Server oder SaaS können dasselbe Symptom erzeugen. Der synthetische Pfad wird vollständig aufgelöst.
18. Connectivity und weitere Actions
Die Backend-Dokumentation beschreibt zusätzliche, domänenübergreifende Actions für Wired- und Wireless-Clients.
| Action | Modellansatz | Validation Time laut Backend-Seite |
|---|---|---|
| Authentication Failure | LSTM-basierte Abweichung von Site-Baseline, Severity und Dauer | 1 Tag |
| DHCP Failure | Abweichung bei DHCP-Erfolg/-Fehler | 1 Tag |
| ARP Failure | Abweichung bei ARP-Erfolg/-Fehler | 1 Tag |
| DNS Failure | Abweichung bei DNS-Erfolg/-Fehler | 1 Tag |
| Persistently Failing Clients | kontinuierliche Auth-/Connect-Fehler, Site- und Gleichzeitigkeitseinfluss | 60 Minuten |
| Bad Cable | Speedwechsel, Fehler, kein Traffic oder häufige Disconnects/Restarts | 7 Tage |
Die Tabellenwerte erklären das action-spezifische Auflösungsverhalten. Sie sind keine allgemeine SLA und keine garantierte Erkennungszeit.
19. Action validieren
Marvis validiert das Ausbleiben des erkannten Symptoms. Der Betreiber prüft zusätzlich, ob der Dienst und die Benutzererfahrung wiederhergestellt sind.
| Action | Technische Nachprüfung |
|---|---|
| Missing VLAN | Client erhält IP, VLAN ist end-to-end vorhanden, DHCP-SLE verbessert |
| Port Stuck | TX und RX kehren zurück, Endpoint bleibt stabil |
| Coverage Hole | Coverage-SLE, RSSI/SNR, Survey und reale Clients |
| Dynamic Capacity | Capacity/Throughput, Kanalnutzung, Clientverteilung, keine Coverage-Nebenwirkung |
| Rogue DHCP | keine unbekannten Offers, legitimer Dienst funktioniert, Portmaßnahme korrekt |
| WAN Connectivity | ARP/DHCP stabil, Uplink und Overlay funktionieren, Anwendungen erreichbar |
| Non-Compliant | Version/Partition entspricht Soll, Gerät gesund, keine neue Störung |
AI Validated + SLE verbessert + Service stabil + keine Nebenwirkung = belastbare Abnahme
20. Operativer Action-Workflow
Organization, Site, Kategorie und Statusfilter kontrollieren.
Betroffene Geräte, Clients, Anwendungen und User Minutes bestimmen.
View More, Timeline, Events, SLEs und Insights prüfen.
Driver Assist oder Self-Driving, Default und effektive Freigabe feststellen.
Change-Auswirkung, Wartungsfenster, Rollback und Owner festlegen.
kleinste wirksame Korrektur manuell oder automatisch ausführen.
Actionstatus, SLE, Events und Anwendungserlebnis beobachten.
Ursache, Aktion, Zeit, Ergebnis und Wiederholungsrisiko sichern.
21. Governance und Guardrails
| Kontrolle | Umsetzung |
|---|---|
| Action Inventory | fähige, aktivierte und nicht deaktivierbare Actions dokumentieren |
| Scope | Organization-Default und Site-Overrides versioniert pflegen |
| Change-Risiko | Bounce, Disable, Upgrade, RF-Change und Snapshot getrennt bewerten |
| Critical Sites | Standorte mit Sonderfreigaben oder Change Freeze gesondert behandeln |
| Owner | Wireless, Wired, WAN, Security und Application Verantwortliche benennen |
| Rollback | für jede reversible Action klare Rücknahme definieren |
| Evidence | CSV, Events, Insights und Auditdaten sichern |
| Review | Nutzen, Fehlaktionen, Reopen-Rate und Nebenwirkungen regelmäßig prüfen |
Actions mit kleiner, klarer Remediation und gut messbarem Ergebnis eignen sich eher für Self-Driving als Aktionen mit großem Blast Radius oder unklarer Rücknahme.
22. Wenn eine Action unklar oder falsch wirkt
| Symptom | Mögliche Ursache | Prüfung |
|---|---|---|
| Action fehlt trotz Event | Trigger, Severity, Dauer oder Impact nicht erreicht | Event/Alert und Backend-Bedingung vergleichen |
| Action bleibt Open | Symptom besteht, kehrte zurück oder Remediation scheiterte | Timeline, Status und aktuelle Messwerte |
| Action verschwindet spät | action-spezifische Validation Time | Validierungszeit und letzte Beobachtung |
| Self-Driving startet nicht | Action nicht fähig, Permission aus, Site Override oder Plattformgrenze | effektive Berechtigung und Action-Icon |
| Port wurde mehrfach gebounced | Port Stuck oder WAN Connectivity wiederholt | maximal drei Versuche und Open-Status |
| falscher Scope vermutet | gemeinsamer Switch/Site/ISP wurde korreliert | betroffene Topologie und lokale Sicht |
| Bad WAN Uplink anders beschrieben | veraltete Dokumentation | aktuelle WAN-Actions-Seite |
| Action nicht sichtbar | Subscription, Rolle, Domain oder Daten fehlen | Lizenz und Org-/Sitezugriff |
Actions und Rohdaten zusammen lesen: Wenn die Action nicht zur Beobachtung passt, werden Eventtimeline, SLE, Insights, Konfiguration und gegebenenfalls PCAP geprüft, bevor sie verworfen oder umgesetzt wird.
23. Review- und Abnahmecheckliste
Vor Remediation
- richtige Organization/Site
- Action und Status korrekt
- betroffene Objekte geprüft
- Evidence nachvollzogen
- Impact quantifiziert
- Self-Driving-Default bekannt
- effektive Permission geprüft
- Rollback und Owner vorhanden
Nach Remediation
- Actionstatus nachvollzogen
- Validation Time berücksichtigt
- SLE verbessert
- Service erreichbar
- keine Nebenwirkung
- kein Reopen
- Events/Audit gesichert
- Ergebnis dokumentiert
Häufige Fehlannahmen
| Behauptung | Bewertung | Fachliche Einordnung |
|---|---|---|
| „Marvis Actions ersetzen Alerts.“ | Falsch | Alerts melden Ereignisse unmittelbar; Actions priorisieren handlungswürdige Muster. |
| „Validation Time ist die Erkennungszeit.“ | Falsch | Sie beschreibt die Zeit bis zur Auflösung nach ausbleibendem Symptom. |
| „Self-Driving ist überall aus.“ | Falsch | Port Stuck und Intermittent WAN Connectivity sind standardmäßig aktiv; DFS Optimization ist aktiv und nicht deaktivierbar. |
| „AI Validated bedeutet dauerhaft fehlerfrei.“ | Falsch | Das erkannte Symptom trat im Validierungsfenster nicht erneut auf. |
| „Jede Action beruht auf demselben Modell.“ | Falsch | Regeln, Events, Konfigurationsvergleiche, Baselines und ML-Verfahren unterscheiden sich. |
| „Rogue DHCP deaktiviert auch einen Trunk.“ | Falsch | Die automatische Portdeaktivierung gilt laut Juniper für Access-Ports. |
| „Bad WAN Uplink umfasst weiterhin ISP DHCP.“ | Falsch | Aktuell gehört ISP ARP/DHCP zu Intermittent WAN Connectivity; Bad WAN Uplink betrifft schlechte LTE-Konnektivität. |
| „Eine verschwundene Action beweist die Root Cause.“ | Falsch | SLE, Service und technische Evidenz müssen die Wirkung bestätigen. |
Merksätze
- Actions priorisieren handlungswürdige Probleme; Alerts melden Ereignisse.
- Input Feature, Trigger Condition und Validation Time sind action-spezifisch.
- Driver Assist empfiehlt, Self-Driving führt definierte Korrekturen aus.
- Organization- und Siteberechtigungen ergeben gemeinsam den effektiven Scope.
- Ein Default ist keine universelle Freigabe.
- AI Validated ist eine beobachtete Stabilität, kein Dauerbeweis.
- Port Disable, Bounce, Upgrade und RF-Change haben verschiedene Risiken.
- Aktuelle Action-Seiten haben Vorrang vor veralteten Beschreibungen.
- Jede Action wird mit SLEs, Insights und Events verifiziert.
- Automatisierung endet mit Wirkungskontrolle und Dokumentation.
Offizielle Grundlagen
- Marvis Actions Overview and Status Filters
- Marvis Actions: An Insight into Back-End Operations
- Self-Driving Marvis Actions
- Wireless Actions
- Wired Actions
- WAN Actions
- Data Center/Application Actions
- Current Juniper Mist Product Updates
Stand der fachlichen Prüfung: August 2026. Action-Katalog, Triggerbedingungen, Validation Times, Self-Driving-Defaults, Remediations, Rollen und Subscriptions können sich ändern. Für produktive Entscheidungen gelten die aktuelle Juniper-Dokumentation, Portalansicht, Plattform, Firmware und effektive Organization-/Site-Konfiguration.