Designing Network Automation at Scale

01 - Der Automatisierungsimperativ

Mon, 10 Nov 2025 00:00:00 +0000

1. Der Automatisierungsimperativ#

“Automatisieren oder nicht automatisieren - das ist hier die Frage.”

Seit Software-Defined Networking (SDN) und DevOps aufgetaucht sind, streiten Ingenieure darüber, ob Netzwerkautomatisierung notwendig, ein Luxus oder schlicht Overengineering ist. Die Antwort? Es kommt darauf an. Hyperscaler brauchen sie: Sie haben Anfang der 2010er Jahre damit begonnen, weil sie keine andere Wahl hatten. Kleine Unternehmen benötigen möglicherweise überhaupt keine vollständige Automatisierung. Die meisten Netzwerke liegen irgendwo dazwischen. Kultur, Fähigkeiten, Tool-Reife, Geschäftsprioritäten - all das beeinflusst, wie schnell man die Automatisierung einführt. Heute fügen sich all diese Faktoren zusammen. Automatisierung wird unvermeidlich.

02 - Designprinzipien

Sun, 30 Nov 2025 00:00:00 +0000

2. Designprinzipien#

Ein Netzwerkautomatisierungsteam verbrachte sechs Monate damit, ein System zu entwickeln, auf das es wirklich stolz war. Es bezog Intent aus einem strukturierten Datenmodell, generierte Gerätekonfigurationen durch eine Templating-Engine, validierte Änderungen anhand einer Richtlinienbibliothek und übertrug sie via NETCONF mit vollständiger Rollback-Unterstützung. Architektonisch war es solide. Die Demo für die Unternehmensführung verlief gut. Dann übergaben sie es dem Netzwerkbetriebsteam.

Die Einführung blieb aus. Operatoren nutzten weiterhin die CLI. Auf die Frage nach dem Grund waren die Antworten einheitlich: “Ich weiß nicht, was es tun wird, bevor es es tut.” “Wenn etwas schiefgeht, kann ich nicht erkennen, was passiert ist.” “Ich verstehe nicht, wie man die Ausgabe liest.” Das Automatisierungsteam hatte etwas technisch Beeindruckendes, aber betrieblich Undurchsichtiges gebaut. Es gab keinen Dry-Run-Modus, keine menschenlesbare Änderungsvorschau, keinen Prüfpfad in einer für Operatoren verständlichen Sprache. Das System war eine Black Box, die Vertrauen einforderte, das es sich nicht verdient hatte. Sechs Monate Entwicklungsarbeit blieben ungenutzt.

03 - Architektonisches Denken

Wed, 10 Dec 2025 00:00:00 +0000

3. Architektonisches Denken#

Dieses Kapitel stellt das Fundament dieses Buches vor. Es erklärt, warum Sie diese Denkweise übernehmen müssen, stellt ein vom Network Automation Forum (NAF) vorgeschlagenes Referenzrahmenwerk vor und zeigt, wie Sie es in Ihren Projekten einsetzen können.

Teil 2 taucht tief in diese Themen ein. In diesem Kapitel werden wir sie nur vorstellen, um ein übergeordnetes Bild zu vermitteln, bevor wir ins Detail gehen. Das ist wichtig, weil das Gesamtbild hilft, die Zusammenhänge zu erkennen, sobald wir jeden Baustein beschreiben.

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.

Preface

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

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.

10 - Platform Engineering and CI/CD

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

11 - Scaling and Reliability

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

12 - Security, Governance and Compliance

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

13 - Der Kulturwandel

Sun, 19 Apr 2026 00:00:00 +0000

13. Der Kulturwandel#

Die Kalendereinladung traf an einem Donnerstag ein, mit dem Titel „Aktualisierung der Netzwerkteamstruktur". Jordi war seit fünfzehn Jahren Netzwerktechniker. Er hatte seinen CCIE. Er hatte drei Übernahmen überlebt, zwei NOC-Konsolidierungen und einen BGP-Routing-Vorfall, der so gravierend war, dass er zu einer internen Fallstudie wurde. Er nahm an, es handele sich um eine Personalaktualisierung.

Das war es nicht.

Sein Vorgesetzter erklärte, dass das Netzwerkteam unter Platform Engineering reorganisiert würde. Der Name des Teams würde sich zu Network Automation Platform ändern. Die Arbeit würde sich weiterentwickeln: weniger manuelle Bereitstellung, mehr Aufbau und Betrieb der Automatisierungssysteme, die die Bereitstellung übernehmen. Die neue Stellenbeschreibung war bereits verfasst. Sie trug den Titel „Network Platform Engineer".

14 - Automatisierung als Produkt

Tue, 05 May 2026 00:00:00 +0000

14. Automatisierung als Produkt#

Sechs Monate vor dem Gespräch, das die Denkweise des Teams über ihre Arbeit veränderte, hatte das Netzwerkplattformteam etwas wirklich Beeindruckendes geliefert. Zwei Jahre konsequenter Arbeit hatten eine Bereitstellungsplattform hervorgebracht, die das Onboarding von Zweigstellen von Anfang bis Ende handhabte: eine Self-Service-Schnittstelle für Standortanfragen, einen Closed-Loop-Validierungsworkflow, der Fehlkonfigurationen vor der Bereitstellung erkannte, und ein Betriebsdashboard, das den Servicezustand über dreihundert Standorte hinweg verfolgte. Das Team hatte von vierundzwanzigstündigen Änderungsfenstern auf vierzigminütige automatisierte Deployments umgestellt. Sie waren stolz darauf, und das zu Recht.

15 - Closed Loop Automation

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

16 - Self Healing Networks

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

17 - Autonomous Networks

Mon, 01 Jan 0001 00:00:00 +0000

Übersetzung in Bearbeitung. Dieses Kapitel wurde noch nicht ins Deutsche übersetzt. Bitte lesen Sie die englische Version.
💬 Found something to improve? Send feedback for this chapter

Über den Autor

Sun, 10 May 2026 00:00:00 +0000

Über Christian Adell#

Staff Network Developer bei CoreWeave | Barcelona, Spanien

Christian Adell hat seine Karriere rund um die Softwareentwicklung im Bereich Netzwerkautomatisierung aufgebaut. Er verfügt über umfangreiche Erfahrung im Design und der Implementierung von Netzwerkautomatisierungslösungen in großem Maßstab.

Kontakt#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

Veröffentlichte Bücher#

Christian ist Autor und Co-Autor mehrerer einflussreicher Bücher zur Netzwerkautomatisierung:

Network Programmability and Automation, 2nd Edition

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 2nd Edition

Vorträge und Community-Engagement#

Christian ist ein aktiver Sprecher auf großen Netzwerk- und Community-Konferenzen: