Es wird viel über die archetypische Beziehung zwischen DevOps und NetOps gesprochen. Wir werden ständig mit einer Litanei von „Wir gegen die“-Rhetorik bombardiert, die die einen gegen die anderen aufhetzt, und bei der sich über die Mauer, die sie trennt, gegenseitig Anträge und Beschuldigungen zuwerfen. Angesichts des zunehmenden Drucks, Apps schneller und häufiger bereitzustellen, kann diese Mauer zur digitalen Kluft werden, die die Gewinner der App-Ökonomie von allen anderen trennt.
Glücklicherweise schrumpft diese digitale Kluft dank der IT-Automatisierung und -Orchestrierung. Als wir jede Gruppe einzeln befragten und dabei ihren Technologieeinsatz, ihre gegenseitige Wahrnehmung und die von ihnen bereitgestellten Anwendungen näher untersuchten, entdeckten wir den Wunsch sowohl bei NetOps als auch bei DevOps, bei der Schließung dieser digitalen Kluft zusammenzuarbeiten. Das sind zunehmend gute Nachrichten für Unternehmen, die eine digitale Transformation in Angriff nehmen, die einen Umfang und eine Geschwindigkeit erfordert, die nur durch Automatisierung und Orchestrierung effektiv erreicht werden können. Dies sind auch gute Nachrichten für Unternehmen, die mit Multi-Cloud-Umgebungen zu kämpfen haben, die eine noch größere Aufmerksamkeit der bereits überlasteten Mitarbeiter erfordern. Durch die Automatisierung wird der Druck vor Ort verringert, sodass Ressourcen für Cloud-bezogene Projekte frei werden können.
884 NetOps- und DevOps-Experten nahmen an den im Sommer 2017 durchgeführten Online-Umfragen teil. Wir haben mehrere wahrnehmungsbezogene Fragen zu Anwendungen im Allgemeinen und ihren Gegenstücken in NetOps oder DevOps gestellt, sowie Fragen, die sich auf die Wahrnehmung der Häufigkeit und Erfolgsraten von Bereitstellungen konzentrierten.
Die Ergebnisse zeigen, dass die Mauer zwischen ihnen zwar noch steht, aber bei weitem nicht so hoch oder undurchsichtig ist, wie es der Dialog innerhalb der Gemeinschaften oder andere Branchenberichte behaupten. Wir haben in Organisationen aller Größen und Branchen viele Gemeinsamkeiten festgestellt, was die Bedeutung und den Wunsch nach Automatisierung der Produktionspipeline betrifft. Darüber hinaus besteht ein gemeinsames Vertrauen in die Sicherheit, Leistung und Zuverlässigkeit der Anwendungen, die beide Gruppen entwickeln und bereitstellen möchten.
Die Automatisierung scheint eine verbindende Kraft für NetOps und DevOps zu sein. Zumindest im Prinzip, wenn auch nicht in den konkreten Umsetzungsdetails.
Während DevOps und NetOps weiterhin unterschiedlicher Meinung darüber sind, wie viel Pipeline-Zugriff über Self-Service und Automatisierung verfügbar sein sollte, sind beide Gruppen größtenteils der Ansicht, dass die jeweils andere auf dem richtigen Weg ist. 82 % der DevOps und 76 % der NetOps sind sich einig, dass die jeweils anderen „die richtigen Dinge“ priorisieren. Offensichtlich gibt es trotz der digitalen Kluft zumindest hinsichtlich der Ziele und Schwerpunkte einen gemeinsamen Nenner, wenn auch nicht immer hinsichtlich der Organisationsstruktur.
Unter den Andersdenkenden auf der NetOps-Seite war die häufigste Antwort auf die Frage, was bei DevOps nicht genügend Priorität habe, die Sicherheit. Auch die Zuverlässigkeit war bei DevOps gegenüber NetOps-Kollegen häufig ein Grund zur Frustration.
Zuverlässigkeit und Sicherheit sind ebenso wichtig wie Liefergeschwindigkeit. Sicherheit ist immer noch ein nachträglicher Gedanke. Leistung, Sicherheit, Zuverlässigkeit.
Es überrascht nicht, dass sich einer der häufigsten Refrains von DevOps bezüglich der Priorisierung durch NetOps auf die Automatisierung konzentriert. Oder eher: ein Mangel daran.
Automatisierung, Automatisierung, Automatisierung. Ich würde mir wünschen, dass sie der automatisierten, Cloud-agnostischen Ressourcenerstellung im Cloud-Bereich Priorität einräumen. Automatisierung, DevOps, Cloud, Sicherheit.
Diese Meinungsverschiedenheit ist wahrscheinlich die Ursache unserer nächsten wichtigen Erkenntnis, die die Auswirkungen des fehlenden Zugriffs von Entwicklern und DevOps auf die Produktionspipeline über Automatisierung und Selfservice auf die Einführung von Cloud- und IT-externen Lösungen offenlegt.
Sie können Sie jetzt hören. Lange Zeit ging man davon aus, dass einer der Gründe für die Einführung der Cloud – sowohl bei Unternehmens- als auch bei DevOps-Interessengruppen – der fehlende Selfservice-Zugriff auf die Produktionsbereitstellungspipeline ist, der zu langwierigen Bereitstellungszyklen führt. Die nicht so gute Nachricht ist, dass unsere Umfrage diesen Glauben bestätigt: 27 % der DevOps geben an, dass er ihre Entscheidung, auf Cloud-basierte Lösungen zurückzugreifen, „stark“ und 38 % „etwas“ beeinflusst. Die gute Nachricht ist, dass NetOps sich der Auswirkungen bewusst sind. Über 65 % der NetOps geben an, dass ihr Wunsch zur Automatisierung und Bereitstellung eines Selfservice-Zugriffs auf die Produktionspipeline „etwas“ oder „stark“ von der Entscheidung der DevOps beeinflusst wird, auf die Cloud umzusteigen.
Das Schuldzuweisungsspiel ist vorbei. Im Gegensatz zu gängigen Darstellungen, in denen NetOps und DevOps nach Vorfällen in einem endlosen Schuldzuweisungsspiel gegeneinander ausgespielt werden, haben wir Hinweise darauf gefunden, dass jede Gruppe die andere in einem weitaus positiveren Licht sieht.
Der Griff zur Cloud durch diejenigen, die wegen des fehlenden Pipeline-Zugriffs frustriert sind, trägt in hohem Maße zum Aufstieg der Multi-Cloud und den damit verbundenen Sicherheits- und Leistungsproblemen bei, wie oft von denjenigen angemerkt wird, die mit der dadurch entstehenden „Rogue-IT“ zu kämpfen haben. Auch wenn NetOps weiterhin versucht, mit privaten Cloud- oder Cloud-ähnlichen Systemen Zugriff über Automatisierung/Self-Service anzubieten, bestehen weiterhin erhebliche Investitionen in externe Cloud-Lösungen, die kaum ignoriert werden können. Unternehmen müssen daher mehrere Cloud-Lösungen und -Umgebungen verwalten, überwachen und sichern, was die Komplexität ihrer Aktivitäten in der digitalen Wirtschaft weiter erhöht.
Die Frage ist jetzt nicht „Bieten wir Selfservice-Zugriff auf die Produktionspipeline?“, sondern vielmehr „Wie viel geben wir preis?“
Wie viel ist genug? Das richtige Maß an Pipeline-Zugriff auf Entwickler und DevOps über Automatisierungs-/Self-Service-Funktionen brachte einige bemerkenswerte Meinungsverschiedenheiten zum Vorschein. DevOps möchte auf jeden Fall mehr Zugriff auf die Produktionspipeline, als NetOps ihnen anbieten möchte.
Wir haben zwar nicht um Einblicke in die Zurückhaltung von NetOps gebeten, DevOps einen besseren Pipeline-Zugriff zu gewähren, eine Antwort könnte jedoch in den dafür verfügbaren Fähigkeiten liegen. Die NetOps-Befragten sind im Allgemeinen der Meinung, dass zwischen den Fähigkeiten, die sie für ihre Arbeit benötigen, und der Ausbildung/dem Wissen, über das sie derzeit verfügen, eine Lücke besteht.
Tatsächlich waren sowohl NetOps als auch DevOps, die sich selbst als „Entwickler“ bezeichnen, eher davon überzeugt, dass ihre Jobs bei ähnlichen Verantwortlichkeiten und Fähigkeiten in fünf Jahren noch relevant sein würden. Am wenigsten Vertrauen zeigten diejenigen, die sich als Netzbetreiber auswiesen – auf beiden Seiten der Mauer.
Der aktuelle Stand der Automatisierung der Produktionspipeline auf der NetOps-Seite scheint die Auswirkungen dieser Qualifikationslücke widerzuspiegeln. Es war keine Überraschung, dass es erheblich hinter der DevOps-Delivery-Pipeline zurückbleibt. Während 11 % der NetOps zugeben, dass die Produktionspipeline nicht automatisiert ist, sagten nur 5 % der DevOps dasselbe über die Anwendungsbereitstellungspipeline.
Der Status der Pipeline-Automatisierung ist wichtig zu beachten, da wir festgestellt haben, dass zwischen der Pipeline-Automatisierung und der Häufigkeit erfolgreicher Bereitstellungen eine positive Korrelation besteht. 86 % der NetOps, die einen höheren Prozentsatz an Pipeline-Automatisierung (75 % oder mehr) angeben, berichteten auch von einer höheren Häufigkeit sehr erfolgreicher (90 % oder mehr) Bereitstellungen.
Dies ist jedoch nicht der einzige Faktor, da die Häufigkeit von Anwendungsänderungen offenbar auch Auswirkungen auf die Häufigkeit erfolgreicher Bereitstellungen hat.
Uns geht es gut, danke. Die größte kulturelle Kluft besteht möglicherweise noch immer im Bereich der Einsatzhäufigkeit. Während einige DevOps-Unternehmen Apps in atemberaubender Geschwindigkeit in die Produktion bringen (12 % bringen Änderungen mehr als einmal am Tag in die Produktion), scheinen NetOps-Unternehmen diese Änderungen deutlich langsamer, aber dafür gleichmäßiger bereitzustellen.
Insgesamt scheint bei einer Vielzahl der Befragten ein gewisser Konsens hinsichtlich der monatlichen und wöchentlichen Häufigkeit zu bestehen. Es überrascht nicht, dass DevOps häufiger liefert als NetOps. Das heißt: Von den 26 % der DevOps, die häufiger liefern möchten, liefern 28 % einmal pro Woche und 26 % bereits mehr als einmal pro Tag.
Die Einschätzungen hinsichtlich der Angemessenheit der Geschwindigkeit, mit der Änderungen umgesetzt werden, sind von Gruppe zu Gruppe unterschiedlich. Bemerkenswert ist jedoch, dass die Mehrheit beider (70 % der DevOps und 74 % der NetOps) die Häufigkeit der Änderungen als „gut genug für uns“ bezeichnete.
Hier endet die Gemeinsamkeit. Während lediglich 4 % der DevOps behaupteten, ihr aktueller Zeitplan sei „zu häufig“, war es auf der NetOps-Seite doppelt so viel, dass sie die Lieferhäufigkeit als „zu häufig“ bezeichneten. Mehr als ein Viertel (26 %) der DevOps möchte schneller vorankommen, während weniger als ein Fünftel (18 %) der NetOps das Tempo erhöhen möchte.
Wenn man jedoch die Wünsche außer Acht lässt und die Ergebnisse untersucht, erkennt man, was die „ideale“ Bereitstellungshäufigkeit für ein Gleichgewicht zwischen Geschwindigkeit und Erfolgsraten sein könnte. Von den 65 % NetOps und 57 % DevOps, die in über 90 % der Fälle erfolgreiche Bereitstellungen verzeichnen, werden Änderungen „einmal pro Woche“ in die Produktion gebracht.
Die digitale Kluft, die Anwendungen überwinden müssen, um von der Auslieferung zur Nutzung zu gelangen, besteht noch immer. Wesentliche Teile der Bereitstellungspipeline werden weiterhin manuell gesteuert, was dazu führt, dass Anwendungen auch weiterhin in die Cloud verlagert werden. Im Gegenzug werden DevOps-Entscheidungen, auf die Cloud umzusteigen, dazu führen, dass NetOps mehr Self-Service-Zugriffe bereitstellen, die für eine schnellere Umsetzung erforderlich sind.
Automatisierung ist der Schlüssel zur Überbrückung dieser digitalen Kluft, da sie es NetOps und DevOps ermöglicht, intelligenter und nicht härter zu arbeiten und den Betrieb zu skalieren, um gemeinsam die Geschäftsanforderungen zu erfüllen.
Die Daten für diesen Bericht wurden aus zwei separaten Online-Umfragen zusammengestellt, die im Juli 2017 durchgeführt wurden. Beide zielten darauf ab, den Einsatz der Automatisierung im Anwendungslebenszyklus von der Entwicklung bis zur Bereitstellung sowie die Wahrnehmungen der beiden hauptsächlich beteiligten Gruppen zu untersuchen. Den Befragten beider Gruppen wurde ein Anreiz zur Teilnahme geboten.
Nachfolgend finden Sie zusätzliche, ausgewählte Antworten auf Umfragefragen, die sowohl von NetOps- als auch von DevOps-Teilnehmern stammen. Es handelt sich hierbei nicht um eine vollständige Liste, sondern sie dienen hier als Beispiel für die Art des erhaltenen Feedbacks. Die Produktnamen wurden zur Vereinfachung der Vorgehensweise bearbeitet. Ansonsten ist beabsichtigt, die Kommentare unverändert und in der vorliegenden Form zu veröffentlichen.
Wenn Sie die Frage „Priorisiert Ihr Entwicklerteam die Dinge richtig?“ mit „Nein“ beantwortet haben: Welche Prioritäten sollten Ihrer Meinung nach anders gesetzt werden?
- Stabilität, Qualität und Vision. Viel zu oft sprinten die Leute zu einem Termin und darunter leidet vor allem die Qualität. Wenn man außerdem nicht über die aktuelle Aufgabe hinausblickt, führt das am Ende zu einer Menge Nacharbeit und nicht zu optimalen Lösungen (es wird Müll zusammengeschustert und er funktioniert vielleicht, aber er ist in keiner Weise optimal oder ideal).
– Wir brauchen mehr Zusammenarbeit zwischen Entwickler- und Systemadministratorteams. Wir kommen nicht schnell genug von der manuellen Verwaltung weg.
- Ich würde mir wünschen, dass Entwicklungsteams mehr Wert auf Betriebszuverlässigkeit, Architekturkonsistenz und die Zusammenarbeit zwischen verschiedenen Entwicklungsteams legen
- App-Entwickler denken nicht an das Netzwerk oder die Sicherheit, die Sicherheit nimmt von der Entwicklung nur am Rande Notiz, das Netzwerk erfährt von den betrieblichen Änderungen, sobald die Entwicklung abgeschlossen ist.
Wie würden Sie in einer idealen Welt die Interaktion, Kommunikation, Zusammenarbeit usw. zwischen Ihren Entwicklungs- und Betriebsteams verbessern?
- Verbessern Sie Metriken, Überwachung und Sichtbarkeit, damit beide Seiten über die Leistung informiert sind. Automatisieren Sie die Pipeline, um die Bereitstellung von Diensten zu beschleunigen. Stellen Sie ausreichend Kapazitäten bereit, um lange Lieferzeiten zu vermeiden.
- Ersetzen Sie sie durch intelligentere Leute
- Hören Sie auf, einander als Hindernisse zu betrachten, und lassen Sie alle Teams dort ihren Beitrag leisten, wo sie den größten Mehrwert schaffen können. Automatisierung ist großartig, aber ohne ein gewisses Maß an Kontrolle werden Lösungen implementiert, die zwar funktionieren können, für die es aber oft eine bessere und optimalere Möglichkeit gäbe, dies zu tun.
- Die Grenze zwischen den Entwicklungs- und Betriebsteams verschwimmt zunehmend. Sollte als „ein Team“ mit dem gemeinsamen Ziel betrachtet werden, Anwendungen so bereitzustellen, dass sie mit minimalem Aufwand skalierbar sind und auf der verfügbaren Infrastruktur eine gute Leistung erbringen.
- Kommunikation spielt keine Rolle, wenn Sie mit dem geistigen Äquivalent eines Steins mit Krawatte sprechen.
- Um das F5-Team früher in den Prozess des DEV-Zyklus einzubeziehen.
- Integrieren Sie Ops früher in den Entwicklungszyklus
- Gemeinsam genutzter Code und Sichtbarkeit von Pipelines. Je mehr Tools per Code verwaltet werden können, desto besser (beispielsweise können wir ein F5 BIG-IP nicht sinnvoll per Code verwalten, und das ist eine Schwachstelle in unserem Prozess).
Wenn Sie die Frage „Priorisiert Ihr Ops-Team die Dinge richtig?“ mit „Nein“ beantwortet haben: Welche Prioritäten sollten Ihrer Meinung nach anders gesetzt werden?
- Ich würde mir wünschen, dass sie der automatisierten, Cloud-agnostischen Ressourcenerstellung im Cloud-Bereich Priorität einräumen. Push-Button-Infrastruktur, die für Entwickler, Qualitätssicherung und Betrieb definitiv erreichbar und nützlich ist.
- Sie müssen sich an die Automatisierung aller Bereiche gewöhnen und dürfen keine Angst mehr vor dem Verlust ihres Arbeitsplatzes haben.
- Zu viel Handarbeit, keine Automatisierung, mangelndes Verständnis für das technische Kernproblem. Bestärken Sie die Entwickler.
- Sie neigen dazu, Probleme zu lösen, indem sie sie mit Geld überhäufen. Mehr (teurere) Ausrüstung. Mehr Personal, um die Dinge in Gang zu halten, statt Automatisierung.
Wie würden Sie in einer idealen Welt die Interaktion, Kommunikation, Zusammenarbeit usw. zwischen Ihren Entwicklungs- und Betriebsteams verbessern?
- Ich möchte, dass das Ops-Team mehr Tools bereitstellt, um die Details der Betriebsumgebung zu abstrahieren.
– Ich bin Entwickler und wir müssen die Infrastruktur bereitstellen und automatisieren. Die Ops-Leute müssen das Automatisieren und einige Tools erlernen.
- Ändern Sie das Betriebsteam so, dass es stärker zu einer Infrastrukturunterstützung wird, die die Verwaltung der Infrastruktur automatisiert. Dadurch könnten die Entwickler die Infrastruktur eher als Dienst verwenden, statt sich bei Upgrades, Serververwaltung usw. auf den Betrieb zu verlassen. Ich würde außerdem Mitglieder des Betriebsteams als Verbindungspersonen in andere Gruppen einbinden, um die Verwaltung der Anwendungen zu vereinfachen.
- Das Ops-Team muss erweitert und direkt in Entwicklung und Tests eingebunden werden. Es muss weniger eine Anlaufstelle für Anfragen sein, sondern mehr ein integrierter Partner an der Front.