Tech-Blog
Moderator Moderator , Moderator Moderator Moderator
Tech-Blog
In 5 Schritten zum automatisierten Netzwerkbetrieb (NetOps)
Nov 14, 2018

In der Sammlung von Juniper Networks 5-Schritt-Frameworks schlagen wir nun einen neuen Kurs ein. Anstatt uns auf die Netzwerkbranche wie in den 5 Schritten für Datencenter, Campus, WAN und Branch zu konzentrieren, richten wir unser Augenmerk nun auf alle Bereiche der Netzwerkautomatisierung. Diese 5 Schritte können an jeder Stelle im Netzwerk angewandt und wie eine durchsichtige Folie etwa über die 5 Schritte für Datencenter gelegt werden.

jamesDE1.png

 

 

5 Schritte weg von der Netzwerkautomatisierung

 

Manchmal klettern wir eine Leiter hoch, nur um festzustellen, dass sie an der falschen Wand steht.

 

Bei der Umsetzung der Netzwerkautomatisierung, etwas, das seit vielen Jahrzehnten verfolgt wird, drehten sich der Diskurs und die Fortschritte hauptsächlich um die Programmierbarkeit, die den Weg für NFV und SDN ebnete. All diesen Entwicklungen zum Trotz scheint die Netzwerkautomatisierung wieder in den Mittelpunkt gerückt zu sein. Wir haben festgestellt, dass das durchschnittliche Netzwerk praktisch in einer Zeitreisekapsel versiegelt war, stellt man ihn der Entwicklung der Softwaretechnik und den entsprechenden DevOps- und SRE-Bewegungen gegenüber.

 

Ganz zu schweigen, dass sich die Netzwerkautomatisierung kaum weiterentwickelt hat, da sich der Fortschritt weitestgehend auf die internen Mechanismen der Produkte beschränkt hat: Wir haben etwas autonomere Systeme; wir haben abstrahierte und aufgeständerte Systeme auf mehr Netzwerkbereichsfläche und wir haben mehr APIs erstellt, damit die Systeme automatisierbarer werden. Leider macht all diese einseitige Netzwerkautomatisierung noch kein automatisiertes Netzwerk aus.

 

Welche Veränderung ist ausgeblieben? Der verlorene Kunde und die Automationschance des Netzwerkbetriebs.

 

Die Übergabe vom Anbieter an den Kunden ist im Durchschnitt noch immer ein sehr isolierter und stürmischer Prozess. Der Netzwerkbetrieb (NetOps) fängt auf, was über die sprichwörtliche DevOps-Wand kommt, und muss es zum Laufen bringen. Dann beginnt dieselbe alte Feuerprobe der ersten Architekturarbeiten, weniger erfreulicher Verwaltungsaufgaben und anschließend unendlicher, mühevoller Arbeit und Fehlerdiagnosen mit dem einzigen Ziel, die Verfügbarkeit aufrecht zu erhalten. Unseren „Freund“, die IT-Schwerkraft, nicht zu vergessen, die eine angemessene Problemermittlung zunichte macht und stets den kleinsten gemeinsamen Nenner beschuldigt, das Netzwerk.

 

Denkt man über diese Erfahrung nach, kommt man zu dem Schluss, dass beim Netzwerkbetrieb mit Sicherheit der größte Automationsbedarf besteht, um von automatisierbar zu automatisiert zu schreiten. Selbstverständlich kann diese Metamorphose die Automation nicht im Vakuum der Technologie betrachten, sondern sollte sich mit besonderer Aufmerksamkeit der Weiterentwicklung der Mitarbeiter und Prozesse zuwenden.

 

Wo also anfangen?

 

Menschen und Prozesse zu verändern stellt sich als schwierig heraus, aber glücklicherweise gibt es einige Lichtblicke. Die DevOps-Bewegung hat sich die Lektionen der Herstellungsbranche zu eigen gemacht, um die Art der Softwareentwicklung zu revolutionieren, und jetzt machen die erfolgreichsten Netzwerkbetrieb-Teams es DevOps nach.

 

Außerdem hat sich herausgestellt, dass Netzwerkingenieure nicht gern als Entwickler bezeichnet werden, da es gerade die Entwickler mit ihren App-Teams, unterstützt durch eine zunehmend komplizierte IT, sind, die den Netzwerkingenieuren die Suppe einbrocken, welche diese dann alleine auslöffeln dürfen. Während die meisten den Begriff DevOps oder DevNetOps nicht scheuen, kann allein die Andeutung von „Entwickler“ Wutausbrüche hervorrufen und Netzwerkingenieure das Weite suchen lassen. Zudem sind die DevOps eine noch ziemlich formlose Reihe von Grundsätzen, sodass sich führende NetOps-Teams vom Site Reliability Engineering (SRE), einer präskriptiven DevOps-Implementierung, haben inspirieren lassen und ihrer transformationalen Aufgabe einen Namen gegeben haben: Network Reliability Engineering (NRE).

 

Dieses 5-Schritt-Framework zur Automatisierung von NetOps ist eine Reise zu einem eigenständigeren Netzwerk, doch vor allem eine Reise hin zu technischer Zuverlässigkeit und Einfachheit. Die Hauptrolle auf der Reise übernehmen qualifizierte Ingenieure für Netzwerkzuverlässigkeit, die Codes schreiben und Automationstools bedienen können, um die Service-Level-Ziele und Zuverlässigkeitsindikatoren zu erreichen.

 

Stellen Sie sich das Framework als eine Karte vor. Während Sie sich orientieren und Ihren Weg suchen, werden Sie feststellen, dass Fortschritt nur selten eine gerade Linie beschreibt und schon gar nicht für jeden am selben Ort beginnt. Aller Wahrscheinlichkeit nach befinden sich die meisten Netzwerker bei dem ersten Schritt, dem manuellen Betrieb, sitzen im Automation-Spiel auf der Ersatzbank und betreiben ihre Netzwerke behutsam nach dem ITIL-Buch. Aber wir sind davon überzeugt, dass Ingenieure sich dem lebenslangen Lernen verschrieben haben und ihr Stillstand bei Schritt 1 nicht aus ihrem Zögern resultiert, sondern weil sie damit beschäftigt sind, Brände zu löschen und sie erst seit dem Aufstieg von NRE in die Narration der Netzwerkautomatisierung eingebunden sind.

 

Die Bedeutung, den ersten Schritt zu überwinden, kann nicht genug betont werden, auch wenn er in der Vergangenheit beängstigend und für Ingenieure ohne Erfahrung in der Softwareentwicklung schwierig war. Aus diesem Grund bietet Juniper EngNet, NRE-Labore, ATOM, kostenlose Testversionen, gehostete Testversionen, Labore, Schulungen und Services an, um die ersten kleinen Schritte auf dem Weg zur Automatisierung zu erleichtern.

 

Sobald Sie auf dem Weg zu Schritt 2 einige NetOps-Workflows wissenschaftlich zerlegen und anschließend vormals manuelle Aufgaben mit Codes und Tools neu entwickeln, öffnen sich Ihnen ein Tor und positiver Kreislauf hin zu mehr Automatisieung. Indem Sie diese Tools suchen, teilen und verwenden, gewinnen Sie außerdem Zeit für die Automatisierung, da Sie sich mit weniger mühevollen Aufgaben herumquälen.

 

JAMESDE2.png

 

DIE SCHRITTE IM DETAIL

 

Schritt 1 - Manueller Betrieb

 

Der manuelle Betrieb ist sehr nützlich, um die Abläufe und Strukturen zu verstehen, doch für mühsame, langwierige und vor allem wiederholte Aufgaben müssen Netzwerkingenieure beginnen, ihr weitergegebenes Wissen und die Workflows zu dokumentieren und die Vorteile von deren Automatisierung zu bewerten.

 

So gehen Sie zu Schritt 2 über:

 

  • Machen Sie sich die Denkweise eines Automatisierers zu eigen. Werden Sie ein Konstrukteur und Technologe, kein Techniker.
  • Automatisieren Sie dokumentierte Workflows. An diesem Punkt kann man sich an praktisch jedem Ad-hoc-Workflow die Zähne ausbeißen, wenn neue Tools für mehr Geschwindigkeit, Skalierung und Konsistenz kodiert werden sollen.
  • Verwenden Sie die CLI-Dokumentation und informieren Sie sich darüber hinaus in der API-Dokumentation nach individuellen Systemen.
  • Suchen Sie bereits bestehende Tools und analysieren Sie diese. Und entwickeln Sie jene, die auf NetOps-Workflows angepasst und kontextabhängig sind.
  • Profitieren Sie von Abstraktionen und SDN, sodass die Automation nicht unnötigerweise auf Box-to-Box oder niedrigeren Ebenen stattfinden muss, wenn bewährte Systeme vorhanden sind. Automatisieren Sie auf deren Grundlage.

 

Schritt 2 - Automatisierung von Workflows

 

In Schritt 2 nehmen Sie dokumentierte Workflows oder deren Pseudocode und beginnen, kleine, erfolgversprechende Bereiche zu automatisieren. Der größte Nutzen ergibt sich bei wiederholten Workflows zur Fehlerbehebung, bei denen es sich eigentlich um eine frühe Form von Tests und Überprüfungen handelt, die in Schritt 3 nützlich sein werden. Schreibgeschützte Fehlerbehebungs-Workflows sind erfolgversprechender als Umkonfigurierungen, eine erneute Bereitstellung oder Schreib-Lese-Workflows. Die Automatisierung von Änderungen während Wartungsfenstern reduziert Risiken. In letzter Zeit gelten Wartungsfenster jedoch als tunlichst zu vermeidende IT-Anti-Pattern und Änderungen werden am besten mit einer verlässlichen Pipeline gehandhabt, die in späteren Schritten eingeführt wird.

 

So gehen Sie zu Schritt 3 über:

 

  • Fortschritt jenseits der Ad-hoc-Automatisierung. Beginnen Sie as-code und GitOps - entwicklertypische Verhaltensweisen - zu üben. Code bedeutet Codifizieren, nicht unbedingt Programmieren. Verwenden Sie SCM-Workflows und eine versionierte Source of Truth für alle Artefakte, Konfigurationen und Kreationen.
  • Die Konfiguration wird nicht verteilt und treibt nicht fortwährend dahin, sondern sie ist deklaratorisch und kodifiziert und ihre Änderungen werden genauso wie programmierte automatisierte Workflows überprüft.
  • Beginnen Sie, im Voraus zu denken, wie Fehler und manuelle Trigger durch Tests und Sensoren beseitigt werden können.
  • Verbinden Sie den automatisierten „then that“-Schritt 2 und zusammengefasste Aufgaben, die manuell getriggert wurden, um sie nun automatisch zu triggern. Beginnen Sie also, „if this“ zu automatisieren, um „then that“ zu triggern.
  • Verwenden Sie APIs und Daten von Systemen wie Juniper AppFormix oder anderen Telemetrie-Kollektoren und Analysesystemen für folgende Aufgaben: 1. Beobachtbarkeit und Entscheidungsfindung, Umstellung auf NRE Service-Level-Indikator-Tools; 2. proaktive Tests, anstatt dem alleinigen Vertrauen auf die reaktive Problembehebung; und 3. Automatisierung von „if this“-Sensoren.

 

Schritt 3 - Automatisierte Trigger und Netzwerke als Code

 

