7. Orchestrierung#

Das Netzwerkteam hatte alles richtig gemacht. Es gab eine solide Source of Truth, gut getestete Playbooks für jede Operation und ein klares Runbook zu deren Ausführung. Auf dem Papier war die Bereitstellung eines neuen VLAN-Diensts vollständig automatisiert. In der Praxis dauerte es einen halben Tag und erforderte einen bestimmten Ingenieur.

Dieser Ingenieur kannte die Reihenfolge. Zuerst die Vollständigkeit der SoT-Daten validieren. Dann das Pre-Check-Playbook ausführen. Dann die Ausgabe prüfen, nach fehlgeschlagenen Geräten suchen und entscheiden, ob man fortfahren soll. Dann das Deployment-Playbook auslösen. Dann warten. Dann das Validierungs-Playbook ausführen. Dann das ServiceNow-Ticket manuell aktualisieren. Wenn ein Gerät mittendrin fehlschlug, es zurückrollen, bevor die anderen es bemerkten. Sie hatte alles in einem Runbook, Schritt für Schritt, in einem gemeinsamen Dokument, das kein anderer vollständig verinnerlicht hatte.

Als sie in Urlaub ging, kamen Deployments zum Erliegen. Als ein Junior-Ingenieur die Abfolge versuchte und die Reihenfolge durcheinanderbrachte, befand sich das Netzwerk sechs Stunden lang in einem Teilzustand. Die Automatisierung existierte. Die Koordination war immer noch manuell.

Das ist das Problem, das dieses Kapitel löst. Orchestrierung ist der Baustein, der eine Sammlung von Automatisierungswerkzeugen in ein System verwandelt, das sich wie eines verhält. Er koordiniert die anderen Bausteine, entscheidet, wann sie ausgeführt werden, behandelt Fehler kontrolliert, verfolgt jede Entscheidung und tut all das, ohne dass ein Ingenieur in der Mitte steht und den Ablauf manuell steuert.

7.1. Grundlagen#

7.1.1. Kontext#

Jeder Baustein, den wir bisher behandelt haben, macht eine Sache gut. Die Source of Truth hält die Intention. Der Executor wendet sie an. Der Collector ruft den Zustand ab. Observability macht diesen Zustand verständlich. Jeder ist ein Spezialist, und Spezialisten brauchen einen Verbinder: etwas, das entscheidet, wann jeder handeln soll, was mit dem Ergebnis zu tun ist und wie man sich erholt, wenn etwas schiefgeht.

Dieser Verbinder ist der Orchestrator.

In Kapitel 3 haben wir ihn im Zentrum des NAF-Frameworks als den Baustein platziert, der alle anderen koordiniert. Kapitel 5 zeigte, wie der Executor Konfigurationsänderungen anwendet; Kapitel 6 zeigte, wie Observability die Ergebnisse validiert. Dieses Kapitel zeigt, wie der Orchestrator beides sequenziert und mit allem umgeht, was dazwischen schiefgehen kann.

Ohne Orchestrierung betreibt man keine Automatisierung. Man betreibt Skripte, die jemand in der richtigen Reihenfolge, zum richtigen Zeitpunkt und auf die richtige Weise aufrufen muss. Das ist Automatisierung nur dem Namen nach.

7.1.2. Ziele#

Der Orchestrator muss fünf Ziele erfüllen:

1. Multi-Block-Workflows end-to-end koordinieren. Ein Deployment ist keine einzelne Aktion; es ist eine Abfolge: Intention in der SoT validieren, Pre-Checks ausführen, Konfiguration anwenden, das Ergebnis validieren, Stakeholder benachrichtigen. Der Orchestrator hält die gesamte Abfolge zusammen.

2. Automatisch auf Ereignisse reagieren, mit oder ohne menschliche Auslösung. Eine ServiceNow-Genehmigung, ein Observability-Alert, ein geplanter Compliance-Scan: All das sollte in der Lage sein, einen Workflow auszulösen, ohne dass ein Mensch ihn manuell startet.

3. Resiliente und skalierbare Ausführung. Ein Workflow, der 800 Switches parallel berührt, muss zuverlässig abgeschlossen werden. Er muss einen Neustart überstehen. Er muss partielle Fehler behandeln, ohne die Arbeit zu verlieren, die von den erfolgreich konfigurierten Geräten geleistet wurde.

4. Manipulationssichere Sichtbarkeit bereitstellen. Operatoren müssen sehen, was gerade läuft. Prüfer müssen sehen, was letzten Monat lief, wer es ausgelöst hat, welche Version des Workflows lief und was jeder Schritt produziert hat. Beide Anforderungen müssen aus demselben System heraus erfüllt werden.

5. Workflow-Definitionen als Produktionssoftware verwalten. Ein Workflow, der auf 800 Produktions-Switches deployed, kann nicht leichtfertig geändert werden. Die Logik selbst muss persistiert, versioniert, getestet und mit derselben Disziplin in die Produktion gebracht werden, die auf jeden Code angewendet wird, der in der Produktion läuft.

7.1.3. Säulen#

Fünf Säulen stützen diese Ziele:

1. Workflow-Engine: mehrstufige Prozesse definieren, ausführen und verfolgen
2. Auslösungsschicht: manuell, geplant, ereignisgesteuert, Webhook
3. Resiliente Ausführung: Workflow übersteht Neustarts; unterstützt Wiederholung, Rollback und gleichzeitige Operationen über Hunderte von Geräten ohne Engpässe pro Gerät
4. Audit und Observability: jeder Schritt protokolliert, jede Entscheidung nachverfolgbar
5. Pipeline-Management: Workflow-Definitionen sicher in der Produktion persistieren, versionieren und befördern

7.1.4. Geltungsbereich#

Der Orchestrator koordiniert. Er handelt nicht.

Im Geltungsbereich:

• Andere Bausteine koordinieren
• Workflow-Logik und Schrittabhängigkeiten definieren
• Auslösung aus mehreren Quellen behandeln
• Ausführungszustand verfolgen und Audit-Trails erstellen
• Rollback-Entscheidungen bei fehlgeschlagenen Schritten verwalten

Außerhalb des Geltungsbereichs:

• Geräteänderungen ausführen (das ist der Executor)
• Netzwerkbetriebszustand speichern (das ist Observability)
• Netzwerkintention halten (das ist die Source of Truth)

Ein häufiger Fehler ist der Aufbau eines Orchestrators, der die Ausführungs- oder Speicherverantwortlichkeiten seiner Nachbarn dupliziert. Die Schnittstelle zwischen Bausteinen muss sauber bleiben.

Ein Orchestrator, der auch Zugangsdaten speichert, Geräteinventare verwaltet oder seine eigene Konfigurations-Engine betreibt, ist zu etwas anderem geworden. Wenn das Orchestrierungswerkzeug beginnt, Verantwortlichkeiten von anderen Bausteinen zu absorbieren, liegt ein architektonisches Kopplungsproblem vor, das später teuer zu entwirren sein wird.

7.2. Funktionalitäten#

Die fünf Ziele und Säulen werden durch fünf Kernfunktionalitäten realisiert. Jede entspricht direkt einem Ziel und seiner unterstützenden Säule:

1. Workflow-Engine: wie Workflows strukturiert sind und wie Schritte koordinieren
2. Auslösung: wie und wann Workflows starten und was der Aufrufer erlebt
3. Resilienz und Skalierung: wie Workflows bei Fehlern und in großem Umfang zuverlässig abgeschlossen werden
4. Zustand und Nachverfolgbarkeit: Ausführungszustand verfolgen und manipulationssichere Audit-Protokolle erstellen
5. Pipeline-Management: Workflow-Definitionen sicher in der Produktion persistieren und verwalten

