Warum Full-Cycle-Rollouts in Brownfield-Netzwerken so schwierig sind

Auf dem Papier ist ein Rollout nichts weiter als eine Liste von Aufgaben:

• VRFs und VLANs definieren
• Routing aktualisieren
• Firewall-Regeln anpassen
• NAC-Richtlinien anpassen
• Objekte in IPAM und CMDB registrieren
• Monitoring und Logging hinzufügen
• Testen und abnehmen

In der Praxis lebt jeder dieser Schritte in seiner eigenen Welt. Verschiedene Teams verantworten unterschiedliche Teilbereiche des Prozesses, verschiedene Hersteller verhalten sich unterschiedlich – selbst wenn sie ähnliche Funktionen anbieten –, und Gerätefunktionen bringen jeweils eigene Verantwortlichkeiten mit sich. Externe Systeme sind sich zudem nicht immer einig, was „korrekt" überhaupt bedeutet. Dazu kommt die Historie gewachsener Brownfield-Umgebungen: Legacy-Ausnahmen, Sonderfälle, regionale Muster und Skripte, die nur noch ein einziger Ingenieur wirklich versteht. Das Ergebnis ist ein vertrautes Muster – Rollouts dauern länger als geplant, Änderungen verhalten sich von Standort zu Standort unterschiedlich, und kleine Fehler können Auswirkungen haben, die weit über das hinausgehen, was irgendjemand erwartet hätte. Teams verbringen dabei oft mehr Zeit mit Koordination als mit der eigentlichen Umsetzung, während die Unsicherheit wächst, weil niemand mehr genau sagen kann, wie der gesamte Prozess von Anfang bis Ende tatsächlich aussieht.

E2E-Automatisierung scheitert nicht, weil Menschen unvorsichtig sind. Sie scheitert, weil der Prozess selbst keinen zentralen Ort hat, an dem er existiert.

Wo herkömmliche Automatisierung an ihre Grenzen stösst

Die meisten Unternehmen setzen bereits auf eine Form der Automatisierung für ihre Rollouts: Ingenieure schreiben Ansible-Playbooks, Python-Skripte oder Vorlagen in herstellerspezifischen Controllern. Diese Tools können durchaus leistungsstark sein, gerade bei lokalen Aufgaben oder in homogenen Umgebungen.

An den Schnittstellen zeigen sich jedoch die Probleme:

• Jedes Skript trifft eigene Annahmen über den aktuellen Status.
• Es fehlt ein gemeinsames Modell für Standorte, Dienste, Zonen oder Gerätefunktionen.
• Externe Systeme wie CMDB, IPAM, NAC und Ticketsysteme bleiben isolierte Nebenkanäle.
• Prüfungen werden nachträglich aufgesetzt, statt direkt in den Ablauf integriert zu sein.
• Rollbacks funktionieren nur teilweise und versuchen oft, Dinge rückgängig zu machen, die so gar nicht mehr existieren.
• Verschiedene Teams nutzen unterschiedliche Tools, ohne dass irgendwo eine einheitliche Sicht auf das tatsächliche Geschehen entsteht.

Automatisierung ist also durchaus vorhanden – aber eben nur für Teilbereiche. Zusammengehalten wird der durchgängige Prozess nach wie vor durch Meetings, Tabellenkalkulationen und das Gedächtnis der Mitarbeitenden.

Vollständige E2E-Automatisierung setzt bei einer anderen Frage an: nicht „Wie übertragen wir Konfigurationen schneller?", sondern „Wie beschreiben, führen wir aus und wie sichern wir den gesamten Rollout als einen einzigen Prozess ab?"

Was sich durch vollständige E2E-Automatisierung ändert

Werden Rollouts als vollständige Prozesse statt als Ansammlung einzelner Aufgaben betrachtet, ändern sich drei Dinge gleichzeitig: die Technologie, die Arbeitsweise und die Erfahrung der beteiligten Personen.

Technisch

• Rollouts laufen über eine gemeinsame Workflow-Engine statt über verstreute Skripte.
• Hersteller werden zu austauschbaren Bausteinen innerhalb dieser Engine.
• Gerätefunktionen – Firewall, Router, Switch, Controller, NAC-Knoten – werden durch rollenbasierte Logik gesteuert.
• Externe Systeme wie CMDB, IPAM, NAC, DNS, Ticketing oder Monitoring sind keine „Add-ons" mehr, sondern fester Bestandteil des Ablaufs.
• Prüfungen und Tests werden direkt zusammen mit den Aktionen definiert, die sie absichern.

