NetOps braucht Fürsprecher, keine Widersacher

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Du willst dich gerade über eine Mahlzeit hermachen, auf die du dich den ganzen Tag gefreut hast, als du bemerkst, dass sie nicht richtig durchgegart ist. Frustriert fährst du die Bedienung schroff an und gibst ihr vielleicht sogar weniger Trinkgeld. Sie nimmt es lächelnd hin, obwohl es nicht ihre Schuld ist. Schließlich hat sie dein Essen nicht zubereitet. Doch sie ist deine Schnittstelle zur Küche, und letztlich ist sie es, die für Fehler büßen muss, die hinter den Kulissen passieren.

Ob es sich um die Bedienung in einem Restaurant oder einen Kundendienstmitarbeiter für <Dienstleistung hier einfügen> handelt – in der Regel bekommt die Person, die Ihr direkter Ansprechpartner ist, Ihren Unmut, Ihre Frustration oder Ihren Ärger ab, wenn etwas schiefläuft.

Das gilt auch im Rechenzentrum.

Während die IT ihre eigene digitale Transformation mit dem Ziel vorantreibt, Optimierung und Geschwindigkeit zu steigern, sind es meist die NetOps-Teams, die mit internen „Kunden“ interagieren und daher den Unmut unzufriedener Nutzer zu spüren bekommen, wenn Prozesse nicht so schnell wie gewünscht ablaufen.

Es ist wichtig zu erkennen, dass nicht immer „NetOps“ die Bereitstellung der neuesten Lösung, Anwendung oder Dienstleistung behindert. Wenn es an Geschwindigkeit mangelt, liegt das häufig daran, dass Unternehmen bei der Transformation ihres IT-Betriebs nicht alle Grundsätze von DevOps übernehmen.

Betreiben Sie DevOps oder automatisieren Sie nur?

CAMS ist das am häufigsten verwendete Modell zur Vermittlung der Grundprinzipien von DevOps. CAMS steht für: Kultur, Automatisierung, Messung und Wissensaustausch.

Von diesen vier Aspekten wird die Automatisierung am ehesten mit Begeisterung angenommen. Die anderen drei hingegen werden bei dem Bestreben, die Geschwindigkeit der Servicebereitstellung in der IT zu erhöhen, häufig vernachlässigt oder gänzlich ignoriert.

Besonders hervorzuheben ist, dass die drei häufig vernachlässigten Konzepte miteinander verknüpft sind. Es ist schwierig, die Kultur zu verändern, solange Teams weiterhin nach Funktionen voneinander abgeschottet 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 – selbst wenn unsere Kollegen im IT-Betrieb versuchen, die Anwendungsverfügbarkeit zu verbessern.

So erinnern Sie sich vielleicht an die Studie zum Stand der Netzwerkautomatisierung, für die wir uns mit Red Hat zusammengeschlossen haben, um in die undurchsichtige Welt von DevOps, NetOps und Automatisierung einzutauchen. Dabei stellten wir erhebliche Unterschiede zwischen den von NetOps angestrebten Kennzahlen (Messgrößen) und denen fest, die für die an Entwicklung und Betrieb Beteiligten relevant sind.

Fast drei Viertel (73 %) der NetOps-Befragten nannten die „Netzwerkverfügbarkeit“ als ihre wichtigste Kennzahl. Auf der anderen Seite gaben 59 % der Befragten aus Entwicklung und Betrieb an, dass die „Anwendungsverfügbarkeit“ ihre wichtigste Kennzahl sei. Umgekehrt wird die Bereitstellungshäufigkeit bei fast doppelt so vielen Befragten aus Entwicklung und Betrieb (30 %) gemessen wie bei NetOps (16 %) und Security (17 %).

Warum ist diese Diskrepanz von Bedeutung? Wenn mein vorrangiges Ziel darin besteht, die Verfügbarkeit des Netzwerks sicherzustellen, werde ich meine Zeit darauf verwenden, mich auf das Netzwerk zu konzentrieren. Instrumentierung und Monitoring – wobei Letzteres für die Austausch-Komponente von DevOps von entscheidender Bedeutung ist – werden sich zunächst auf das Netzwerk und dann vielleicht auf die Anwendung konzentrieren. Falls dafür noch Zeit bleibt. Niemand hat Zeit für Sicherheit, und daran wird ohnehin niemand gemessen. Tatsächlich war die am häufigsten genannte Kennzahl für Sicherheit – <Trommelwirbel bitte> – die „Netzwerkverfügbarkeit“: 59 % der Sicherheitsexperten werden anhand dieser Kennzahl bewertet.

Die Menschen, die nach wie vor das Herzstück der IT bilden und in den Teams arbeiten, die Automatisierung und Orchestrierung umsetzen müssen, verfolgen nicht unbedingt dieselben Ziele. Ein Grund für diese mangelnde Abstimmung ist die anhaltende Abschottung der einzelnen Betriebsbereiche. NetOps- und Sicherheitsteams arbeiten eher als Teams mit nur einem Funktionsbereich. NetOps kümmert sich um das Netzwerk. Sicherheit? Um die Sicherheit. Betrieb? Um den Systembetrieb.