graph LR

    subgraph Ziele
        direction TB
        A1[Multi-Block-Workflows end-to-end koordinieren]
        A2[Automatisch auf Ereignisse reagieren]
        A3[Resiliente und skalierbare Ausführung]
        A4[Manipulationssichere Sichtbarkeit und Audit]
        A5[Sichere Änderungen an Produktions-Pipelines]
    end

    subgraph Säulen
        direction TB
        B1[Workflow-Engine: definieren, ausführen, verfolgen]
        B2[Auslösungsschicht: manuell, geplant, ereignisgesteuert]
        B3[Resiliente Ausführung: dauerhaft, Wiederholung, Rollback im großen Maßstab]
        B4[Audit und Observability: jeder Schritt protokolliert]
        B5[Pipeline-Management: sicher persistieren, versionieren, befördern]
    end

    subgraph Funktionalitäten
        direction TB
        C1[Workflow-Engine]
        C2[Auslösung]
        C3[Resilienz und Skalierung]
        C4[Zustand und Nachverfolgbarkeit]
        C5[Pipeline-Management]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;

7.2.1. Workflow-Engine#

Die Workflow-Engine ist der Kern des Orchestrators. Sie definiert mehrstufige Prozesse, führt sie aus, verfolgt ihren Zustand und behandelt die Beziehungen zwischen Schritten.

Bevor es zu den Mustern geht, lohnt es sich, die vier grundlegenden Koordinationsansätze zu benennen, da diese Wahl alles andere prägt.

7.2.1.1. Koordinationsansätze#

• Monolith (imperatives Programm): Ein einzelnes Python-Skript ruft jeden Schritt der Reihe nach auf, wartet auf jedes Ergebnis und entscheidet, was als nächstes zu tun ist. Einfach zu schreiben, und viele Teams beginnen hier. Das Problem ist die Dauerhaftigkeit: Wenn das Skript bei Schritt 5 von 10 abstürzt, startet man von vorne. Zwischen den Läufen gibt es keinen persistierten Zustand. Man kann Schritte auch nicht parallelisieren, ohne selbst Threading-Logik zu schreiben. Es funktioniert für kleine, schnelle Operationen; es versagt unter Last und unzuverlässiger Infrastruktur. In der Praxis ist das bereits das, was der Executor-Baustein bietet: ein von einem Operator aufgerufenes Skript. Es Orchestrierung zu nennen, ist großzügig.

• Workflow (DAG-basiert): Hier beginnt Orchestrierung wirklich. Schritte werden als gerichteter azyklischer Graph (Directed Acyclic Graph) definiert, wobei jeder Knoten eine Aufgabe ist und Kanten Abhängigkeiten ausdrücken. Die Engine verfolgt den Zustand pro Knoten: Bei einem Neustart nach einem Absturz werden nur die fehlgeschlagenen oder unvollständigen Schritte erneut ausgeführt. Parallelität ist eingebaut: Unabhängige Zweige werden gleichzeitig ausgeführt. Dies ist der dominante Ansatz für Produktionsorchestierung und am bewährtesten für Netzwerkautomatisierung. Tools in dieser Kategorie umfassen Prefect, Temporal und AWX-Workflow-Templates.

• Choreographie (ereignisgesteuert, ohne zentralen Koordinator): Es gibt keinen Orchestrator. Jede Komponente reagiert auf Ereignisse, die von anderen veröffentlicht werden: Der Executor veröffentlicht “Deployment abgeschlossen”, das Observability-System konsumiert es und führt eine Validierung durch, das Benachrichtigungssystem konsumiert das Validierungsergebnis. Die Kopplung zwischen Komponenten ist lose, was es einfach macht, neue Konsumenten hinzuzufügen. Der Nachteil: Es gibt keinen einzelnen Ort, um den vollständigen Workflow-Zustand zu verstehen. Das Debuggen systemübergreifender Fehler erfordert die Korrelation von Ereignissen aus mehreren Systemen. Dieser Ansatz funktioniert für einfache reaktive Muster, skaliert aber bei steigender Komplexität schlecht.

• Agentisch (Wahrnehmen-Denken-Handeln-Schleife): Ein Large Language Model (LLM) oder KI-System fungiert als Logikschicht. Der Agent beobachtet den aktuellen Zustand (aus Observability oder SoT), überlegt, welche Aktion erforderlich ist, und ruft den Executor auf. Anstatt einem vordefinierten Workflow-Graphen zu folgen, trifft er Entscheidungen dynamisch zur Laufzeit. Dies ist der Ansatz, der Determinismus gegen Flexibilität eintauscht und die architektonische Grundlage für autonome Netzwerke bildet. Abschnitt 7.2.7 behandelt ihn ausführlich; Kapitel 17 erweitert ihn zur vollständigen Autonomie.

Die meisten Teams beginnen mit dem Monolith-Ansatz und wechseln zum Workflow-Ansatz (DAG-basiert), wenn ihre Automatisierung reift. Choreographie ist selten die richtige Wahl für den Netzwerkbetrieb, weil Audit- und Nachverfolgbarkeitsanforderungen einen zentralen Koordinator wertvoll machen. Agentische Ansätze sind real, aber noch nicht der Standard für produktiven Netzwerkbetrieb.

7.2.1.2. Workflow-Muster#

Innerhalb des DAG-basierten Ansatzes decken vier Muster die meisten realen Netzwerkautomatisierungs-Workflows ab:

• Sequenziell: Schritte laufen nacheinander; jeder hängt davon ab, dass der vorherige erfolgreich abgeschlossen wurde. Geeignet, wenn eine strikte Reihenfolge erforderlich ist: Intention validieren, dann Pre-Check, dann ausführen, dann verifizieren.

• Parallel (Fan-out/Fan-in): Mehrere unabhängige Schritte werden gleichzeitig ausgeführt. Ein Fan-out-Schritt startet viele parallele Aufgaben (eine pro Gerät oder eine pro Gebäude); ein Fan-in-Schritt wartet, bis alle abgeschlossen sind, bevor er fortfährt. Unverzichtbar für Operationen über Hunderte von Geräten: Ohne Fan-out dauert eine 10-Sekunden-Operation pro Gerät über 800 Geräte sequenziell mehr als zwei Stunden.

• Bedingtes Verzweigen: Der gewählte Pfad hängt vom Laufzeitzustand ab. Hat der Pre-Check bestanden? Zweig zur Ausführung. Hat er versagt? Zweig zum Abbruch und zur Benachrichtigung. Die Workflow-Definition enthält Entscheidungsknoten, die Ergebnisse auswerten und den nächsten Schritt wählen.

• Saga-Muster (Saga Pattern): Für lang laufende Workflows fügt das Saga-Muster jedem Schritt kompensierende Transaktionen hinzu. Wenn Schritt N fehlschlägt, führt der Workflow kompensierende Aktionen für die Schritte N-1 bis 1 in umgekehrter Reihenfolge aus und bringt das System in einen bekannt-guten Zustand zurück. So funktioniert Rollback auf Orchestrierungsebene: nicht durch erneutes Ausführen des gesamten Workflows, sondern durch Ausführen des Gegenstücks jedes Schritts, der erfolgreich war.