Prozessual

• Es gibt einen einzigen durchgängigen Prozess, auf den sich alle beziehen – nicht fünf lokale Varianten.
• Die Verantwortlichkeiten pro Schritt sind klar: Wer löst aus, wer genehmigt, wer überwacht, wer gibt frei.
• Rollbacks und Notfallpfade sind dokumentiert und jederzeit ausführbar, nicht nur theoretisch vorhanden.
• Wiederholbarkeit wird zum Standard, nicht zur Ausnahme.

Menschlich

• Ingenieure verbringen ihre Zeit mit dem Gestalten von Abläufen statt mit dem Löschen von Bränden.
• Betriebsteams gewinnen Planungssicherheit statt Überraschungen.
• Weniger Nachtschichten hängen davon ab, ob alles gut geht.
• Neue Teammitglieder verstehen den Rollout-Prozess schneller und können ihm vertrauen.

Automatisierung nimmt den Menschen dabei nicht aus dem Prozess – sie entfernt nur die Teile, die ohnehin nie auf das menschliche Gedächtnis hätten angewiesen sein dürfen.

Die Rolle von neops: eine vollständige E2E-Workflow-Engine für echte Netzwerke

neops steht im Zentrum dieses Wandels – nicht, um bestehende Tools zu ersetzen, sondern um ihnen eine gemeinsame Sprache und einen einheitlichen Prozess zu geben. Im Kern ist neops eine Workflow-Engine für den gesamten Lebenszyklus: Sie modelliert Standorte, Dienste, Zonen, Mandanten und Gerätefunktionen als Entitäten, verbindet diese mit echten Geräten und externen Systemen, führt Workflows aus, die das Verhalten eines Rollouts von Anfang bis Ende beschreiben, und hält vollständig fest, was gelaufen ist, warum es gelaufen ist und mit welchem Ergebnis. Statt für jeden neuen VRF-, VLAN-, NAC- oder IPv6-Rollout massgeschneiderte Logik zu schreiben, definieren Teams wiederverwendbare Prozesse – mit klaren Vorgaben dazu, welche Aufgaben existieren, in welcher Reihenfolge sie ablaufen, unter welchen Bedingungen sie ausgeführt werden dürfen, wie sie sich selbst validieren und wie sie sich sicher zurückrollen lassen. So wird aus verstreuten Fragmenten ein klarer, strukturierter Ablauf, den das ganze Team versteht und dem es vertrauen kann.

Idealerweise sind Workflows keine Skripte, die in einem Repository versteckt sind. Sie sind sichtbare, versionierte und überprüfbare Modelle, die für das gesamte Team einsehbar sind.

Automatisierte Validierung und Tests: integriert statt nachträglich aufgesetzt

Ein Hauptgrund, warum sich Rollouts instabil anfühlen, liegt darin, dass Validierung meist nur in den Köpfen der Mitarbeitenden oder in separaten Dokumenten existiert. Vor- und Nachprüfungen laufen „aus Gewohnheit" mit, statt fester Bestandteil des Systems zu sein. neops rückt diese Prüfungen deshalb ins Zentrum des Prozesses.

Für jeden Workflow lassen sich definieren:

• Vorbedingungen: Was muss erfüllt sein, bevor die Änderung beginnen kann?
• Laufzeitprüfungen: Was muss während der Änderung unverändert bleiben?
• Nachbedingungen: Was muss nach Abschluss der Änderung erfüllt sein?

Diese Prüfungen können Geräte, externe Systeme oder den internen Status abfragen und Soll-Werte mit dem tatsächlichen Zustand des Netzwerks vergleichen. Fehler lassen sich dabei als FAILED_SAFE (vorzeitiger Abbruch, Schutz der Umgebung) oder FAILED_UNSAFE (menschliche Entscheidung erforderlich) klassifizieren.

Das macht zwei Dinge möglich:

• Unsichere Änderungen werden blockiert, bevor sie die Produktion erreichen.
• Geht trotzdem etwas schief, ist für alle nachvollziehbar, warum sich das System so verhalten hat.

Auch beim Testen zahlt sich das aus: Workflows lassen sich in Staging-Umgebungen oder virtuellen Laboren ausführen, bevor sie je mit der Produktion in Berührung kommen. Da Logik und Prüfungen identisch sind, lässt das Verhalten im Labor deutlich präzisere Rückschlüsse auf das Verhalten im Feld zu.

