Bei DevOps für NetOps geht es um Skalierung

Und Größe führt zu Geschwindigkeit. Und Geschwindigkeit führt zum Erfolg.

Angenommen, ein Ingenieur kann eine Änderungsanforderung in zwei Stunden bearbeiten. Nehmen wir an, ein anderer Techniker kann diese Änderungsanforderung in 1,5 Stunden bearbeiten. Wenn sie zusammenarbeiten, wie lange wird es dauern, bis sie zweihundert Änderungsanforderungen bearbeitet haben?

Ja, die Antwort ist offensichtlich Bier.  

Jeder erinnert sich wahrscheinlich (mit nicht wenig Angst und Abscheu) an die berüchtigten Textaufgaben zum Thema „Eisenbahn“ oder „Gemälde“ im Mathematikunterricht, die uns etwas über Bruchzahlenbeziehungen beibringen sollten. Das war tatsächlich ihre Absicht, auch wenn viele von uns daraus eine Abneigung gegen das Malen und Bahnreisen zogen. Und viele Memes. Vergessen wir die Memes nicht.

Der Punkt ist, dass diese Art von formelhaften Messungen im Rechenzentrum, insbesondere im Netzwerk, zunehmend zur Anforderung werden. Das liegt daran, dass die Budgets begrenzt sind (ich weiß, nicht wahr? Wie verrückt ist das denn?) und Sie können nur X Ingenieure für die Arbeit Y einstellen. In einer Anwendungswelt, in der schnelle und häufige Veröffentlichungszyklen das A und O sind, ist die Anzahl der „X“, die Sie für die rechtzeitige Veröffentlichung einstellen können, begrenzt.

Aus diesem Grund ist die Skalierung ein primärer Treiber von „DevOps“ im Netzwerk, auch „NetOps“ genannt. Man geht davon aus, dass Netops durch die Anwendung der Betriebsprinzipien von DevOps auf das Netzwerk die erforderliche Betriebsgröße erreichen können, damit die Ingenieure von „X“ die Arbeit von „Y“ termingerecht und innerhalb der Budgetbeschränkungen erledigen können, selbst wenn das Verhältnis zwischen X und Y exponentiell (für Laien: wirklich unausgeglichen) ist.

Das Problem der Änderungsanforderungen ist real; es wurde von einem Netzwerktechniker vorgestellt, der mit einer steigenden Anzahl von Änderungsanforderungen konfrontiert war (definiert als „Erstellen eines Load Balancer-Endpunkts für eine Anwendung, Hinzufügen zu DNS und Erstellen einer Firewall-Regel zum Gewähren des Zugriffs“), die letztlich die verfügbaren Mitarbeiter zu überfordern drohten und gleichzeitig die Zeit bis zur Fertigstellung verlängerten.

Die Antwort lag natürlich in der Automatisierung, in der Anwendung der DevOps-Prinzipien und in der Bereitstellung einer Self-Service-Schnittstelle, über die andere Ingenieure Anfragen stellen konnten, die dann im Ticketsystem dokumentiert und über verschiedene Netzwerk- und Anwendungsdienste-APIs ausgeführt wurden.

Durch die Einführung der Automatisierung (und Orchestrierung, da der gesamte Prozess ebenfalls automatisiert wird) können die vorhandenen Ingenieure nicht nur ihre Betriebsabläufe skalieren, sondern der Prozess wird auch schneller . Die Bearbeitung eines Änderungsantrags dauert nicht mehr bis zu zwei Stunden, sondern nur noch fünf Minuten.

Ja, Sie haben richtig gelesen. Fünf Minuten statt bis zu zwei Stunden.

Dies stellt eine deutliche Geschwindigkeitssteigerung dar, die sich aus der Skalierbarkeit durch Automatisierung und Orchestrierung ergibt. Und obwohl es sich nicht um ein ehrgeiziges, das gesamte Rechenzentrum umfassendes Projekt handelt, befasst es sich doch mit einem spezifischen Problem, mit dem sowohl Ingenieure als auch Anwendungsbesitzer häufig konfrontiert sind. In diesem Fall angeblich bis zu 200 Mal pro Woche.

Genau so sollten Netops an die Automatisierung und Orchestrierung innerhalb des Produktionsnetzwerks herangehen. Das Auffinden von Aufgaben, die wiederholbar sind und vom Änderungsprüfungsgremium als trivial erachtet werden (d. h. sie sind nachweislich störungsfrei und die meisten Ingenieure können sie im Schlaf erledigen), kann zu erheblichen Skalierungsmöglichkeiten führen, die zu der Geschwindigkeit führen, die wir laut Angaben von Unternehmen und Anwendungseigentümern im Netzwerk erreichen müssen.

Durch das Ausgraben der Nuggets, die mit möglichst geringem Störungsrisiko automatisiert werden können, haben die Ingenieure mehr Zeit, sich auf die Aufgaben zu konzentrieren, die als noch nicht reif für die Automatisierung gelten. Durch diese Konzentration werden auch die Implementierungen anderer Dienste beschleunigt, da nicht mehr übermäßig viel Zeit mit einfacheren, wiederholbaren Aufgaben verbracht werden muss.

Ich kann nicht genug betonen, wie wichtig ein CPR-Ansatz für die Netzwerkautomatisierung ist: Eine konsistente, vorhersehbare und wiederholbare Automatisierung ermöglicht eine effizientere Skalierung und schnellere Bereitstellung bei geringerem Risiko von Störungen durch Fehler. Dabei handelt es sich um die Verbindung der sogenannten Betriebsmodelle „Modus 1“ und „Modus 2“, bei denen Zuverlässigkeit und Stabilität im Vordergrund stehen, Agilität jedoch dennoch erwünscht ist. Durch die Aktivierung eines CPR-Ansatzes zur Automatisierung und Orchestrierung im Netzwerk können Unternehmen die Agilität verbessern und gleichzeitig das Risiko einer Beeinträchtigung der Zuverlässigkeit eines Netzwerks, das mit der Bereitstellung sehr vieler (im Durchschnitt etwa 200) anderer Anwendungen beauftragt ist, deutlich verringern.

Rechenzentrumsnetzwerke bestehen aus veralteten und neuen Technologien und werden oft mit MacGyver-ähnlichen Techniken zusammengehalten, für die Kaugummi und eine Angelschnur erforderlich sind. Diese Netzwerke müssen gleichzeitig Anwendungen unterstützen, die seit mittlerweile 50 Jahren in Produktion sind (Mainframes gibt es immer noch) und neue Apps, die auf kaum aus der Luft gegriffener Technologie (wie Containern) basieren. Es muss alle Anwendungen bereitstellen und dies zuverlässig und sicher tun. Diese Standards können nicht zugunsten der Geschwindigkeit und Frequenz ignoriert werden, die neuere, anspruchsvollere Anwendungen erfordern.

Netops kann jedoch eine Balance erreichen, die die Koexistenz beider ermöglicht, wenn das Unternehmen diejenigen Aufgaben und Servicebereitstellungsoptionen identifizieren und automatisieren kann, die nicht störend sind und von der Änderungskontrolle und anderen Genehmigern als abhakende Aufgaben betrachtet werden.

Schließlich ändert sich unsere Lieblingsgleichung zur Ermittlung der zum Streichen eines Hauses erforderlichen Zeit dramatisch, wenn den Malern automatische Farbroller anstelle von handbetriebenen Pinseln zur Verfügung gestellt werden.

Machen Sie sich nicht so viele Gedanken über die Änderung des Netzwerks, ändern Sie stattdessen einfach die Gleichung.