flowchart TD
    subgraph Sequenziell
        S1[Schritt A] --> S2[Schritt B] --> S3[Schritt C]
    end

    subgraph FanOut["Fan-out und Fan-in"]
        F0[Start] --> F1[Gerät 1]
        F0 --> F2[Gerät 2]
        F0 --> F3[Gerät N]
        F1 --> FJ[Fan-in]
        F2 --> FJ
        F3 --> FJ
    end

    subgraph Saga["Saga - Rollback bei Fehler"]
        P1[Schritt 1] --> P2[Schritt 2] --> P3[Schritt 3]
        P3 -- Fehler --> R3[Rollback 3]
        R3 --> R2[Rollback 2]
        R2 --> R1[Rollback 1]
    end

Das Saga-Muster ist auch die strukturelle Grundlage für progressive Rollouts: Netzwerkänderungen in Wellen statt alle auf einmal zu deployen. Welle 1 deckt eine kleine Testpopulation ab; wenn sie erfolgreich ist, weitet der Workflow auf Welle 2 aus, dann auf Welle N. Wenn eine Welle fehlschlägt, kompensiert der Rollback nur diese Welle. Dies ist das Netzwerkäquivalent eines Canary-Deployments: dieselbe kontrollierte Beförderungsdisziplin, die Software-Teams auf Code-Releases anwenden, auf Netzwerkänderungen angewendet.

7.2.1.3. Abhängigkeitsmanagement#

Workflow-Schritte existieren selten isoliert. Die Engine muss drei Arten von Abhängigkeiten ausdrücken und durchsetzen:

• Datenabhängigkeiten: Aufgabe B kann erst starten, wenn Aufgabe A abgeschlossen ist und ein Ergebnis produziert hat, das B konsumiert. Die Engine übergibt Ausgaben zwischen Schritten als strukturierte Daten. In der Praxis bedeutet das, dass der Pre-Check-Schritt die Liste der erreichbaren Geräte an den Ausführungsschritt übergibt, anstatt sie von Grund auf neu abzufragen.

• Mehrfach-Eingabe-Abhängigkeiten (Fan-in): Ein Schritt wartet auf mehrere parallele Zweige, bevor er fortfährt. Die Engine hält den Zustand für jeden Zweig und löst den Join-Schritt nur aus, wenn die konfigurierte Abschlussrichtlinie erfüllt ist: alle abgeschlossen, oder N von M, oder erster Erfolg.

• Externe Abhängigkeiten: Manchmal kann ein Schritt nicht fortfahren, bis etwas außerhalb des Systems passiert. Ein Änderungsfenster öffnet sich. Ein Mensch genehmigt. Ein Gerät wird nach einem Neustart wieder erreichbar. Die Engine muss Wartezustände mit konfigurierbaren Timeouts und definierten Eskalationspfaden unterstützen, für den Fall, dass das Warten nie endet.

7.2.2. Auslösung#

Ein Workflow muss irgendwie starten. Die Auslösung beantwortet zwei Fragen: Was bewirkt, dass ein Workflow beginnt, und was erlebt der Aufrufer danach.

Wie sich Auslösung von Kapitel 5 unterscheidet: In Kapitel 5 bezog sich Auslösung darauf, wie ein Operator oder System die Ausführungs-Engine direkt aufruft: ein API-Aufruf an AWX, ein Template-Start über die Command Line Interface (CLI). Das ist Auslösung auf Ausführungsebene. Hier beschreibt Auslösung, was den Orchestrator veranlasst, einen Workflow zu starten, der seinerseits den Executor als einen von mehreren Schritten aufrufen kann. Der Orchestrator empfängt den Auslöser und entscheidet, welchen vollständigen Workflow er ausführt. Der Executor führt einfach aus, was der Orchestrator ihm aufträgt.

7.2.2.1. Auslösungsmodi#

Vier Modi decken das gesamte Spektrum von menschlich bis vollständig automatisiert ab:

• API-Aufruf: Der Orchestrator stellt einen HTTP-Endpunkt bereit. Ein Operator ruft ihn manuell auf, ein UI-Button ruft ihn auf, oder ein externes System (ServiceNow, Nautobot, eine CI/CD-Pipeline) ruft ihn auf, wenn ein Ereignis eintritt. Das ist derselbe Mechanismus: Was sich unterscheidet, ist, wer den Aufruf initiiert und ob er strukturierte Ereignisdaten trägt. Geeignet für jede Änderung, die jetzt starten muss, unabhängig davon, ob der Initiator ein Mensch oder ein System ist.

• Geplant: Ein Cron-ähnlicher Zeitplan startet einen Workflow zu einem konfigurierten Zeitpunkt. Nächtliche Compliance-Scans, wöchentliche Firmware-Audits, monatliche Kapazitätsberichte. Die meisten Orchestratoren unterstützen dies nativ; einige Teams verwenden einen externen Scheduler und rufen die Orchestrator-API auf.

• Message-Queue: Der Orchestrator konsumiert Nachrichten aus einer Queue (Kafka, NATS, RabbitMQ) und startet pro Nachricht einen Workflow. Dadurch wird der Ereignisproduzent vom Orchestrator entkoppelt: Der Produzent veröffentlicht und macht weiter; der Orchestrator verarbeitet in seinem eigenen Tempo. Geeignet für Ereignisströme mit hohem Volumen, bei denen Zustellungsgarantien direkter API-Aufrufe unzureichend sind.

Die Wahl zwischen Push (API-Aufruf) und Pull (Message-Queue, geplant) hängt vom Volumen und der Kopplungstoleranz ab. API-Aufrufe sind einfacher, erfordern aber, dass der Sender den Endpunkt des Orchestrators kennt. Message-Queues skalieren besser für Hochvolumen-Streams, erfordern aber zusätzliche Infrastruktur.

7.2.2.2. Antwortvertrag#

Sobald ein Workflow startet, muss der Aufrufer wissen, was er zurückerwarten kann:

• Synchron: Der Aufrufer wartet, bis der Workflow abgeschlossen ist, und erhält das Ergebnis direkt. Geeignet für kurze Operationen (unter 30 Sekunden), bei denen der Aufrufer das Ergebnis zum Fortfahren benötigt. Die meisten interaktiven Anwendungsfälle beginnen hier und stellen fest, dass sie darüber hinausgewachsen sind, wenn sie versuchen, ein 10-minütiges Deployment auszuführen und der API-Client ein Timeout hat.

• Asynchron: Der Aufrufer erhält sofort eine Workflow-Lauf-ID und fragt den Status ab oder registriert eine Callback-URL, um das Ergebnis bei Abschluss zu erhalten. Erforderlich für jeden Workflow, der mehr als eine Handvoll Geräte berührt. Dies hat direkte Auswirkungen darauf, wie das System den Status anzeigt: Die Präsentationsschicht (Kapitel 8) muss Status-Endpunkte und Push-Benachrichtigungen bereitstellen, da Benutzer Workflows von irgendwo ausgelöst haben und eine Möglichkeit brauchen, sie zu verfolgen, ohne eine offene HTTP-Verbindung aufrechtzuerhalten.

• Hybrid: Der Workflow startet asynchron, aber der Aufrufer kann bei Bedarf optional auf einem Sync-Wait-Endpunkt blockieren. Ein Komfortmuster, das Aufrufer davon befreit, sich vorab zu entscheiden.