Externe Systeme anbinden, ohne im Glue-Code zu versinken

Bei echten Rollouts steckt die grösste Arbeit oft ausserhalb der Geräte: in CMDB, IPAM, Ticketing, NAC, DNS, Monitoring, Service-Katalogen und mehr. Wird jedes dieser Systeme separat verwaltet, entstehen typischerweise:

• manuelle Updates, die der Realität hinterherhinken
• kleine Fehler, die sich über mehrere Tools hinweg fortpflanzen
• Berichte, denen man nie so ganz trauen kann

neops geht hier einen anderen Weg: Externe Systeme werden über eine klare API-Schicht angebunden und Teil desselben Prozessablaufs. Statt verstreuter Übergaben kann der Workflow IP-Adressen im IPAM reservieren, CMDB-Objekte aktualisieren, Tickets öffnen und schliessen, NAC-Labels anpassen und Monitoring-Metriken registrieren – alles als eine zusammenhängende Aktionskette und als Teil derselben Änderung, nicht als nachträglicher Zusatz. Schlägt der Workflow fehl, scheitern die externen Schritte mit ihm oder werden gemeinsam zurückgerollt. So entsteht ein Zustand, in dem Geräte und Systeme deutlich häufiger übereinstimmen – und wo das einmal nicht der Fall ist, wird die Diskrepanz sichtbar statt verborgen zu bleiben.

Multivendor als Normalfall, nicht als Ausnahme

Die meisten grossen Netzwerke sind historisch bedingt herstellerübergreifend gewachsen: Unterschiedliche Hardware-Generationen, Fusionen, spezifische Anwendungsfälle und Änderungen in der Beschaffung führen über die Zeit zu einem Mix an Plattformen. Herkömmliche Automatisierungsansätze bleiben dabei meist bei zwei Optionen: entweder ein eigenes Tool pro Hersteller, oder der Versuch, alles auf den kleinsten gemeinsamen Nenner zu reduzieren.

neops wählt einen anderen Weg: Die Prozesslogik bleibt herstellerunabhängig und beschreibt, was geschehen soll – nicht, wie die jeweilige Plattform das umsetzt. Herstellerspezifika stecken in wiederverwendbaren Bausteinen, die unter dem Workflow liegen.

In der Praxis heisst das:

• Derselbe Rollout-Prozess kann Cisco, Juniper, Palo Alto, Fortinet, HPE und weitere Hersteller umfassen.
• Gerätespezifische Details werden einmal erfasst, nicht für jedes Projekt neu.
• Teams denken in Begriffen wie „VRF für Dienst X an Standort Y erstellen" – nicht „diese 14 verschiedenen Templates ausführen".

Ein herstellerunabhängiger Ansatz macht grosse Rollouts wesentlich überschaubarer – besonders wenn die Brownfield-Realität komplex ist.

Ausführungssicherheit mit Core 2.0: transaktional, isoliert, überprüfbar

Bei der Sicherheit scheitert Theorie oft an der Praxis: Einen sauberen Prozess zu entwerfen ist das eine, ihm unter echtem Druck zu vertrauen etwas ganz anderes. Genau hier setzt neops Core 2.0 an. Jeder Workflow wird zu einer kontrollierten Arbeitseinheit: mit transaktionalem Verhalten, das entweder vollständig abgeschlossen wird oder den vorherigen Zustand wiederherstellt, mit isolierter Ausführung, die Kollisionen bei parallelen Änderungen verhindert, mit klaren Fehlersemantiken, die zwischen sofortigem Stopp und Situationen mit menschlichem Ermessensspielraum unterscheiden, und mit vollständigem Logging, das jede Aktion, Entscheidung und externe Interaktion festhält. Bei grossen Rollouts verändert das die Stimmung während der Wartungsfenster spürbar: Teams wissen, dass keine Teiländerungen zurückbleiben, dass Rollbacks geplant statt improvisiert erfolgen und dass die gesamte Historie der Änderung für spätere Analysen erhalten bleibt. Aus dieser Kombination wird durchgängige Automatisierung von einer Risikoquelle zu einem stabilisierenden Faktor.

Geschwindigkeit und Skalierung ohne Kontrollverlust