Neben der Bereitstellung, Skripterstellung und den Programmiersprachen lernen Sie in Schritt 3 GitOps, Versionskontrolle und Code-Überprüfung. Sie nehmen die Infrastruktur als Code wahr und denken über automatisierte Fehlerbehebung als Tests und proaktive Überprüfung. Die testgesteuerte Netzwerkautomatisierung ist von der testgesteuerten Entwicklung (Test-driven Development; TDD) inspiriert. Es reicht nicht aus, einfach Skripts auszuführen und Probleme später zu lösen. Stattdessen müssen holistische Tests entwickelt werden, die vor Ausfällen schützen.

 

Jenseits proaktiver Tests können wir proaktiv sein, indem wir einige automatisierte Maßnahmen triggern, wenn ereignisgesteuerte Frameworks von Nutzen sind. Proaktive Trigger erfordern jedoch die Entwicklung oder Verwendung von Sensoren. Sensoren basieren manchmal auf Telemetrie- und Analysesystemen, die ebenso zur Bereitstellung oder Entwicklung von Service-Level-Indikatoren nützlich sind.

 

So gehen Sie zu Schritt 4 über:

 

  • Übernehmen Sie eine QA- und Testdenkweise bei allen Änderungen, indem Sie durch Automatisierung nicht nur Einheitlichkeit, sondern auch Genauigkeit erreichen.
  • Testverfahren werden zwischen as-code und der Bereitstellung in einer Pipeline eingefügt. Genauso wie die Softwareingenieure, die eine DevOps-Pipeline verwenden, können wir dies als eine DevNetOps-Pipeline oder eine vernetzte CICD-Pipeline wie Junipers NITA-Framework
  • Geben Sie häufiger Bereitstellungen ohne lästige Wartungsfenster aus, indem Sie auf automatisierte Änderungstests vertrauen.

 

Schritt 4 - Kontinuierliche Prozesse und Pipeline

 

An dieser Stelle übernehmen die Technologie- und Automatisierungslaufzeit eine neue Rolle in der Vorproduktion, anstatt nur in der Produktion. Schritt 4 fügt eine CICD-Pipeline hinzu, um automatische Tests auszuführen.

 

Durch die kontinuierliche Integration (Continuous Integration; CI) können Sie Codeänderungen jederzeit integrieren. Diese könnten beispielsweise Programmierungsänderungen oder eine Konfigurationsänderung umfassen. Verlässliche Änderungen werden durch automatische Tests möglich. Die automatische Zusammenfassung von manchmal gleichlaufenden Veränderungen in eine gefahrlos getestete Hauptlinie und die Entwicklung der erforderlichen Artefakte für die Bereitstellung werden als kontinuierliche Bereitstellung (Continuous Delivery; CD) bezeichnet.

 

Ebenso klug ist es, die Bereitstellung selbst zu automatisieren (hier ein Beispiel), um sich der kontinuierlichen Bereitstellung (auch CD) anzunähern. Und sogar eine echte kontinuierliche Bereitstellung erfordert noch immer manuelle Einschätzungen. Diese echte kontinuierliche Bereitstellung, vor allem gemäß dem unveränderlichen Infrastrukturmuster, kann zu kontrollierten, isolierten Ausfällen führen, die einer entsprechenden Architektur und Automatisierung bedürfen, um die Verfügbarkeit aufrechtzuerhalten und damit der Traffic nicht nachlässt. Bei Microservices-Software sind Bereitstellungsmuster wie Blue-Green, Canary oder Rolling-Upgrades einfacher zu realisieren. Netzwerke hingegen sind üblicherweise weder auf solche Dinge ausgelegt noch verfügen sie über die entsprechende Architektur. Die Ausnahme bilden heutzutage einige SDN-Systeme, und redundante oder geschichtete Hardwaresysteme werden das schon bald möglich machen.

 

Jenseits von CICD erweitert Continuous Response (CR) das ereignisgesteuerte if-this then-that aus Schritt 3. Außerdem kommt CR hauptsächlich in der Produktion zum Tragen, anstatt in der Vorproduktion und in der Bereitstellung. CR mit maschinellem Lernen, Deep Learning und Big-Data-Analysen können zur Beobachtbarkeit und automatisierten Regulierung von Netzwerksystemen eingesetzt werden, um eine Optimierung und Effizienz umzusetzen, die von Menschenhand nicht möglich wäre. Lesen Sie die Juniper-Blogs über eigenständige Netzwerke für ausführlichere Informationen zu dieser Idee.

 

So gehen Sie zu Schritt 5 über:

  • Entwickeln Sie Ihre Tools und Denkweise zu NRE/SRE-Konzepten weiter
  • Die Ablaufkultur, Beobachtbarkeit und Planung ist datengesteuert
  • Versuchen Sie zu verstehen, was Effizienz, Effektivität und Zufriedenheit für Kunden bedeutet (z. B. große IT-Organisationen oder die tatsächlichen Kunden eines Dienstleisters)
  • Nutzen Sie Chaos Engineering und Experimente, um die Systemgrenzen, -beschränkungen und -abhängigkeiten zu identifizieren und Kapazitäten und What-if-Szenarien zu optimieren und einzuplanen.

 

Schritt 5 - Entwicklungsergebnisse

 

Obwohl Schritt 5 der letzte Schritt ist, gehen das kontinuierliche Lernen und Wachstum weiter. Das ermöglicht eine schnelle und sichere Wiederholung auf dem Netzwerk und die Optimierung der Prozesse, um sich auf höhere Zuverlässigkeitsmetriken und andere Ziele zu konzentrieren. Geben Sie sich nicht mit der Netzwerkverfügbarkeit zufrieden. Tauchen Sie tiefer ein und verbessern Sie stetig Ihre Fähigkeit, auf Probleme und Veränderungen zu reagieren.

 

In diesem Schritt steht das Netzwerk nicht länger im Mittelpunkt des Universums und ein auf Netzwerke spezialisierter NRE-Experte wird die Zuverlässigkeit mit Fehlerbudgets, Arbeitsbudgets und Service-Level-Indikatoren (SLI) wie jede andere SRE verwalten. Für sich selbst erreichen sie dies mit Service-Level-Zielen (Service-Level-Objectives; SLOs) und für ihre Abhängigkeiten mit Service-Level-Agreements (SLAs). Sie berücksichtigen ihre Zuverlässigkeitsabhängigkeiten. Beispielsweise können sie Zuverlässigkeitsabhängigkeiten auf Software haben, die auf Infrastruktur außerhalb ihrer Kontrolle ausgeführt wird.

 

Ein NRE hat in diesem Schritt eine globale, schichtenweise Übersicht über die einzelnen Probleme und er kennt ihre Position im Stack.

 

Mit Vereinbarungen, Automation und Kompromissen ist Zuverlässigkeit ein zu verwaltendes Ziel, das nicht unbedingt maximiert werden muss. Geschwindigkeit, Agilität, Effizienz und andere Erfolge sind für den NRE-Messer nebensächlich, der die erforderliche Zuverlässigkeit und Verfügbarkeit für andere nützliche Ersparnisse bietet.

 

Blättern Sie durch die Folien des 5-Schritt-Framework, um mehr zu erfahren. Technologen scheinen hauptsächlich von der Folie über die 5-Schritt-Tool-Umgebung gefesselt zu sein, doch um Fortschritte zu machen, geht es weniger darum, was Sie verwenden, sondern wie Sie es einsetzen.

 

Bitte schreiben Sie uns unten einen Kommentar über Ihre Fortschritte und das auf diesem Weg Erlernte. Vielen Dank im Voraus, dass Sie diese Ideen, die im Diskurs über die Automatisierung so lange gefehlt haben, mit uns teilen.