Idempotenz in ereignisgesteuerten Workflows: Wenn Observability einen Alert auslöst oder ein SoT-Änderungsereignis auslöst, können mehrere Systeme gleichzeitig reagieren. Derselbe Alert kann zweimal ausgelöst werden; eine Message-Queue kann dieselbe Nachricht mehr als einmal zustellen. Jeder ereignisgesteuerte Workflow muss idempotent sein: ihn zweimal gegen dieselbe Eingabe auszuführen muss dasselbe Ergebnis produzieren wie einmal. Auf Orchestrierungsebene erfordert dies typischerweise einen Deduplizierungsschlüssel: einen eindeutigen Bezeichner, den der Orchestrator prüft, bevor er einen neuen Lauf startet. Wenn ein Lauf mit diesem Schlüssel bereits existiert und noch läuft, wird das Duplikat abgelehnt oder in eine Queue gestellt. Das klingt einfach und ist überraschend leicht in der Praxis falsch zu machen.

Das Closed-Loop-Muster (Closed-Loop Pattern): Observability erkennt eine Drift-Bedingung (eine Gerätekonfiguration ist von der Intention abgewichen). Es sendet einen Alert an den Orchestrator über die oben genannten Auslösungsmechanismen. Der Orchestrator startet einen Behebungs-Workflow: fragt die SoT nach dem erwarteten Zustand, ruft den Executor auf, um das Gerät zu korrigieren, und führt dann erneut eine Observability-Prüfung durch, um die Korrektur zu bestätigen. Wenn die Prüfung besteht, schließt sich die Schleife. Wenn sie fehlschlägt, eskaliert der Orchestrator. Dieses Muster ist die Grundlage der selbstheilenden Automatisierung und wird ausführlich in Kapitel 15 behandelt. Die Schleife funktioniert nur, wenn Orchestrator, Observability und Executor ausreichend entkoppelt sind, damit jeder seine Rolle unabhängig spielen kann.

7.2.3. Resilienz und Skalierung#

Das ist es, was einen Orchestrator, mit dem man prototypisiert, von einem unterscheidet, dem man um 3 Uhr morgens in der Produktion vertraut. Ein Workflow, der unter idealen Bedingungen zuverlässig läuft, sagt einem nichts darüber, ob er einen Coordinator-Neustart mitten in einem Lauf übersteht, 40 von 800 Geräten behandelt, die Pre-Checks nicht bestehen, oder kontrolliert abbaut, wenn eine Abhängigkeit nie aufgelöst wird. Beim nächsten Test des Orchestrators wird es keine Demo sein.

Resilienz auf der Ausführungsebene, behandelt in Kapitel 5, befasst sich mit Idempotenz und Wiederholung auf der Ebene einzelner Geräte: Wenn ein Playbook gegen ein Gerät fehlschlägt, wird es wiederholt. Was Kapitel 5 nicht behandelt, ist die Dauerhaftigkeit auf Workflow-Ebene: Was passiert, wenn der Orchestrator selbst mitten in einem Lauf neu startet, wenn 40 von 800 Geräten Pre-Checks nicht bestehen, oder wenn eine Abhängigkeit nie aufgelöst wird und der Workflow hängt. Die Skalierung des Orchestrators selbst, einschließlich Hochverfügbarkeit, horizontaler Worker und Datenbankauslastung bei gleichzeitigen Läufen, ist eine Infrastrukturaufgabe, die in Kapitel 11 behandelt wird.

7.2.3.1. Dauerhafter Zustand#

Eine Workflow-Engine, die den Ausführungszustand im Speicher hält, verliert bei einem Neustart alles. Das ist für Skripte akzeptabel und für Produktionsorchestierung inakzeptabel. Dauerhafter Zustand bedeutet, dass der Fortschritt des Workflows den Ausfall des Orchestrators übersteht: welche Schritte abgeschlossen wurden, was sie produziert haben, welche noch ausstehen. Wenn der Orchestrator wieder online geht, setzt er dort fort, wo er aufgehört hat.

Temporal ist vollständig um diese Garantie herum aufgebaut: Es spielt die Workflow-Funktion aus ihrer Ereignishistorie beim Neustart ab, was den Zustand laufender Prozesse absturzsicher macht. AWX speichert den Job-Zustand in seiner Datenbank. Skripte speichern nichts.

7.2.3.2. Wiederholungsstrategien#

Nicht alle Fehler sind gleich. Ein Gerät, das während eines Firmware-Neustarts kurzzeitig nicht erreichbar war, sollte wiederholt werden. Ein Gerät, das einen dauerhaften Autorisierungsfehler zurückgegeben hat, sollte nicht: Wiederholung hilft nicht und kann Sperr-Richtlinien auslösen.

Die Wiederholungskonfiguration sollte unterscheiden:

• Vorübergehende Fehler: Netzwerkausfälle, API-Timeouts, temporäre Ressourcenkonflikte. Mit exponentiellem Backoff wiederholen.
• Dauerhafte Fehler: falsche Zugangsdaten, Gerät im Wartungsmodus, Konfiguration, die auf diesen Gerätetyp nicht anwendbar ist. Abbrechen und eskalieren.

Die Workflow-Definition sollte eine Wiederholungsrichtlinie pro Schritt festlegen. Ein Pre-Check-Schritt und ein Konfigurationsübertragungsschritt haben unterschiedliche Fehlersemantiken und sollten nicht dieselben Wiederholungseinstellungen teilen.

7.2.3.3. Rollback und Kompensation#

Wenn ein Deployment-Workflow auf halbem Weg fehlschlägt, hat man drei Optionen: den Teilzustand belassen, ihn manuell beheben oder ihn automatisch zurückrollen. In den meisten Netzwerkoperationen ist ein Teilzustand gefährlich: Geräte, die die neue Konfiguration erhalten haben, verhalten sich anders als Geräte, die dies nicht haben.

Das Saga-Muster löst dies, indem für jeden Schritt eine kompensierende Transaktion definiert wird. Wenn der Workflow bis Schritt N erfolgreich ist und dann fehlschlägt, führt er kompensierende Aktionen für die Schritte N-1 bis 1 in umgekehrter Reihenfolge aus. In einem VLAN-Deployment: Wenn die Konfigurationsübertragung auf 30 Geräten erfolgreich ist und beim 31. fehlschlägt, rollt das Saga-Muster die 30 erfolgreichen Übertragungen zurück, bevor es den Fehler meldet.

Das Saga-Muster erfordert, dass kompensierende Transaktionen im Voraus zur Workflow-Entwurfszeit definiert werden. Das ist anfänglich mehr Aufwand. Die Alternative ist, um 2 Uhr morgens festzustellen, dass sich das Netzwerk in einem Zustand befindet, den kein Runbook beschreibt.

7.2.3.4. Gleichzeitigkeitskontrolle#

Fan-out über 800 Geräte gleichzeitig überwältigt die meisten Ausführungsschichten. Gleichzeitigkeitskontrolle auf Orchestrierungsebene bedeutet:

• Batching: N Geräte parallel ausführen, auf den Abschluss des Batches warten, dann die nächsten N ausführen. Dies kontrolliert den Schadensradius: Wenn eine fehlerhafte Konfiguration ein Problem aufdeckt, wurden noch nicht alle 800 Geräte berührt.
• Rate-Limiting: Die Ausführungsschicht hat Grenzen; der Orchestrator muss sie respektieren. Die AWX-Queue nicht mit 800 gleichzeitigen Jobs füllen.
• Teilerfolgsschwellen: Definieren, was Erfolg im großen Maßstab bedeutet. 798 von 800 korrekt konfigurierten Geräten könnte gut genug sein, um fortzufahren; 600 von 800 sollte den Workflow stoppen und eskalieren.

7.2.3.5. Timeout und Schaltkreisunterbrecher#