Aber es geht noch tiefer als das. Denn innerhalb der GROSSEN Silos gibt es noch kleinere Silos. Wie bei einer Matroschka – einer russischen Schachtelpuppe – gibt es innerhalb von NetOps viele verschiedene Teams, die diese scheinbar einfache Anfrage nach einer „neuen Website“ durchlaufen muss, bevor sie abgeschlossen ist. Zahlreiche Infrastruktur- und Anwendungsdienste müssen bereitgestellt und eingebunden werden, bevor eine solche Anfrage umgesetzt werden kann. Eine neue Website erfordert nicht nur die Rechen- und Netzwerkressourcen für ihr Hosting, sondern auch eine Vielzahl weiterer Komponenten: einen Webserver und den zugehörigen Speicher, Zugriffskontrolle, Zertifikats- und Schlüsselverwaltung, Lastverteilung sowie Firewallregeln. Die Liste der IT-internen Silos, die diese „einfache“ Anfrage durchlaufen muss, ließe sich endlos fortsetzen.

Und wenn eines dieser Silos innerhalb des NetOps-Silos nicht automatisiert ist, kommt der Prozess abrupt zum Stillstand. Dadurch kann die Bearbeitung einer solchen Anfrage Tage, wenn nicht sogar Wochen länger dauern.

Von außen – für den Anfordernden – sieht es so aus, als würde NetOps seine Arbeit einfach nicht richtig machen. Der „Ansprechpartner“, die „Verbindungsstelle“, der „IT-Partner“ bekommt den Unmut derjenigen zu spüren, die wissen wollen, warum die Erfüllung einer scheinbar einfachen Anfrage so lange dauert. Wir geben NetOps die Schuld, so wie technische Laien bei Internetstörungen dem lokalen Anbieter die Schuld geben, obwohl das Problem in Wirklichkeit bei einem Router tief im Backbone liegt, der von einem anderen Anbieter verwaltet wird.

Seien Sie ein Fürsprecher, kein Widersacher

Der Wandel hin zu einer stärker auf Zusammenarbeit und Transparenz ausgerichteten IT zeichnet sich für viele Unternehmen noch kaum am Horizont ab. Einige IT-Gruppen erkennen zwar die Notwendigkeit und setzen die erforderlichen Veränderungen um, doch längst nicht alle tun dies. In den fünf Jahren, in denen wir Anwendungsservices untersucht haben, konnten wir nicht feststellen, dass „DevOps“ die strategische Bedeutung erlangt hat, die erforderlich wäre, um die notwendigen kulturellen und organisatorischen Veränderungen tatsächlich anzustoßen und die Geschwindigkeit zu erreichen, die das Unternehmen anstrebt – und benötigt. Stattdessen haben Unternehmen auf Automatisierung gesetzt – und dabei die drei anderen für DevOps entscheidenden Komponenten außer Acht gelassen.

Es ist besorgniserregend, dass die Ausweitung der DevOps-Bewegung auf die IT nicht als etwas verstanden wird, das über reine Automatisierung hinausgeht. Dabei wird verkannt, dass zur Steigerung der Geschwindigkeit die Pipeline automatisiert werden muss – und diese Pipeline durch nahezu alle operativen Bereiche und Silos innerhalb der IT verläuft. Das bedeutet, dass alle Beteiligten auf Automatisierung setzen müssen, da sich die angestrebte Geschwindigkeit und Häufigkeit von Bereitstellungen andernfalls nicht erreichen lässt. Es reicht nicht aus, lediglich die Automatisierung voranzutreiben und auf Erfolg zu hoffen. Wenn die Automatisierung die Grenzen zwischen isolierten Gruppen überwinden muss, wird sie ohne einen tiefgreifenden kulturellen Wandel scheitern.

Die erforderliche Veränderung muss von der Führungsebene ausgehen. Das gilt insbesondere für organisatorische Veränderungen. Schließlich können wir uns nicht einfach selbst neu organisieren, oder? Wir können auch nicht eigenmächtig unsere Ziele neu priorisieren und völlig andere Kennzahlen verwenden, oder?

Das können wir nicht, und wenn wir nicht diejenigen aufklären und überzeugen, die die notwendigen Änderungen vornehmen können, werden wir inmitten einer ansonsten automatisierten Pipeline weiterhin an manuellen Prozessen festhängen.

Hören wir also auf, NetOps zum Sündenbock zu machen, und erkennen wir an, dass auch das NetOps-Team frustriert sein könnte. Stattdessen sollten wir die Entscheidungsträger daran erinnern, dass Organisationsstrukturen neu bewertet und Messgrößen anders priorisiert werden müssen, um eine bessere Abstimmung mit den Geschäftszielen und dem übrigen Teil der Continuous Pipeline zu erreichen.

Die NetOps-Mitarbeiter an vorderster Front anzuschreien, mag sich befriedigend anfühlen, ändert aber nichts an der Situation, die den Ärger überhaupt erst ausgelöst hat. Und ohne Veränderungen wird die Pipeline auch nicht schneller.

Setzen Sie sich für Ihr NetOps-Team ein, statt ihm entgegenzuarbeiten. Es braucht jede Unterstützung, die es bekommen kann.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie