NetOps brauchen Fürsprecher, keine Gegner
Sie möchten gerade das Essen genießen, auf das Sie sich den ganzen Tag gefreut haben, als Sie feststellen, dass es nicht richtig durch ist. Frustriert sprechen Sie den Kellner unhöflich an und kürzen vielleicht sogar das Trinkgeld. Sie nehmen es mit einem Lächeln hin, auch wenn es nicht ihre Schuld ist. Schließlich haben sie Ihr Essen nicht zubereitet. Aber sie sind Ihre Schnittstelle zur Küche, und letztlich sind sie es, die für Fehler bezahlen, die außerhalb Ihres Blickfelds passieren.
Ob es sich um den Kellner in einem Restaurant oder einen Kundendienstmitarbeiter von <hier Dienst einfügen> handelt: Im Allgemeinen ist es die Person, die mit Ihnen kommuniziert, die die Hauptlast Ihrer Angst/Frustration/Wut tragen muss, wenn etwas schief geht.
Dies gilt auch für Rechenzentren.
Im Zuge der digitalen Transformation der IT mit dem Ziel einer stärkeren Optimierung und Geschwindigkeit sind es die NetOps-Teams, die am ehesten mit internen „Kunden“ interagieren und somit die Hauptlast verärgerter Benutzer tragen, wenn die Prozesse nicht so schnell wie gewünscht voranschreiten.
Es ist wichtig zu erkennen, dass es nicht immer „NetOps“ ist, das der Bereitstellung der neuesten Sache/App/des neuesten Dienstes im Weg steht. Geschwindigkeitshemmnisse sind häufig darauf zurückzuführen, dass Unternehmen bei der Umgestaltung ihres IT-Betriebs nicht alle DevOps-Prämissen übernehmen.
Machen Sie DevOps oder automatisieren Sie nur?
CAMS ist das am häufigsten verwendete Mittel zur Verbreitung der Kernprinzipien von DevOps. CAMS steht für: Kultur , Automatisierung , Messung und Teilen .
Von diesen vier wird die Automatisierung wahrscheinlich mit der größten Begeisterung aufgenommen. Es sind die anderen drei, die bei dem Bestreben, die Servicegeschwindigkeit innerhalb der IT zu verbessern, oft vernachlässigt oder völlig ignoriert werden.
Besonders hervorzuheben ist, dass diese drei häufig ignorierten Konzepte eng miteinander verknüpft sind. Es ist schwierig, die Kultur zu ändern, wenn die Teams immer noch nach Funktionen isoliert sind und sich auf Kennzahlen konzentrieren, die für andere Teams keine Rolle spielen. Wir arbeiten auf das hin, woran wir gemessen werden. Wenn wir an der Netzwerkverfügbarkeit gemessen werden, konzentrieren wir uns darauf – auch wenn unsere Kollegen im Betrieb versuchen, die Application zu verbessern.
Sie erinnern sich vielleicht an die Studie „State of Network Automation“, bei der wir gemeinsam mit Red Hat in die undurchsichtige Welt von DevOps, NetOps und Automatisierung eingetaucht sind. Dabei stellten wir fest, dass zwischen den von NetOps und den an Entwicklung und Betrieb Beteiligten gesuchten Metriken (Messungen) große Unterschiede bestehen.
Fast drei Viertel (73 %) der NetOps gaben die „Netzwerkverfügbarkeit“ als wichtigste Messgröße an. Auf der anderen Seite sagten uns 59 % der Entwickler und Betriebsmitarbeiter, dass die „Application “ ihr wichtigster Maßstab sei. Umgekehrt werden fast doppelt so viele Entwickler und Betriebsmitarbeiter (30 %) anhand der Bereitstellungshäufigkeit gemessen als NetOps (16 %) und Sicherheit (17 %).
Warum ist diese Ungleichheit wichtig? Wenn mein Hauptziel darin besteht, das Netzwerk verfügbar zu halten, werde ich meine Zeit darauf verwenden, mich auf das Netzwerk zu konzentrieren. Bei der Instrumentierung und Überwachung – Letzteres ist für die Sharing -Komponente von DevOps von entscheidender Bedeutung – wird der Schwerpunkt zunächst auf dem Netzwerk und dann möglicherweise auf der Application liegen. Wenn Zeit ist. Für Sicherheit hat niemand Zeit und daran wird sowieso niemand gemessen. Tatsächlich war der am häufigsten genannte Sicherheitsparameter die „Netzwerkverfügbarkeit“, die 59 % der Sicherheitsexperten anhand dieser Kennzahl angaben.
Die Menschen, die noch immer das Herz der IT bilden und die Teams bilden, die Automatisierung und Orchestrierung implementieren müssen, sind nicht unbedingt auf dieselben Ziele ausgerichtet. Ein Faktor dieser Fehlausrichtung ist die anhaltende Isolierung operativer Bereiche. NetOps- und Sicherheitsgruppen arbeiten eher in der Struktur eines „Single Function“-Teams. NetOps kümmert sich um das Netzwerk. Sicherheit? Sicherheit. Operationen? Systembetrieb.
Aber es geht sogar noch tiefer . Denn in den GROSSEN Silos befinden sich noch kleinere Silos. Wie bei der Matrjoschka – einer russischen Puppe – gibt es bei NetOps viele verschiedene Teams, die diese scheinbar einfache „Neue Site“-Anforderung erfüllen müssen, bevor sie abgeschlossen ist. Bevor einer solchen Anfrage entsprochen werden kann, müssen zahlreiche Infrastruktur- und Application bereitgestellt und integriert werden. Eine neue Site erfordert nicht nur die für ihr Hosting erforderlichen Rechen- und Netzwerkressourcen, sondern auch eine Vielzahl weiterer Anforderungen. Ein Webserver und sein Speicher. Zugriffskontrolle. Zertifikate und Schlüsselverwaltung. Lastenausgleich. Firewall-Regeln. Die Liste der IT-internen Silos, die diese „einfache“ Anfrage durchlaufen muss, ist endlos.
Und wenn eines dieser Silos innerhalb des NetOps-Silos nicht automatisiert wird, kommt der Prozess abrupt zum Stillstand. Die für die Erfüllung einer solchen Anfrage erforderliche Zeit kann sich um Tage oder sogar Wochen verlängern.
Für den Anforderer sieht es nach außen hin so aus, als würde NetOps seiner Aufgabe einfach nicht gerecht. Es ist das „Gegenstück“, der „Verbindungsmann“, der „IT-Partner“, der die Ängste derjenigen aushält, die wissen wollen, warum die Erfüllung einer scheinbar einfachen Anfrage so lange dauert. Wir geben NetOps die Schuld, so wie technische Neulinge den lokalen Provider für Internetprobleme verantwortlich machen, während das Problem eigentlich ein Router tief im Backbone ist, der von einem anderen Provider verwaltet wird.
Seien Sie ein Fürsprecher, kein Gegner
Der Wandel hin zu einer stärker kollaborativen und transparenteren IT ist für viele Unternehmen noch immer nur eine Phase am Horizont. Während einige Gruppen in der IT die Notwendigkeit erkennen und die notwendigen Änderungen annehmen, ist dies nicht bei allen der Fall. In den fünf Jahren, in denen wir Forschung zu Application betrieben haben, konnten wir nicht feststellen, dass „DevOps“ die erforderliche strategische Bedeutung erlangte, um wirklich die kulturellen und organisatorischen Veränderungen einzuleiten, die notwendig sind, um die Geschwindigkeit zu erreichen, die das Unternehmen will – und braucht. Stattdessen haben sich die Unternehmen der Automatisierung zugewandt – und die anderen drei für DevOps entscheidenden Komponenten vergessen.
Es ist beunruhigend, dass nicht erkannt wird, dass es bei der DevOps-Bewegung in der IT um mehr geht als nur um Automatisierung. Dabei wird nicht erkannt, dass eine Beschleunigung nur durch die Automatisierung der Pipeline möglich ist, und dass diese Pipeline praktisch alle Betriebsbereiche und Silos innerhalb der IT durchläuft. Das bedeutet, dass alle Betroffenen auf die Automatisierung umsteigen müssen. Andernfalls werden Sie die gewünschte Geschwindigkeit und Häufigkeit der Bereitstellungen nicht erreichen. Sie können nicht einfach die Automatisierung annehmen und erwarten, dass Sie damit Erfolg haben. Wenn die Automatisierung die Grenzen zwischen isolierten Gruppen überschreiten muss, wird das ohne einen wesentlichen kulturellen Wandel zum Scheitern führen.
Der notwendige Wandel muss von oben kommen. Insbesondere organisatorische Veränderungen. Wir können uns nicht wirklich neu organisieren, oder? Wir können unsere Ziele nicht neu priorisieren und einen völlig anderen Maßstab verwenden, oder?
Das ist uns nicht möglich, und wenn wir nicht diejenigen, die die notwendigen Änderungen vornehmen können , informieren und überzeugen, werden wir inmitten einer ansonsten automatisierten Pipeline mit manuellen Prozessen stecken bleiben.
Hören wir also auf, NetOps als Sündenbock zu benutzen, und erkennen wir an, dass auch sie möglicherweise frustriert sind. Erinnern Sie die Entscheidungsträger stattdessen daran, dass sie die Organisationsstrukturen neu bewerten und die Prioritäten für Messungen neu festlegen müssen, um eine bessere Abstimmung mit dem Geschäft und dem Rest der kontinuierlichen Pipeline zu erreichen.
Die NetOps-Leute an der Front anzuschreien, mag zwar befriedigend sein , ändert aber nichts an der Situation, die den Ärger überhaupt erst ausgelöst hat. Und ohne Veränderungen wird die Pipeline nicht schneller werden.
Seien Sie Ihr NetOps-Fürsprecher und nicht deren Gegner. Sie brauchen jede Hilfe, die sie bekommen können.