Workflows, die ewig warten, sind ein Zuverlässigkeitsproblem. Jeder Schritt, der blockieren kann, braucht einen konfigurierten Timeout. Wenn der Timeout abläuft, braucht der Workflow eine definierte Aktion: eskalieren, überspringen oder abbrechen.

Das Circuit Breaker-Muster erweitert dies auf wiederholte Fehler: Wenn ein Schritt in einem Zeitfenster mehr als N Mal fehlschlägt, wird das Versuchen eingestellt und ein Alert ausgelöst. Dies verhindert, dass ein einzelnes nicht erreichbares Gerät einen Workflow stundenlang offen hält.

7.2.3.6. Resilienz über Bausteingren hinweg#

Die fünf oben genannten Muster behandeln Fehler innerhalb der eigenen Ausführung des Orchestrators: dauerhafter Zustand, Wiederholungen, Rollback, Gleichzeitigkeit, Timeouts. Aber Workflows scheitern auch an den Grenzen zwischen Bausteinen, und diese Fehler erfordern eine andere Behandlung.

Wenn der Orchestrator die SoT-API aufruft und ein Timeout erhält, ist die angemessene Reaktion eine andere als wenn der Executor einen Gerätefehler zurückgibt. Ein SoT-Timeout bedeutet, dass der Orchestrator nicht verifizieren kann, dass die Intention, die er gerade deployen möchte, aktuell ist. Mit zwischengespeicherten Daten fortzufahren birgt das Risiko, veraltete Konfiguration anzuwenden. Die korrekte Reaktion ist in der Regel abbrechen und wiederholen, anstatt mit Unsicherheit fortzufahren. Ein Präsentationsschichtereignis, das nie ankommt (der Genehmigungs-Webhook von ServiceNow), könnte bedeuten, dass die Anfrage abgelehnt wurde, die Integration defekt ist oder die Nachricht verloren gegangen ist. Diese erfordern unterschiedliche Wiederherstellungspfade: Eine fehlende Genehmigung ist kein vorübergehender Fehler, der unbegrenzt wiederholt werden sollte.

Fehler an Bausteingrenzen sollten in der Workflow-Definition explizit klassifiziert werden:

• Abhängigkeit nicht verfügbar (SoT, Observability): Der Workflow kann nicht sicher fortfahren. Sauber fehlschlagen, ein diagnostisches Ereignis ausgeben und nicht mit veralteten Daten wiederholen.
• Abhängigkeit beeinträchtigt (partieller SoT-Lesezugriff, Observability verzögert): Der Workflow kann mit expliziter Anerkennung fortfahren, dass er mit reduziertem Vertrauen operiert. Den beeinträchtigten Zustand protokollieren; nicht stillschweigend fortfahren.
• Nachgelagerter Baustein fehlgeschlagen (Executor hat Fehler zurückgegeben, Collector hat keine Daten zurückgegeben): Die oben genannten Wiederholungs- und Rollback-Muster anwenden, aber die Fehlerquelle genau klassifizieren, damit der Alert und der Audit-Eintrag den richtigen Baustein benennen.

Ein Workflow, der alle Fehler als wiederholbare Gerätefehler behandelt, wird eine defekte SoT-Integration wiederholen, bis er sein Wiederholungsbudget erschöpft und einen Bereitschaftsingenieur mit der falschen Diagnose alarmiert. Die Klassifizierung von Fehlern an Bausteingrenzen ist der Unterschied zwischen einem Workflow, der schnell fehlschlägt, und einem, der verwirrend fehlschlägt.

7.2.4. Zustand und Nachverfolgbarkeit#

Wenn um 3 Uhr morgens etwas schiefgeht, braucht man sofortige Antworten auf zwei Fragen: Was ist der aktuelle Zustand des Workflows, und wer hat ihn ausgelöst?

Wenn das Audit-Team drei Monate später Fragen stellt, muss derselbe Datensatz antworten: Was lief, welche Version der Workflow-Definition lief, was jeder Schritt als Eingabe erhalten hat, was er als Ausgabe produziert hat und was das Endergebnis war.

Das sind unterschiedliche Fragen mit unterschiedlicher Dringlichkeit, aber sie kommen aus derselben Quelle: dem Ausführungszustand des Workflows und seinem Audit-Datensatz.

Nachverfolgbarkeit ist ein übergreifendes Anliegen der gesamten Automatisierungsplattform: Die Source of Truth zeichnet jede Änderung der Intention auf; Observability zeichnet jede Änderung des Netzwerkzustands auf. Aber keiner dieser Datensätze sagt einem, wer einen Workflow initiiert hat, welche Schritte in welcher Reihenfolge liefen und was das Ergebnis verursacht hat. Nur der Audit-Datensatz des Orchestrators schließt diese Lücke. Da der Orchestrator alle anderen Bausteine koordiniert, ist seine Spur die maßgebliche Ansicht von allem, was über das gesamte Automatisierungssystem für ein gegebenes Ereignis passiert ist.

7.2.4.1. Zustand ist nicht Netzwerkzustand#

Diese Unterscheidung ist leicht zu übersehen. In Kapitel 6 bedeutete “Zustand” den Betriebszustand des Netzwerks: Interface-Zähler, BGP-Sitzungen, Gerät-CPU. In Kapitel 5 bedeutete “Zustand” die gewünschte Konfigurationsintention in der SoT. Hier bedeutet Zustand den Ausführungszustand des Workflows selbst: welche Schritte ausgeführt wurden, welche gerade laufen, welche fehlgeschlagen sind und was sie produziert haben.

Die beiden sind verwandt (ein Workflow-Schritt produziert Netzwerkzustandsänderungen, die Observability dann validiert), werden aber unterschiedlich gespeichert, unterschiedlich abgefragt und dienen unterschiedlichen Zwecken. Man darf sie nicht vermischen.

7.2.4.2. Die Workflow-Zustandsmaschine#

Jeder Workflow-Lauf durchläuft eine definierte Zustandsmaschine:

• Ausstehend: Empfangen, aber noch nicht gestartet
• Laufend: Schritte werden aktiv ausgeführt
• Erfolgreich: Alle erforderlichen Schritte wurden erfolgreich abgeschlossen
• Fehlgeschlagen: Ein Schritt ist fehlgeschlagen und der Workflow konnte nicht fortfahren
• Abgebrochen: Von einem Menschen oder einem externen Signal gestoppt

Jeder Schritt innerhalb des Workflows trägt seinen eigenen Zustand. Ein teilweise erfolgreicher Fan-out-Lauf muss genau zeigen, welche Geräte erfolgreich waren, welche fehlgeschlagen sind und welche übersprungen wurden. “Der Workflow ist fehlgeschlagen” ist ohne die gerätebezogene Aufschlüsselung nicht nützlich.

7.2.4.3. Audit-Protokollanforderungen#

Jeder Workflow-Lauf-Datensatz muss mindestens enthalten:

• Wer oder was den Lauf ausgelöst hat: menschliche Identität, Systemname, auslösende Ereignis-ID
• Wann er gestartet und wann er abgeschlossen wurde
• Welche Version der Workflow-Definition lief
• Die vollständige Eingabe, die der Workflow erhalten hat
• Die Ausgabe jedes Schritts
• Das Endergebnis

Dieser Datensatz muss manipulationssicher sein: Er kann im Nachhinein nicht bearbeitet werden. In regulierten Umgebungen ist das Audit-Protokoll des Orchestrators der Change-Management-Datensatz. Wenn dieser Datensatz verändert werden kann, ist das Change-Management-System nicht vertrauenswürdig.

