NetOps setzt auf Github, bis auf einen Typen, der an vimdiff festhält
Und weitere Erkenntnisse aus der NetDevOps-Umfrage vom Herbst 2016, die von der NetworkToCode- Community durchgeführt wurde
Die NetworkToCode-Community ist voller Menschen, die sich leidenschaftlich für Netzwerke und Code interessieren. So klischeehaft es auch klingen mag, diese Leute haben die Vernetzung schon automatisiert, bevor es cool wurde (und zu einem Gebot der Geschäftsleitung wurde).
Im Herbst 2016 führte die Community eine Umfrage zu einem breiten Fragenspektrum durch, bei dem es passenderweise um die Themen Netzwerke und Code ging. Die Rohergebnisse (Link oben) sind öffentlich verfügbar. Aufgrund der Natur von Online-Umfragetools können die resultierenden Datensätze schwer zu analysieren sein, sofern Sie die Daten nicht normalisieren (was Arbeit erfordert). Zum Glück für Sie, lieber Leser, habe ich diese Arbeit für Sie erledigt und kann Ihnen Einblicke in einer anschaulicheren und farbenfroheren Form bieten.
Aufmerksamen Lesern wird aufgefallen sein, dass ich mich schon lange für die Anwendung der sogenannten „DevOps“-Prinzipien auf das Netzwerk einsetze, und es überrascht nicht, dass ich bei der Analyse dieser Daten einen großen Teil meiner Energie darauf konzentriert habe.
Es ist keine Überraschung, dass in einer Gruppe, die sich auf Code und Netzwerke konzentrierte, die Ansichten gegenüber DevOps zumindest überwiegend positiv waren. Nur 6,75 % hatten „kein Interesse“ an DevOps, während 25,74 % angaben, dass es bereits in der Produktion sei. Die meisten anderen dachten zumindest darüber nach (39,24 %), wenn sie es auch schon nicht in Erwägung zogen (28,27 %).
Die erfahrenen Autoren dieser Umfrage stellten einige recht detaillierte Fragen zu diesem Thema, darunter auch zur Perspektive von NetOps auf Infrastructure as Code. Dies stieß auf etwas mehr Desinteresse, wobei fast 10 % „kein Interesse“ sagten. Interessant war, dass nur 19,35 % behaupteten, die Infrastruktur als Code sei „bereits in Produktion“, aber ganze 54 % der Befragten angaben, sie nutzten Automatisierung für die Konfigurationsbereitstellung und weitere 66 % automatisierten die Konfigurationsarchivierung. Genau ein NetOps automatisiert das Konfigurationsmanagement (und ich bin ziemlich sicher, dass es nicht der einzige NetOps ist, der stolz vimdiff zur Verwaltung von Konfigurationsänderungen verwendet).
Die erste Frage, die einem normalerweise in den Sinn kommt, ist überhaupt: „Was ist Infrastructure as Code?“ Dies ist wahrscheinlich die Ursache dafür, dass so viele andere etwas „tun“, obwohl sie sich meist damit identifizieren, es zu „bewerten“ oder darüber „nachzudenken“. Die Definition von Müdigkeit ist real, Leute , und ohne klare Definitionen ist es heutzutage schwierig, Schlussfolgerungen aus flüchtiger Terminologie zu ziehen (obwohl wir das trotzdem tun, denn das ist unser Job, oder?).
Was also automatisieren NetOps? Wir sagen ihnen immer wieder, dass sie das tun müssen, damit die digitale Transformation ohne Verzögerungen weiterläuft. Aber wir wissen auch, dass insbesondere Unternehmensnetzwerke nicht gerade eine Umgebung sind, in der man mit Automatisierung herumspielen sollte. Dabei handelt es sich um seriöse Netzwerke, auf die sich heute das gesamte Geschäft stützt. Es stellt sich heraus, dass NetOps ziemlich viel automatisieren.
Die drei wichtigsten Vorgänge, die heute automatisiert werden, sind die Konfigurationsgenerierung, -archivierung und -bereitstellung. Auch die Datenerfassung und Berichterstattung scheint an Fahrt zu gewinnen.
Tatsächlich scheint mit Ausnahme des Konfigurationsmanagements (und des abenteuerlichen NetOps) in den Organisationen einer beachtlichen Anzahl von Befragten jeder Vorgang automatisiert zu sein.
Bei der Automatisierung konfigurationsbezogener Aufgaben stellt sich jedoch natürlich die Frage, wie häufig sie vorkommt und ob eine Automatisierung daher gerechtfertigt ist. Ich würde (wahrscheinlich im Widerspruch zur aktuellen Meinung zu diesem Thema) argumentieren, dass die Automatisierung umso wertvoller ist, je seltener Sie Änderungen in die Produktion einbringen. Natürlich „vergisst“ man das Fahrradfahren nie, aber wenn Monate oder Jahre dazwischen liegen, kann die erste Fahrt zurück im Sattel eine schmerzhafte (und fehlerbehaftete) Erfahrung sein. So kann es auch bei Bereitstellungen sein. Aber das ist ein Thema für einen anderen Tag.
Es zeigt sich, dass NetOps relativ regelmäßig Bereitstellungen durchführt, wobei knapp die Hälfte (50,92 %) kleinere Änderungen mehr als einmal am Tag in der Produktionsumgebung bereitstellt und 37,59 % ein- bis fünfmal im Monat größere Änderungen bereitstellen. Das kommt zwar nicht annähernd an die außergewöhnlichen „200 Mal am Tag“ heran, die von webnativen Technologieanbietern angepriesen werden, die hauptsächlich einzelne Apps unterstützen (denken Sie an Netflix, PayPal oder Facebook), aber für ein Unternehmen, das durchschnittlich mehr als 200 Anwendungen unterstützt (gemäß unseren eigenen Umfragen zum Stand der Anwendungsbereitstellung), sind das immer noch ziemlich gute Apps.
Schließlich muss man sich fragen, wie sie all diese Änderungen bewältigen? Wie im Titel erwähnt, gab es tatsächlich einen einzelnen, stolzen NetOps, der behauptete, zur Verwaltung von Änderungen nur vimdiff zu verwenden. Angesichts der Struktur der Daten ist es schwierig, dies mit der Häufigkeit von Änderungen in der Produktion zu korrelieren, aber ich möchte wirklich mit diesem NetOps sprechen, denn er oder sie ist mein Held, weil er oder sie stolz an dem festhält, was für sie funktioniert, egal wie groß der externe Druck ist.
Worauf verlassen sich die restlichen NetOps? Es stellte sich heraus, dass eine ganze Menge von ihnen Github verwenden. 47 %, um genau zu sein. Und eine weitere große Gruppe (39 %) verwendet ranzige/oxidierte Stoffe. Rancid (nicht zu verwechseln mit der 1991 in Berkeley, Kalifornien, gegründeten amerikanischen Punkrock-Band) ist ein Netzwerktool, das Konfigurationssicherungen verwaltet. Oxidized ist auch ein Netzwerktool zum Verwalten von Konfigurationssicherungen, das oft als Ersatz für RANCID angepriesen wird. Es gibt spezielle Subreddits zu diesem Tool, falls Sie mehr darüber erfahren möchten.
Erschreckende 8 % verfolgen Konfigurationsänderungen überhaupt nicht. Ich habe das einmal im Labor gemacht und endete mit einer furchtbar asymmetrischen netzübergreifenden Verbindung, die in die eine Richtung 100 Mbit/s und in die andere 1,5 Mbit/s betrug. Ja, ich habe vor fast 11 Jahren versehentlich in einem Labor in Green Bay das moderne Breitbandkabelmodell nachgebaut. Nein, ich bekomme leider keine Tantiemen, aber die gute Nachricht ist, dass ich auch keine Hassmails bekomme. Auch diese Begründung ist ohne die Möglichkeit einer Kreuztabelle mit den Zahlen der Organisation schwer zu verstehen. Interessanterweise verwalten 11,91 % zwischen 0 und 50 Netzwerkgeräte. Daher ist die Annahme plausibel, dass diese 8 % eine überschaubare Anzahl an Geräten zu verwalten haben und gut zurechtkommen. Die größte Gruppe der NetOps (38,63 %) verwaltet mehr als 1.000 Geräte, und weitere 28,23 % verwalten zwischen 251 und 1.000. Man kann also getrost sagen, dass die Mehrheit der NetOps für eine große Anzahl (mit ziemlicher Sicherheit heterogener) Geräte verantwortlich ist und die Nachverfolgung von Konfigurationsänderungen daher nicht nur für die dauerhaft gute Funktionsfähigkeit des Netzwerks, sondern auch für die geistige Gesundheit seiner Betreiber notwendig ist.
Generell hat mir dieser Einblick in die Welt der NetDevOps, wie sich die Firma selbst bezeichnet, sehr gut gefallen. Auch die Sicht auf das, was sie verwenden, was sie für wichtig erachten und wie die Umgebungen aussehen, in denen sie arbeiten, wenn auch nur aus einer oberflächlichen Perspektive, hat mir sehr gut gefallen.
NetOps sind das Rückgrat der IT-Organisation und zunehmend dafür verantwortlich, dass alles am Laufen bleibt, während Unternehmen digitale Transformationen durchführen, die eine stärkere Belastung des Netzwerks und der Betreiber, die für dessen sicheren Betrieb sorgen, mit sich bringen.
Ich glaube nicht, dass es möglich ist, den Netzwerkbetrieb von einem traditionellen Modell auf ein agileres, DevOps-ähnliches Modell umzustellen. Ebenso wie die digitale Transformation von Unternehmen erfolgt auch die digitale Transformation der IT schrittweise. Dabei wird darauf geachtet, dass bestehende Prozesse nicht gestört werden, da dies zu einer Unterbrechung des Geschäftsbetriebs führen könnte. Diese Umfrage zeigt, dass hier eindeutig ein Wandel stattfindet, der zwar nicht als „DevOps“ bezeichnet wird oder die Vorstellungen der Puristen davon, was damit verbunden ist, nicht vollständig erfüllt, das Unternehmensnetzwerk jedoch auf seinem Weg der digitalen Transformation definitiv voranbringt.