Part 2: Architectural Building Blocks on Designing Network Automation at Scale

04 - Source of Truth

Sun, 15 Feb 2026 00:00:00 +0000

4. Der Source of Truth#

Ein neuer Dienst musste bis Ende der Woche in Betrieb gehen. Die Änderung war unkompliziert: ein neues VLAN, ein neues Subnetz, aktualisierte Firewall-Regeln und eine neue BGP-Community auf den Edge-Routern. Der Netzwerktechniker wusste genau, was zu tun war. Was folgte, waren vier Tage Koordination über fünf Systeme hinweg: das IPAM-Tool zur Reservierung des Subnetzes, die CMDB zur Registrierung des Dienstes, die Firewall-Verwaltungsplattform zum Einreichen der neuen Richtlinie, das Router-Konfigurationssystem für die BGP-Community und die Monitoring-Plattform zum Hinzufügen der neuen Schwellenwerte. Jedes System hatte seine eigene Schnittstelle, sein eigenes Datenmodell, seinen eigenen Genehmigungsworkflow. Und da es keine gemeinsame Referenz gab, musste der Ingenieur den Kontext manuell mitführen: Werte von einem System zum nächsten kopieren und hoffen, dass zwischen den Schritten nichts abweicht.

05 - Ausführung

Sat, 01 Nov 2025 00:00:00 +0000

5. Ausführung#

Das Playbook lief seit Monaten einwandfrei: zehn Access-Switches im Labor, zwei Minuten von Anfang bis Ende, saubere Ergebnisse jedes Mal. Als das Team beschloss, es auf das vollständige Inventar von 800 Switches auszurollen, erwartete niemand Probleme. Die ersten 600 Geräte wurden ohne Zwischenfälle aktualisiert. Dann verlangsamte sich der Job. Dann stockte er. Der RADIUS-Server, der plötzlich 150 gleichzeitige SSH-Authentifizierungsanfragen erhielt, begann, Verbindungen abzulehnen. Ansible hing bei 150 Geräten mitten in der Ausführung. Ein Ingenieur beendete den Job.

06 - Observability

Mon, 12 Jan 2026 00:00:00 +0000

6. Observability#

Beim Core-Router eines Service-Providers fiel über Nacht ein Lüftermodul still aus. Es gab keine Alarme. Das Wärmemanagement-Subsystem auf den Line Cards erkannte steigende Temperaturen und begann, die Weiterleitungs-ASICs zum Schutz der Hardware zu drosseln. Der Durchsatz auf einem produktiven Transit-Link sank um 40%. Das Monitoring-System sah nichts: Die Temperatursensoren, die es abfragte, befanden sich auf dem Chassis-Supervisor, nicht auf den einzelnen Line Cards. Die SNMP-Abfragen liefen alle fünf Minuten und meldeten das Gerät als gesund. Die Interface-Counter zeigten reduzierten Durchsatz, aber für dieses Muster war kein Schwellenwert konfiguriert, weil der Link immer weit unter seiner Kapazität gelaufen war.

07 - Orchestrierung

Fri, 20 Mar 2026 00:00:00 +0000

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.

08 - Präsentation

Sat, 28 Mar 2026 00:00:00 +0000

8. Die Präsentationsschicht#

Die VLAN-Automatisierung lief seit sechs Wochen. Das Netzwerkteam war stolz darauf. Jeden Morgen trafen drei oder vier neue Serviceanfragen von Anwendungsteams ein, und der Orchestrator bearbeitete sie, ohne dass jemand im Netzwerkteam eine Tastatur berühren musste. Die Deployments funktionierten. Die Switches waren konfiguriert. Das Netzwerk war gesund.

Die Eskalation kam an einem Donnerstag. Der Anwendungsteamleiter fragte, warum VLAN-Anfragen drei bis fünf Werktage dauerten, obwohl das Portal “Eingereicht” anzeigte. Das Netzwerkteam prüfte ihre Queue: null ausstehende Anfragen, alle Deployments erfolgreich. Die Automatisierung hatte jede Anfrage innerhalb von zwanzig Minuten nach Eingang verarbeitet. Aber die ServiceNow-Tickets zeigten noch immer “In Bearbeitung”, weil niemand die Integration geschrieben hatte, die sie aktualisieren würde.

09 - Das Netzwerk

Sun, 29 Mar 2026 00:00:00 +0000

9. Das Netzwerk#

Die VLAN-Automatisierung lief drei Wochen lang im Labor. Drei Switches, je einer pro Hersteller, jeder Workflow erfolgreich. Das Team war zuversichtlich. Beim ersten Produktionslauf schlugen 23 der 800 Campus-Switches fehl. Alle HPE. Alle liefen auf einer Firmware-Version, die niemand dokumentiert hatte.

Das Playbook prüfte die Fehlerantwort jedes Geräts, nachdem die VLAN-Konfiguration übertragen worden war. Auf moderner HPE-Firmware gibt ein bereits vorhandenes VLAN den Fehlercode duplicate-vlan zurück. Auf dieser älteren Firmware-Version lieferte dieselbe Bedingung vlan-exists. Das Playbook war so geschrieben worden, dass es duplicate-vlan als Idempotenz-Signal behandelte, also als “das existiert bereits, das ist in Ordnung.” Es war nicht darauf ausgelegt, vlan-exists zu behandeln, und betrachtete diese Antwort daher als Fehler. Ein Drittel der HPE-Geräte meldete einen Fehler. Der Rollback lief sauber durch. Das Ticket des Anwendungsteams blieb weitere drei Stunden offen, während das Netzwerkteam manuell prüfte, welche Switches tatsächlich konfiguriert worden waren und welche nicht.