Die meisten Orchestrierungswerkzeuge schreiben Audit-Protokolle in eine Datenbank, die sie selbst besitzen. Ob das ausreicht, hängt von den Compliance-Anforderungen ab. Einige Organisationen exportieren Orchestrierungs-Audit-Protokolle in ein nur-append-fähiges externes System (ein SIEM, ein Write-Once-Protokollspeicher), um Manipulationen durch jeden zu verhindern, der Datenbankzugriff hat, einschließlich Personen mit Abfragerechten auf die eigene Datenbank des Orchestrators.

7.2.5. Pipeline-Management#

Ein Workflow, der 800 Produktions-Switches konfiguriert, ist architektonisch gesehen Produktionssoftware. Die zentrale Herausforderung ist nicht nur Versionierung: Es geht darum, wie Workflow-Definitionen gespeichert, validiert und befördert werden, damit die Logik selbst so zuverlässig ist wie die Infrastruktur, die sie verwaltet.

Die Workflow-Definition kodiert Entscheidungen: welche Pre-Checks ausgeführt werden, was zu tun ist, wenn ein Gerät nicht erreichbar ist, was Erfolg ausmacht. Sie leichtfertig zu ändern, ändert, was beim nächsten Lauf mit jedem Gerät passiert, den dieser Workflow berührt.

Teams haben Produktions-Workflows stillschweigend gebrochen, indem sie die Workflow-Definition direkt in der UI des Orchestrierungswerkzeugs bearbeiteten. Niemand bemerkte es, bis der nächste Lauf einen Gerätetyp berührte, den der modifizierte Schritt nicht korrekt behandeln konnte. Die UI-Bearbeitung hatte keine Überprüfung, keinen Test, keinen Rollback-Pfad.

7.2.5.1. Strategien#

• Git-gesicherte Definitionen: Workflow-Definitionen in der Versionskontrolle speichern. Das Orchestrierungswerkzeug zieht bei der Bereitstellung aus Git, nicht aus lokalen UI-Bearbeitungen. Das gibt eine Historie, einen Überprüfungsprozess und die Möglichkeit, auf jede frühere Version zurückzugrollen.

• Blau/Grün-Pipeline-Versionen: Zwei Versionen eines Workflows in der Produktion aufrechterhalten: die aktuelle stabile Version, die alle aktiven Workflows behandelt, und eine neue Version, die nach einer Validierungsperiode neue Läufe erhält. Der Traffic wechselt erst, wenn die neue Version als stabil gilt.

• Canary-Rollout: Eine neue Workflow-Version behandelt zunächst eine kleine Anzahl von Läufen. Ein Firmware-Upgrade-Workflow könnte die neue Version auf 10 Geräte anwenden, bevor er sie auf die gesamte Flotte befördert. Probleme werden bei 10 Geräten sichtbar, nicht bei 800.

7.2.5.2. Orchestrierungsänderungen testen#

Workflow-Definitionen können vor der Produktion getestet werden:

• Dry-Run-Modus: Den Workflow gegen echte Eingaben ausführen, aber die Schritte überspringen, die das Netzwerk modifizieren. Überprüfen, ob die Logik die erwartete Aktionsabfolge produziert.
• Staging-Umgebung: Eine Teilmenge von Geräten, die ausschließlich zum Testen von Workflow-Änderungen vor deren Produktionsausführung vorgesehen ist.
• Shadow-Ausführung: Die neue Version parallel zur aktuellen Version ausführen, aber ihre Ergebnisse ignorieren. Ausgaben vergleichen, um Abweichungen zu erkennen, bevor umgestellt wird.

Zwei verschiedene Rollbacks: Das Zurückrollen eines Workflow-Laufs bedeutet das Rückgängigmachen der Netzwerkänderungen, die durch eine bestimmte Ausführung vorgenommen wurden (behandelt durch das Saga-Muster in Abschnitt 7.2.3). Das Zurückrollen einer Workflow-Definition bedeutet, die Workflow-Logik auf eine frühere Version zurückzusetzen: die Git-Referenz wechseln, die Definition neu deployen, und der nächste Lauf verwendet die frühere Version. Das sind orthogonale Operationen. Wer sie verwechselt, rollt das Falsche zurück.

7.2.6. Lösungslandschaft#

Haftungsausschluss: Die hier aufgeführten Werkzeuge sind Beispiele zu Erläuterungszwecken, keine Empfehlungen. Jedes hat ein anderes Architektur- und Kompromiss-Profil. Diese gegen die Fähigkeiten des Teams, das vorhandene Tooling und die betrieblichen Rahmenbedingungen abwägen.

Der Markt für Orchestrierungswerkzeuge deckt ein breites Spektrum ab, von netzwerkspezifischen Plattformen bis hin zu allgemeinen Workflow-Engines. Die Frage ist selten “Was ist am besten”, sondern fast immer “Was passt zu unserer Betriebsweise”.

Eine architektonische Frage zieht sich durch alle diese Werkzeuge: Dient das Orchestrierungswerkzeug auch als Ausführungs-Engine, oder sind sie getrennt? AWX/AAP fasst beides in einem zusammen. Prefect, Temporal und Windmill sind Orchestratoren, die separate Ausführungswerkzeuge aufrufen (Ansible, benutzerdefinierte Skripte, APIs). Das zusammengefasste Modell ist einfacher zu betreiben; das getrennte Modell gibt mehr Flexibilität, Ausführungs-Engines unabhängig auszutauschen. Kapitel 3 stellte diesen Kompromiss unter dem Begriff minimale Kopplung vor.

Die AWX/AAP-Zeile in der obigen Tabelle verdient einen klärenden Hinweis für Teams, die sie als primäre Plattform in Betracht ziehen. AWX-Workflow-Templates sind der Orchestrator; einzelne Ansible-Job-Templates sind der Executor. Die architektonische Grenze zwischen beiden existiert, auch wenn sie innerhalb derselben Plattform laufen. Ein Team, das alle Logik in Job-Templates (den Executor) steckt und Workflow-Templates nur zum Verketten verwendet, hat effektiv einen Orchestrator aus Ausführungsprimitiven gebaut, was Sichtbarkeit, Wiederholungskonfiguration und Rollback-Optionen einschränkt. Umgekehrt nutzt ein Team, das Geschäftslogik in Workflow-Templates steckt (bedingte Verzweigung basierend auf externen Daten, dynamische Inventarauswahl), AWX als echten Orchestrator. Der Unterschied ist wichtig, weil Audit-Trail, Genehmigungsschranken und Benachrichtigungs-Hooks von AWX Workflow-Level-Features sind. Wenn die gesamte Logik in Job-Templates lebt, können diese Features ohne Umstrukturierung nicht genutzt werden. Das ist keine Einschränkung von AWX; es ist eine Folge davon, Orchestrierung nicht von Ausführung im Design zu unterscheiden.

Diese Werkzeuge überschneiden sich erheblich: Python läuft sowohl in Prefect als auch in Windmill; sowohl Prefect als auch Temporal können Ansible aufrufen. Ein grober Ausgangspunkt: Wenn das Team Ansible-first ist und minimale neue Komponenten möchte, sind AWX-Workflow-Templates die natürliche Wahl; wenn testbare, Code-first-Pipelines mit Software-Engineering-Disziplin gewünscht sind, funktionieren Prefect und Windmill mit unterschiedlichen Betriebsmodellen; wenn Dauerhaftigkeit bei partiellem Ausfall die primäre Einschränkung ist, ist das Replay-Modell von Temporal speziell dafür ausgelegt. Dies als Ausgangspunkt für die Bewertung betrachten, nicht als endgültige Antwort.

