Ein Störungsorchestrator ist ein Graph mit Checkpoints, kein Skript

Warum kein Skript

Der Ablauf zur Bearbeitung einer Backbone-Störung wirkt linear - bis man ihn schreiben will. Das Monitoring legt ein Ticket an, man wertet es aus, verbindet sich mit beiden Enden der Strecke, liest Optik und Interface-Konfiguration, zieht ein Fazit, deaktiviert den Port, legt eine Aufgabe für den Außendienst an - und wartet. Das Warten dauert eine Stunde oder drei Tage, bis ein Trupp die Muffe erreicht.

Ein Skript übersteht das nicht. Es stirbt beim nächsten Deploy, und mit ihm das Wissen, dass ein Port bereits deaktiviert ist und jemand zur Reparatur unterwegs ist.

Deshalb ist das Szenario ein Zustandsgraph auf LangGraph, dessen Zustand in PostgreSQL-Checkpoints liegt. Ein Neustart ist kein Kontextverlust, sondern eine Pause: Der Prozess läuft genau an dem Knoten weiter, an dem er stehengeblieben ist.

Entscheidung 1: Das LLM greift nie auf Geräte zu

Die Versuchung, dem Modell CLI-Zugriff zu geben, ist groß - und genau das darf man nicht tun. Die Trennung ist strikt:

• deterministischer Code - NETCONF/PyEZ-Verbindungen, Parsen der Ausgaben, Anwenden der Konfiguration;
• das Modell - nur Text und ein kompakter JSON-Auszug der Diagnose, aus dem es eine Einschätzung für den Ingenieur formuliert.

Alles, was das Netz verändert, läuft durch Code, den man lesen und testen kann. Das Modell prägt Formulierungen und das Urteil „sieht nach Faserbruch aus" - nicht den commit.

Angenehmer Nebeneffekt: Ein Auszug statt roher Ausgabe-Dumps bedeutet auch um ein Vielfaches weniger Tokens.

Entscheidung 2: commit confirmed statt Hoffnung

Junos kann eine Konfiguration selbst zurücknehmen:

# der Rollback-Timer läuft auf dem Gerät selbst
cu.commit(confirm=10, comment="incident <ticket>: deactivate port")
# ... ein Ingenieur bestätigt in der Oberfläche ...
cu.commit()  # Festschreiben; ohne diesen Schritt setzt das Gerät zurück

Das verändert das Fehlermodell. Stürzt der Orchestrator ab, verliert er das Netz oder irrt er sich, kehrt der Port ohne uns in den Ausgangszustand zurück, denn der Timer lebt auf dem Gerät, nicht in unserem Prozess. Der Mensch bleibt in der Schleife: Die Bestätigung ist seine Handlung, kein Schalter in einer Konfigurationsdatei.

Entscheidung 3: zuerst Dry-Run

Die erste Projektstufe läuft bewusst ohne einen einzigen echten commit. Statt Konfiguration anzuwenden, berechnet der Orchestrator ein diff und protokolliert, was er getan hätte:

WOULD COMMIT on <device-a>:
[edit interfaces xe-0/0/0]
+   inactive: gigether-options

Langweilig - und genau deshalb wirksam. Im Dry-Run zeigt sich, woran der Parser bei untypischen Ticketbeschreibungen scheitert, wo die Diagnose ein falsches Urteil liefert und welche Gegenstellen im Inventar fehlen. Das erfährt man besser aus einem Log als aus einem Vorfall.

Was offen bleibt

Das Format der Ticketbeschreibung ist kein Vertrag - es stammt aus einer Monitoring-Vorlage und ändert sich. Der Parser ist robust gegenüber den bisher gesehenen Varianten, doch bei leerer Interface-Liste stoppt er und ruft einen Menschen, statt zu raten. Das ist wohl das Kernprinzip des ganzen Systems: Automatik darf sich weigern zu handeln.