Sind Prozesse einmal standardisiert und Sicherheit fester Teil des Designs, wird Geschwindigkeit zum natürlichen Nebeneffekt. neops kann über verteilte Worker viele Rollouts parallel ausführen – verschiedene Standorte, Regionen oder Kundensegmente lassen sich gleichzeitig bearbeiten, jeweils nach denselben Workflows und Prüfungen. Betriebsteams sehen den Echtzeitstatus pro Standort, Region und Dienst, und Führungskräfte erkennen den Fortschritt eines Rollouts, ohne dafür einen manuellen Bericht anfordern zu müssen.

Der Projektaufwand sinkt dabei spürbar:

• weniger Koordinations-Calls
• weniger manuelle Validierungen
• weniger Überraschungen

Rollouts, die früher Monate dauerten, lassen sich so in Wochen abwickeln, manchmal sogar in Tagen – nicht, weil die Ingenieure härter arbeiten, sondern weil das System einen grossen Teil der Schwerstarbeit übernimmt.

Eine hypothetische Geschichte, die vielen bekannt vorkommen wird

Stellen Sie sich einen Provider oder ein grosses Unternehmen vor, das einen kombinierten Rollout plant: neue VRFs für Geschäftsbereiche, ein überarbeitetes VLAN-Design für die Niederlassungen und NAC-gesteuerte Zugriffskontrolle am Edge. Das Netzwerk ist ein Brownfield-Szenario mit mehreren Herstellern und einer langen Historie.

Bei einem traditionellen Vorgehen würde das Projektteam Templates für jeden Gerätetyp vorbereiten, sich mit den Firewall-, Routing-, Access- und NAC-Teams abstimmen, Tabellen zur Standortbereitschaft nachführen, CMDB- und IPAM-Einträge von Hand anpassen, Tests manuell durchführen und Cutovers standortweise planen – in der Hoffnung, dass am Ende alle Abhängigkeiten zum richtigen Zeitpunkt zusammenpassen. Jede Phase würde dabei von der persönlichen Sorgfalt Einzelner abhängen.

Mit neops läuft dieselbe Initiative anders ab. Ein durchgängiger Workflow beschreibt den gesamten Rollout von der Anforderung bis zur Validierung, während Entitäten wie Standorte, Dienste und Zonen den operativen Kontext liefern. Geräteaufgaben, Interaktionen mit externen Systemen und integrierte Prüfungen fliessen dabei in einer einzigen kohärenten Sequenz zusammen. Core 2.0 sorgt für sichere Ausführung und zuverlässige Rollbacks – und ermöglicht so, dass viele Standorte parallel vorankommen, ohne dass das Risiko steigt.

Brownfield ist Realität – aber sie bestimmt nicht mehr, wie das Unternehmen arbeiten muss.

Geschäftlicher Nutzen: Warum das für die Führungsebene wichtig ist

Aus Führungsperspektive lässt sich durchgängige E2E-Automatisierung an drei Ergebnissen festmachen:

• Stabilität: weniger Ausfälle, weniger fehlgeschlagene Rollouts, weniger Notfallkorrekturen.
• Geschwindigkeit: schnellere Service-Aktivierung, schnellere Reaktion auf geschäftliche Anforderungen.
• Verantwortlichkeit: klar nachvollziehbar, was geändert wurde, wer es geändert hat und warum.

So gewinnt der Betrieb an Ruhe, die Technik erhält Freiraum für Konzeption und Design, und das Unternehmen kann neue Dienste einführen, ohne jedes Mal vor dem nächsten Wartungsfenster zu bangen.

Fazit – von Projekten zu einem wiederholbaren Betriebsmodell

Durchgängige E2E-Automatisierung ist kein Luxus mehr. Für Netzwerke, die geschäftskritische Prozesse tragen, ist sie zur Notwendigkeit geworden. neops bietet Unternehmen einen Weg, das schrittweise zu erreichen: von verstreuten Skripten zu gemeinsamen Workflows, von manuellen Prüfungen zu integrierter Validierung, von fragilen Einzelprojekten zu einem zuverlässigen Betriebsmodell. Wenn Ihr nächster Rollout mehrere Anbieter, verschiedene Gerätefunktionen und unterschiedliche Systeme umfasst – mit anderen Worten: wenn er die Realität widerspiegelt –, lohnt sich die Frage, ob der Prozess tatsächlich so geordnet abläuft, wie es die Diagramme vermuten lassen.

Lautet die ehrliche Antwort „noch nicht", ist neops bereit, Ihnen bei dieser Veränderung zu helfen.

Nehmen Sie Kontakt mit uns auf, wir freuen uns!

‍