Network Automation / NetDevOps & Change-Tests
NetDevOps.Ein grüner Job ist noch kein funktionierendes Netz.
Eine Pipeline soll nicht nur Befehle erfolgreich ausführen. Sie soll nachvollziehbar machen, was geändert wird und ob das Netz danach die vereinbarten Aufgaben erfüllt. Wir verbinden Review, technische Prüfungen und Betriebsfreigabe.
Leistungsumfang
Was am Ende bei Ihnen liegt.
Das Angebot passt zu Teams mit ersten Skripten oder Playbooks, denen gemeinsame Qualitätsregeln fehlen. Ebenso zu Migrationen, bei denen Vorher-Nachher-Nachweise immer wieder manuell entstehen. Ausgangspunkt sind reale Netzfunktionen: Nachbarschaften, Erreichbarkeit, Interface-Zustände oder ein definierter Anwendungspfad. Aus diesen Erwartungen entsteht der Testkatalog, nicht aus einer beliebigen Anzahl grüner Checks.
Ein nachvollziehbarer Changeweg
Branch, Review, Freigabe und Ausführung werden verknüpft. Ein Produktivlauf ist einem geprüften Codestand und einer konkreten Gerätegruppe zugeordnet; Freigaben werden nicht durch einen automatischen Merge ersetzt.
Tests auf mehreren Ebenen
Syntax, Datenregeln und Konfigurationsvorschau werden vor der Ausführung geprüft. pyATS/Genie oder passende alternative Prüfungen erfassen ausgewählte Betriebszustände vor und nach dem Change.
Aussagekräftige Abnahme
Sie erhalten definierte Erwartungen, tolerierte Änderungen und Hinweise auf fehlende Messdaten. Zeitstempel, Zielgeräte und Testergebnisse machen einen Befund wiederauffindbar, ohne Secrets in Artefakten offenzulegen.
Ein Betriebsweg für rote Tests
Wir unterscheiden Fehlkonfiguration, nicht erreichbare Geräte und Fehler im Test selbst. Stop-Regeln, Eskalation und erneute Ausführung werden mit dem Team geübt.
Der Projektweg
In drei kontrollierten Schritten.
- 01
Erwartungen formulieren
Einen Change auswählen und die betroffenen Funktionen benennen. Fachliche Abnahme und technische Messung den richtigen Verantwortlichen zuordnen.
- 02
Pipeline und Gegenproben bauen
Mit einem guten und einem absichtlich abweichenden Testfall prüfen, ob die Pipeline wirklich unterscheidet. Artefakte auf Verständlichkeit und sensible Inhalte kontrollieren.
- 03
Im Wartungsfenster anwenden
Vorherzustand erfassen, freigegebenen Change ausführen und Ergebnisse gemeinsam bewerten. Neue Erkenntnisse in Tests und Runbook übernehmen.
Was wir vorher klar vereinbaren
Ein Test kann nur bewerten, was seine Datenquelle und Erwartung abdecken. Parser-Unterstützung wird je Plattform geprüft. Keine Pipeline beweist die Funktion aller Anwendungen oder erlaubt automatisch einen Produktivchange; dafür bleiben konkrete Freigaben und Anwendungstests erforderlich.
Dokumentiertes Configlane-Lab · negative Abnahme
Wenn die Konfiguration passt, aber der Dienst nicht funktioniert.
CHG-0029 im Next-Gen-SP-Core-Lab blieb fehlgeschlagen: Die virtuellen XR-Router akzeptierten Subinterfaces, Tag-Rewrite und Pseudowire-Konfiguration, der XConnect wurde jedoch nicht operativ.
Erwartung
Ein VPWS/E-Line-Dienst auf VLAN 200 sollte den vereinbarten CE-Pfad tragen. Die Abnahme prüfte den Dienstzustand und die Erreichbarkeit aus Sicht der Endpunkte.
Beobachtung
Keine CE-Probe kam durch. Ein erfolgreicher Konfigurationslauf durfte diesen Befund nicht überstimmen; der Validator wurde nicht gelockert.
Entscheidung
Die Plattformgrenze wurde als Upgrade-Gate dokumentiert. Das Ergebnis bleibt ein gescheiterter Dienstnachweis und wird nicht als erfolgreicher Rollout gezählt.
Gut zu wissen
Ihre Fragen. Klare Antworten.
Muss unser Team dafür Softwareentwickler werden?
Nein. Der Einstieg erfolgt über überschaubare Reviews, lesbare Tests und wiederholbare Abläufe. Wir dokumentieren die notwendigen Handgriffe und üben sie an Ihrem Anwendungsfall.
Kann die Pipeline ohne Produktionszugriff testen?
Ja, Syntax, Daten und viele gerenderte Konfigurationen lassen sich offline prüfen. Ein Nachweis über den laufenden Gerätezustand benötigt dagegen eine geeignete Umgebung und freigegebene Zugänge.
Was passiert bei einem unklaren Testergebnis?
Fehlende Daten gelten nicht als Erfolg. Der Lauf erhält einen unterscheidbaren Status und eine nächste Maßnahme. Ein Mensch entscheidet anhand der vereinbarten Kriterien über Fortsetzung oder Rückfall.
Lassen Sie uns über Ihr Vorhaben sprechen
Ein paar Eckdaten reichen für den Anfang.
Sie brauchen noch kein fertiges Konzept. Wir klären Bedarf, Grenzen und einen belastbaren nächsten Schritt.
Change-Prüfung besprechenHilfreich für das erste Gespräch
- Bestehendes Git- und CI-System
- Ein repräsentativer Change mit Abnahmekriterien
- Verfügbare Testgeräte oder Laborumgebung
- Artefaktaufbewahrung und zuständige Reviewer
Bitte keine Passwörter, API-Schlüssel oder vertraulichen Netzpläne im Formular übermitteln.
Fachlich tiefer einsteigen
Von versionierter Konfiguration zum überprüften ChangeTechnischer Hintergrund: Cisco DevNet: pyATS & GenieQuelle geprüft am . Produktfunktionen und Voraussetzungen sind versionsabhängig; der Leistungsumfang wird projektspezifisch vereinbart.