7.2.7. Der Agentische Orchestrator#

Der agentische Koordinationsansatz aus Abschnitt 7.2.1 führt ein anderes Ausführungsmodell ein: Anstatt einem vordefinierten DAG zu folgen, erhält ein Large Language Model (LLM) ein Ziel und bestimmt die Aktionsabfolge zur Laufzeit. Der Agent beobachtet den aktuellen Zustand aus den Observability- und SoT-Bausteinen, überlegt, welche Aktion die Lücke schließt, ruft den Executor auf und beobachtet erneut, um das Ergebnis zu verifizieren. Wenn das Ergebnis nicht den Erwartungen entspricht, überlegt er erneut. Die Entscheidungslogik ist nicht in einer Workflow-Definition kodiert; sie lebt in der Reasoning-Fähigkeit des Modells.

Was dies über die gesamte Automatisierungsplattform hinweg ermöglicht, ist Model Context Protocol (MCP) (Model Context Protocol). Jeder Baustein stellt einen MCP-Server bereit: eine definierte Menge von Tools, die der Agent als Teil seiner Reasoning-Schleife aufrufen kann. Der SoT-Server stellt Geräteabfragen und Intentions-Lookups bereit; der Observability-Server stellt Zustandsabfragen und Compliance-Prüfungen bereit; der Executor-Server stellt Job-Auslösung und Status-Polling bereit. Der Agent ruft diese Tools in beliebiger Reihenfolge auf, je nach Situation, ohne dass der Workflow-Autor jede mögliche Kombination vorcodiert hat.

Die architektonische Implikation ist, dass die Bausteine nichts voneinander oder vom Agenten wissen müssen. Die MCP-Schnittstelle ist der Vertrag. Die SoT, die heute REST-Aufrufe aus einem DAG-basierten Workflow beantwortet, wird MCP-Tool-Aufrufe von einem KI-Agenten ohne Modifikation beantworten. Saubere Bausteingrenzen zahlen sich hier auf eine Weise aus, die enge Kopplung nie könnte.

DAG-basierte Workflows und agentische Orchestrierung schließen sich nicht gegenseitig aus. In der Praxis sind DAG-basierte Workflows die richtige Wahl für routinemäßige, gut definierte Operationen: VLAN-Deployments, Compliance-Scans, Firmware-Upgrades. Diese sind hochfrequent, benötigen vorhersehbare Audit-Trails und sollten nicht von LLM-Reasoning abhängen. Die agentische Schicht behandelt das Neuartige: ereignisgesteuerte Behebung, Anomalieinvestigation, Situationen, bei denen die richtige Aktionsabfolge erst nach Verständnis des aktuellen Zustands bestimmt werden kann. Beide Ansätze können in derselben Plattform koexistieren, wobei der DAG zu einem agentischen Workflow routet, wenn eine Situation keinem bekannten Muster entspricht.

Dieser Abschnitt führt das Muster ein. Die vollständige architektonische Behandlung, einschließlich der Skalierung agentischer Orchestrierung zu kontinuierlichem autonomen Betrieb über das gesamte Netzwerk, befindet sich in Kapitel 17.

7.3. Implementierungsbeispiel#

7.3.1. Den Campus-VLAN-Dienst-Lebenszyklus orchestrieren#

Wir haben dasselbe Campus-Netzwerk durch Teil 2 verfolgt. In Kapitel 4 haben wir die VLAN-Dienstanfrage in Nautobot gespeichert: die VLAN-ID, das Subnetz, die Ziel-Switches und die herstellerspezifischen Konfigurationsvorlagen. In Kapitel 5 haben wir Ansible über AWX verwendet, um diese Konfiguration auf die Campus-Switches zu übertragen. In Kapitel 6 haben wir das Deployment validiert und begonnen, den Dienst zu überwachen.

Was wir nie adressiert haben, ist, wer das alles koordiniert. Jedes Kapitel hatte eine implizite Annahme: Ein Ingenieur führte jeden Schritt manuell aus. Hier machen wir das explizit und ersetzen den Ingenieur durch einen Workflow.

Das Szenario

Das Anwendungsteam hat eine Anfrage für ein neues Anwendungssegment gestellt: VLAN app-payments, Subnetz 10.22.14.0/24, deployed auf alle Access-Switches in building-b über Cisco- und Arista-Stacks. Die Anfrage wurde über ServiceNow eingereicht und hat gerade die finale Genehmigung erhalten.

Diese Genehmigung löst einen Webhook aus. Der Orchestrator empfängt ihn und startet den VLAN-Dienst-Deployment-Workflow.

Der Workflow

Wir implementieren dies als AWX-Workflow-Template, konsistent mit der bereits vorhandenen Ausführungsschicht. AWX unterstützt Workflow-Templates, die Job-Templates mit bedingtem Verzweigen und Genehmigungsschranken verketten, was für dieses Szenario ausreicht.

flowchart TD
    A[ServiceNow-Webhook\nVLAN-Anfrage genehmigt] --> B[Schritt 1: SoT validieren\nNautobot nach Gerätedatensätzen\nund VLAN-Definitionsvollständigkeit abfragen]
    B --> C{SoT-Daten vollständig?}
    C -- Nein --> Z1[Abbruch: Ingenieur benachrichtigen\nund ServiceNow-Ticket aktualisieren]
    C -- Ja --> D[Schritt 2: Fan-out Pre-Checks\nErreichbarkeit und VLAN-Zustand\nüber alle Ziel-Switches]
    D --> E{Pre-Checks bestanden?}
    E -- Fehler --> Z2[Abbruch: gerätebezogene\nFehler an ServiceNow melden]
    E -- Bestanden --> F[Schritt 3: Genehmigungsschranke\nOptionale menschliche Freigabe\nvor Produktionsausführung]
    F --> G[Schritt 4: Deployment ausführen\nAnsible-Playbook über AWX]
    G --> H[Schritt 5: Fan-out-Validierung\nObservability-Prüfung pro Switch]
    H --> I{Alle Geräte validiert?}
    I -- Vollständiger Erfolg --> J[Schritt 6: Benachrichtigungen\nServiceNow-Ticket aktualisieren\nan Slack posten]
    I -- Teilfehler --> K[Schritt 6a: Saga-Kompensation\nNur fehlgeschlagenen Bereich zurückrollen]
    K --> J

Schritt 1: SoT-Validierung

Der Orchestrator fragt Nautobot ab, um zu bestätigen, dass Gerätedatensätze und VLAN-Definition vollständig sind, bevor irgendetwas das Netzwerk berührt. Dieser Schutzschritt ist die Verantwortung des Orchestrators, nicht des Executors: Der Executor sollte gültige Eingaben erhalten, nicht mitten im Übertragen auf fehlerhafte Daten stoßen. Wenn eine Prüfung fehlschlägt, bricht der Workflow ab und aktualisiert das ServiceNow-Ticket mit der spezifischen Lücke. (Wie SoT-Validierung strukturiert ist, wird in Kapitel 4 behandelt.)

Schritt 2: Pre-Checks über Ziel-Switches (Fan-out)

Der Workflow fächert über alle Ziel-Switches parallel aus. Jeder Zweig führt einen leichtgewichtigen Pre-Check durch: Erreichbarkeit, VLAN-Tabellenzustand, verfügbare Kapazität. Der Fan-in-Schritt klassifiziert die Ergebnisse und verzweigt; der Fehlerschwellenwert ist konfigurierbar. Aus Orchestrierungsperspektive wichtig ist, dass dies ein Fan-out/Fan-in-Muster mit bedingtem Verzweigen ist, kein sequenzielles Polling. (Pre-Check-Ausführungsmuster sind in Kapitel 5.)

