Was ist die eigentliche Schwierigkeit? Ein Testnetz mit drei sauber dokumentierten Geräten zu automatisieren, ist keine Kunst. Ein gewachsenes Kundennetz mit Geräten verschiedener Generationen aus unterschiedlichen Beschaffungszyklen und/oder unterschiedlicher Hersteller (Cisco-, Nokia-, HP- und sonstiger Hardware), mit historisch gewachsenen Workarounds und mehreren Teams, die gleichzeitig Änderungen vornehmen, ist etwas völlig anderes. Genau hier hat sich in den letzten Monaten die konzeptionelle Arbeit an neops konzentriert. Wir stellten uns der Frage, welche Grundprinzipien Automation in genau diesem Umfeld überhaupt vertrauenswürdig machen.

Ein konkretes Beispiel, das auch ohne Code funktioniert. Stellen wir uns zwei Teams vor, die zur gleichen Zeit dasselbe Gerät anfassen, nicht ungewöhnlich, wenn Monitoring-Automation, Ticketing-Workflows und Menschen parallel auf dieselbe Infrastruktur zugreifen. Team A will Port 1 aktivieren, Team B will Port 2 aktivieren. Beide lesen zuerst den aktuellen Zustand, beide schreiben dann ihre Änderung zurück.

Nun ist dieses Beispiel in der Praxis eher die Ausnahmesituation. Was allerdings in den meisten Netzwerken zutrifft ist, dass mit jeder zusätzlichen Automation nicht nur die Geschwindigkeit steigt, sondern auch die Zahl gleichzeitig handelnder Akteure im Netzwerk. Ohne ein gemeinsames Sicherheitsmodell kann deshalb ausgerechnet mehr Automation zu weniger Kontrolle führen.

Für unser Beispiel heisst das: Das Problem, wenn beide Scripts auf Basis desselben, inzwischen veralteten Zustands schreiben, kann die Änderung von Team A stillschweigend wieder verschwinden - überschrieben von Team B, ohne dass irgendjemand einen Fehler sieht. Das Gerät meldet keinen Fehler. Es macht einfach etwas anderes, als beide Teams angenommen haben. In einem gewachsenen Netz mit vielen gleichzeitigen Akteuren ist das kein exotisches Randproblem, sondern ein strukturelles Risiko und es wird mit jedem zusätzlichen Automations-Layer wahrscheinlicher.

Ein weiteres Problem: Selbst wenn eine Operation technisch korrekt durchläuft, bleibt oft offen, was im Fehlerfall wirklich passiert ist. Wurden Veränderungen im Netzwerk durchgeführt oder wurde nur ein Status abgefragt? Wurde ein abgebrochener Workflow vollständig zurückgerollt? Konnte er das überhaupt, oder war der betroffene Schritt gar nicht rückgängig zu machen? Die meisten gewachsenen Skript-Sammlungen kennen nur einen Zustand für "ist schiefgegangen", unabhängig davon, ob tatsächlich etwas verändert wurde oder nicht.

Die Antwort auf beide Probleme wurde in Bern präsentiert: Netzwerkänderungen wie Datenbank-Transaktionen behandeln. Jede Änderung hat einen klar definierten Umfang, exklusiven Zugriff auf den betroffenen Kontext, und, das ist der eigentlich wichtige Punkt, eine saubere Unterscheidung zwischen zwei Arten von Fehlschlag: einem sicheren Fehlschlag, bei dem noch nichts manipuliert wurde oder der Rollback nachweislich funktioniert hat und nichts weiter zu tun ist, und einem unsicheren Fehlschlag, bei dem tatsächlich jemand hinschauen muss. Für ein Betriebsteam, das um zwei Uhr nachts einen Alarm bekommt, ist das der Unterschied zwischen "kann bis morgen warten" und "sofort eskalieren", eine Unterscheidung, die die meisten selbstgebauten Skript-Sammlungen heute nicht treffen können.

Der zweite Teil der Geschichte und für uns der eigentlich bemerkenswerte. Für AutoCon 5 in München hat Leandro Lerena diese Überlegungen zu vier zusammenhängenden "Paradigms of Trust" weiterentwickelt und dabei explizit die Brücke zum nächsten grossen Thema geschlagen: Wie lässt sich KI-Agenten kontrolliert und sicher der Zugriff auf Netzwerkinfrastruktur geben, ohne dass "Agent" zu "unkontrollierter Blindzugriff auf Produktivgeräte" wird? Bemerkenswert daran ist, dass diese "Paradigms of Trust" für alle Formen zukunftssicherer Netzwerkautomation gelten — dass sie damit auch agentenfähig wird, ist ein erfreuliches "Nebenprodukt" (die "Paradigms of Trust" und den technischen Deep Dive stellen wir nächste Woche vor).

Für uns als neops-Team erfreulich, war zudem der Rahmen, in dem das stattfand: Es war unsere allererste Einreichung bei AutoCon überhaupt, und sie wurde direkt angenommen, ins Hauptprogramm als Lightning Talk. AutoCon ist explizit als Gegenentwurf zu Vendor-Marketing positioniert, mit einem Line-up, in dem in derselben Ausgabe auch Sprecher von DE-CIX, LINX und GÉANT sowie etablierte Stimmen der Szene wie Ivan Pepelnjak und Eric Chou standen.

Das heisst konkret: Dass AutoCon den Beitrag ins Hauptprogramm aufgenommen hat, werten wir als ermutigendes externes Signal: Mit den Paradigmen, an denen wir arbeiten, liegen wir offenbar ziemlich genau am Puls dessen, was die Branche gerade tatsächlich umtreibt.

Was das für unsere Kunden bedeutet

• Weniger Risiko bei Netzwerkänderungen in komplexen, historisch gewachsenen Umgebungen. Nicht durch mehr Vorsicht, sondern durch ein Modell, das Fehlerfälle sauber klassifiziert statt sie zu vermischen.
• Nachvollziehbarkeit im Ernstfall: jede Operation lässt sich rekonstruieren (wer, was, mit welcher Absicht).
• Eine Architektur, die den kommenden Schritt, kontrollierten Einsatz von KI-Agenten in der Automatisierung, nicht nachträglich aufsetzen muss, sondern von denselben Grundprinzipien getragen wird, die heute schon menschliche und automatisierte Änderungen absichern.

Videos:

• Leandros Talk an der AutoCON 5 - München (video - youtube)
• Leandro & Andys Talk an der SwiNOG#41 - Berne (video - youtube)