Schritt 3: Genehmigungsschranke

Eine optionale menschliche Freigabe vor dem Produktions-Push. Ein Ingenieur hat 30 Minuten, um zu genehmigen oder abzulehnen; ein Timeout fährt automatisch fort und wird protokolliert. Der Orchestrator hält den Workflow mit einer externen Abhängigkeit in einem Wartezustand, bis die Genehmigung eintrifft oder das Fenster abläuft.

Die Genehmigungsschranke ist eine Richtlinienentscheidung, keine architektonische. Reifestarke Teams entfernen sie oft und ersetzen menschliche Genehmigung durch automatisierte Vertrauensschwellen aus Pre-Check-Ergebnissen: Wenn die Pre-Check-Abdeckung 95% übersteigt und keine kritischen Fehler gefunden wurden, automatisch fortfahren. Teams, die noch Vertrauen aufbauen, behalten die Schranke. Beide Entscheidungen sind auf verschiedenen Punkten des in Kapitel 1 diskutierten Automatisierungsreife-Spektrums gültig.

Schritt 4: Deployment-Ausführung

Der Orchestrator löst das AWX-Job-Template aus Kapitel 5 aus, übergibt die Parameter aus dem SoT-Validierungsschritt und wartet auf das Ergebnis. Der Executor erledigt den Rest. Das ist die Trennung der Verantwortlichkeiten in der Praxis: Der Orchestrator entscheidet zu handeln, der Executor handelt.

Schritt 5: Observability-Validierung (Fan-out)

Nach dem Deployment führt ein zweiter Fan-out pro Ziel-Switch einen Validierungs-Job aus: Erscheint das VLAN in der VLAN-Tabelle, befinden sich die Interfaces im erwarteten Zustand? Der Fan-in klassifiziert die Ergebnisse: vollständiger Erfolg, Teilerfolg oder Fehler. (Was die Observability-Schicht validiert und wie, wird in Kapitel 6 behandelt.)

Schritt 6: Ergebnis-Routing

Vollständiger Erfolg schließt den Workflow: Das ServiceNow-Ticket wird aktualisiert und eine Zusammenfassung an Slack gepostet. Teilfehler löst Saga-Kompensation aus: Das Rollback-Playbook läuft nur für die Geräte, die die Validierung nicht bestanden haben; Geräte, die erfolgreich waren, behalten ihre Konfiguration. Das ServiceNow-Ticket zeichnet das gerätebezogene Ergebnis auf.

Zurück zum Ingenieur vom Anfang

Dieser Workflow zeigt alle sieben Bausteine des NAF-Frameworks aus Kapitel 3, die zusammenarbeiten: Nautobot (Source of Truth) lieferte die Intention, AWX (Executor) wendete sie an, Prometheus (Observability) validierte das Ergebnis, das AWX-Workflow-Template (Orchestrator) koordinierte die gesamte Abfolge, und ein ServiceNow-Webhook (Präsentation, behandelt in Kapitel 8) löste den gesamten Ablauf aus der Anfrage des Anwendungsteams aus.

Der Ingenieur aus der Eröffnungsgeschichte ist noch immer da. Sie ist diejenige, die die Genehmigungsschranke prüft, wenn sie ausgelöst wird. Sie ist diejenige, die den Teilfehler untersucht, den das Saga-Muster markiert, aber nicht vollständig lösen konnte. Sie ist immer noch die Expertin. Was der Orchestrator ihr abgenommen hat, ist nicht das Fachwissen, sondern die Last, die Abfolge im Kopf zusammenzuhalten, sie Schritt für Schritt erneut auszuführen und die einzige Person zu sein, die das konnte. Das ist der wahre Preis von Koordination ohne Automatisierung.

7.4. Zusammenfassung#

Dieses Kapitel hat festgestellt, dass der Orchestrator der Baustein ist, der eine Menge funktionierender Automatisierungswerkzeuge in ein System verwandelt, das sich wie eines verhält. Ohne ihn bleibt die Koordination manuell, Fehler erfordern menschliche Eingriffe, und die Netzwerkgröße wird zur Grenze dafür, wie viel Automatisierung tatsächlich möglich ist.

Im Kern basiert Orchestrierung auf einer Workflow-Engine, die definiert, wie mehrstufige Prozesse strukturiert und ausgeführt werden. Die Wahl zwischen Monolith, DAG, Choreographie und agentischer Koordination ist eine architektonische Entscheidung, keine Werkzeugpräferenz. Das DAG-Modell mit seinen benannten Mustern (sequenziell, Fan-out, bedingt, Saga) ist der Produktionsstandard für Netzwerkautomatisierung. Das agentische Muster, eingeführt in Abschnitt 7.2.7 mit Model Context Protocol (MCP) als Schnittstellenschicht, stellt einen anderen Kompromiss dar und erhält seine vollständige Behandlung in Kapitel 17.

Auslösung definiert, wie die Außenwelt den Orchestrator erreicht. Die Unterscheidung zwischen Auslösung auf Ausführungsebene (Kapitel 5) und Auslösung auf Orchestrierungsebene ist architektonisch wichtig: Eine treibt eine einzelne Geräteänderung, die andere treibt einen koordinierten Multi-System-Workflow. Ereignisgesteuerte Automatisierung und das Closed-Loop-Muster erben die nicht verhandelbaren Eigenschaften Idempotenz und Deduplizierung genau deshalb, weil automatisierte Auslöser ohne menschliche Überprüfung feuern.

Resilienz und Skalierung trennen Automatisierung, die in Demos funktioniert, von Automatisierung, die um 3 Uhr morgens funktioniert. Dauerhafter Zustand, Wiederholungsstrategien, die vorübergehende von dauerhaften Fehlern unterscheiden, das Saga-Muster für Teilfehler-Kompensation und Gleichzeitigkeitskontrollen für große Gerätepopulationen sind keine optionalen Features, die später hinzugefügt werden können. Sie definieren, ob dem Orchestrator vertraut werden kann, wenn die Bedingungen nicht ideal sind.

Zustand und Nachverfolgbarkeit liefern den Datensatz darüber, was lief, wer es ausgelöst hat und was jeder Schritt produziert hat. Dieser Datensatz unterscheidet sich vom Netzwerkbetriebszustand (Kapitel 6) und der Netzwerkintention (Kapitel 4). Manipulationssichere Audit-Protokolle sind eine Compliance-Anforderung, kein Nachgedanke. Pipeline-Management schließt den Kreis: Workflow-Definitionen sind Produktionssoftware und müssen mit derselben Disziplin versioniert, getestet und befördert werden wie jeder andere Code, der auf der Automatisierungsplattform läuft.

Das Campus-VLAN-Dienst-Szenario brachte diese fünf Funktionalitäten zusammen: Ein zehnstufiger Workflow, ausgelöst durch einen ServiceNow-Webhook, koordinierte SoT-Validierung, Pre-Checks, Ausführung, Observability-Validierung und Saga-Kompensation, ohne einen Ingenieur in der Koordinationsschleife. Die naheliegende nächste Frage ist, wer diesen laufenden Workflow sieht und wie das Anwendungsteam, das ihn ausgelöst hat, seinen Fortschritt verfolgt. Das ist die Präsentationsschicht, behandelt in Kapitel 8.

💬 Found something to improve? Send feedback for this chapter