Der Stand von DevOps im Jahr 2022

In diesem Artikel geben wir Ihnen einen Überblick über die neuesten DevOps-Berichte von Puppet, BMC, dem DevOps Institute und Google Cloud. Lesen Sie dann weiter, um die Schritte zu erfahren, die erfolgreiche Organisationen bei der Einführung von DevOps unternehmen können. Springen Sie zu dem, was Sie interessiert:

• Puppets DevOps-Zustand
• BMC & Puppet diskutieren den Stand von DevOps
• Das DevOps-Institut
• Googles Accelerate Report
• Schritte, um DevOps richtig zu starten

Puppets DevOps-Zustand 2021

Jedes Jahr berichtet Puppet über den Stand von DevOps und veröffentlichte kürzlich seine 10. Auflage, gesponsert von BMC und anderen Branchenführern. In den letzten zehn Jahren haben die Berichte zusammen mehr als 35.000 technische Profis befragt, und die Jahresergebnisse haben großen Einfluss.

DevOps-Institut

Für den Bericht 2021 erhielt Puppet 2.657 Antworten aus aller Welt, wobei die Mehrheit – 32 Prozent – in die Kategorie 1.000 bis 10.000 Mitarbeiter und 40 Prozent im Technologiesektor liegt.

Der Bericht, der weniger als ein Jahr nach dem letzten veröffentlicht wurde, betrachtet die historische Entwicklung von DevOps und hebt die Bedeutung von Automatisierung, Cloud sowie von Menschen und Kultur für seinen Erfolg hervor. Puppet weist darauf hin, dass DevOps sich so weit entwickelt hat, dass:

"Viele der Teams, die DevOps gut machen, sprechen gar nicht mehr über DevOps – so funktionieren sie einfach."

Und doch läuft es für die Organisationen, die noch auf halbem Weg feststecken, darauf hinaus, sich besser mit Technologie und Menschen zu beschäftigen, um weiterzumachen.

Puppet stellt fest, dass sich in dieser Mittelgruppe die Hindernisse und Herausforderungen von einer Mischung aus technischer, kultureller und organisatorischer Lage am unteren Ende zu fast ausschließlich kulturellen (organisatorische Akzeptanz, Risikoscheu, unvollkommene Rückkopplungsschleifen, suboptimale Teamdefinitionen usw.) am oberen Ende verändern.

Der Bericht setzt zudem eine Gleichstellung, indem er die Geschichte von DevOps seit Beginn seiner Berichte untersucht und das große Ganze betrachtet, was DevOps ist und was nicht.

• DevOps ist nicht nur Automatisierung. Hochentwickelte Unternehmen haben weitaus eher umfangreiche und allgegenwärtige Automatisierung implementiert, aber gut in Automatisierung zu sein, macht einen nicht gut in DevOps. Zweiundsechzig Prozent der befragten Organisationen geben an, dass sie trotz hoher Automatisierungsniveaus mitten in der Entwicklung ihrer DevOps-Reise feststecken.
• Fast jeder nutzt die Cloud, aber die meisten Menschen nutzen sie schlecht. Organisationen sollten nicht erwarten, hochentwickelt, nur weil sie Cloud und Automatisierung nutzen. Während 65 Prozent der Organisationen in der mittleren Entwicklung angeben, Public Cloud zu nutzen, nutzen nur 20 Prozent die Cloud voll aus.
• Teamidentitäten und klare Interaktionsparadigmen sind entscheidend. Unternehmen werden durch Organisationsstruktur und Dynamik daran gehindert, sich auf höchste Ebenen weiterzuentwickeln. Organisationen, die "gut in DevOps" sind, haben Teams mit starken, gut verstandenen Identitäten, klaren Verantwortlichkeiten mit hohem Maß an Autonomie und klar definierten Kommunikationskanälen mit anderen Teams.

Weitere wichtige Erkenntnisse sind:

1. Während kulturelle Hindernisse wie organisatorischer Widerstand gegen Veränderungen, Legacy-Architektur, Fachkräftemangel, begrenzte bis keine Automatisierung sowie unklare Ziele oder Vorgaben für Unternehmen mit mittlerer Evolution weiterhin bestehen, sind sie für Organisationen mit niedriger Evolution am ausdrocklichsten.
2. Das Vorhandensein von "DevOps-Teams" ist für die Branche und viele Organisationen verwirrend und hilft in den meisten Fällen nicht bei der Weiterentwicklung. Puppet stellt fest, dass Organisationen mit weniger unklaren Teamnamen und klarer definierten Aufgaben viel eher eine leistungsfähigere IT-Funktion haben.
3. Gute Sicherheitspraktiken und bessere Sicherheitsergebnisse werden durch DevOps-Praktiken ermöglicht. Mit der Verbesserung der DevOps-Praktiken folgt DevSecOps ganz natürlich.
4. Plattformteams können DevOps-Transformationen beschleunigen, indem sie bestehende Automatisierungen nutzen, und die am weitesten entwickelten Organisationen in Puppets DevOps-Modellen übernehmen ein Plattformmodell, das Entwicklern Self-Service ermöglicht und das Entwicklererlebnis kuratiert.
5. Die Modernisierung älterer (alter) IT-Infrastruktur und Anwendungen erfordert Analysen, das Sortieren in leicht verständliche Kategorien sowie die Festlegung expliziter Ziele und Aktionspläne.

DevOps-Webinar mit Puppet & BMC

Während "viele der Teams, die DevOps gut machen, gar nicht mehr über DevOps sprechen – es ist einfach ihre Arbeitsweise", stellte Puppet fest, dass andere Organisationen auf halbem Weg feststecken.

In einem Folge-Webinar "The State of DevOps: Stuck in the Middle" sprach BMC-Produktmanager Jon Stevens-Hall mit Puppet-CTO Nigel Kersten über den Bericht und darüber, wie Organisationen Technologie und Menschen besser im Griff haben müssen, um voranzukommen. Wichtige Erkenntnisse aus ihrem Gespräch sind:

• Wie Größe den Erfolg von DevOps beeinflusst
• Vermächtnis für Ihre Organisation definieren
• Die richtige Bereitstellungsfrequenz
• Die Schlüsselrolle des Managements

Die Größe ist in DevOps wichtig

Zuerst sprachen sie darüber, wie die Größe bei DevOps eine Rolle spielt.

"DevOps in großen Unternehmen unterscheidet sich stark von DevOps in kleineren Unternehmen und Start-ups, und das scheint ein großes Thema im Stand des DevOps-Berichts zu sein", sagt Stevens-Hall.

"Die Leute, die ich 2015 [auf Konferenzen] getroffen habe, waren eher kleine Unternehmen, und das größte und prominenteste Unternehmen... war Spotify... das... ein sehr großer Pionier in Sachen Teamorganisation und so weiter war. Nur vier Jahre später... waren es Banken, es waren Telekommunikationsunternehmen. Sie hatten das Gefühl, agile Entwicklung gemacht zu haben, aber die Ops-Seite war noch nicht wirklich agil geworden."

"Das Interessanteste für mich war, dass sie sagten, dass Legacy nicht verschwindet... über Nacht. [Die Bank sagte], viele ihrer Transaktionen könnten die neueste Technologie beinhalten, aber auch viele Legacy-Produkte, die nicht geändert werden können oder in Jahren nicht geändert werden... sie brauchen neue Arbeitspraktiken, neue Technologien, um der Herausforderung gerecht zu werden, DevOps in all dieser Governance und Komplexität gedeihen zu lassen."

Legacy ist ein variabler Begriff

Kersten fügt hinzu, dass auch "Legacy" ein variabler Begriff ist. "Wenn Kunden anfangen, über die Legacy-Umgebung zu sprechen, ist das nicht alles dasselbe. Es ist tatsächlich nicht das älteste, was sie besitzen. Oft gibt es diese alten Mainframe-Systeme, die von kleinen Teams sehr gut betrieben werden, die in einer sehr, sehr DevOps-Denkweise arbeiten, ohne diese Praktiken mit dem Rest der Organisation zu teilen", sagt er.

"Legacy bezieht sich oft auf diese halbherzigen Anwendungen, die in den Neunzigern gebaut wurden und zweitausend [von Menschen], die alle Autodidakten sind, [also] gab es nicht viel Disziplin. Jeder hat das unterwegs ausgearbeitet. Ich denke, wir haben eine ganze Generation von Anwendungen, die viel schwerer zu monetarisieren sind als viele der Dinge auf den Großrechnern... Und ich denke, es gibt viele Kategorien, welche Probleme Menschen innerhalb von Legacy haben."

(Lernen Sie, wie Sie bei der Modernisierung von Anwendungen und Software erfolgreich sind.)

Die richtige Aussetzungsfrequenz erreichen

Im Hinblick auf die Kategorisierungsmethodik des Berichts erklärte Kestern: "Wir haben diese Idee von niedrigen, mittleren und hohen evolutionären Gruppen eingeführt... die Bereitstellungsfrequenz auf niedriger Ebene [tritt] monatlich [auf] alle drei bis sechs Monate auf, um eine Bereitstellung von abgeschlossen bis tatsächlichen Nutzen an den Endnutzer zu bringen, das Medium liegt zwischen täglich und wöchentlich, und eine hohe Gruppe ist auf Abruf."

"Die Bereitstellungsfrequenz [kan] eine Eitelkeitskennzahl sein, wenn die Leute sich zu sehr darauf konzentrieren [aber] es gibt etwas Transformatives für das Unternehmen, von monatlich auf alle paar Tage zu wechseln, das ist ein wirklich großer Sprung.

"[Wenn] wir uns die Daten aus der Umfrage selbst ansehen... gibt es in den meisten Organisationen relativ leichte Vorteile, um von niedrig nach mittel zu wechseln. Und dann gibt es eine relativ konkrete Reihe von Aufgaben, um von mittlerer nach hoher Gruppe zu wechseln. Die niedrige Gruppe wird kleiner. Die obere Gruppe wird größer, aber es gibt diese riesige Gruppe von fast 80 Prozent der Menschen, die nicht aus dem mittleren Bereich herauskommen. Und darauf wollten wir uns dieses Jahr wirklich konzentrieren."

"[Kein] dieser [Herausforderungen] sind technische Probleme... Die Dinge, die große Organisationen behindern, sind die Interaktionen mit Menschen, Teaminteraktionen, Kommunikation und all diese soziotechnischen Systeme. Und wenn wir Veränderungen auf der Menschenseite vornehmen, beeinflusst das die Technologie und umgekehrt... und es hemmt wirklich... viel Fortschritt für die Menschen."

Stevens-Hall weist darauf hin, dass die derzeitige Komplexität vieler Organisationen diese Herausforderung noch verschärft:

"[Um] Menschen aus diesem festgefahrenen Mittelzustand zu holen... kann die Technologieabteilung im Unternehmen sicherstellen, dass wir mit dieser Werkzeugkette und deren Eigentümern zusammenarbeiten. [Wir] können dies auch in das Service-Management-System einbringen und Menschen aus der Serviceorganisation können mit Leuten aus dem DevOps-Team zusammenarbeiten und... sie können Informationen teilen und Wissen schaffen", sagt er.

Auch das Management muss sich einmischen

Kersten hat auch Tipps fürs Management. "Aus der... operativen Perspektive... wenn man im Management ist, ist das Wichtigste, dass die Teams einen klaren Zweck und eine Identität haben und klar definierte Interaktionen miteinander haben", erklärt er.

"Es geht vor allem darum, über funktionale Grenzen hinweg zusammenzuarbeiten, aber es stellt sich heraus, dass Zusammenarbeit tatsächlich eine sehr zeitaufwändige und ineffiziente Art ist, im großen Maßstab zu arbeiten. Und wenn Sie ein relativ kleines Service-Management-Team oder ein Betriebsteam mit Hunderten oder Tausenden von Entwicklern sind, können Sie unmöglich mit allen zusammenarbeiten."

"Die weiterentwickelten Organisationen sind diejenigen, die Praktiken teilen und dafür Räume schaffen. Solange man es nicht ein Exzellenzzentrum nennt, was in den meisten Umgebungen meist das Todesurteil für tatsächlichen Fortschritt bedeutet."

Kersten empfiehlt einige umsetzbare Tipps:

• "[Nennen] es etwas anderes [wie eine] Gemeinschaft der Praxis... etwas etwas weniger hierarchisches, autonomes und autoritäres.
• [Schaffen] Räume, in denen Menschen einfach zuhören, lernen und teilen können. Ich denke, die Menschen sind wirklich ziemlich klug und generell sehr engagiert.
• Und wenn Sie ihnen den Raum geben, Lösungen zu finden, werden sie diese umsetzen."

Als Nächstes werfen wir einen Blick auf den Upskilling-Bericht des DevOps Institute. Das DevOps Institute führte die Studie durch und untersuchte die notwendigen Fähigkeiten, die ein DevOps-Mensch im zweiten Jahr in Folge besitzen muss. Der folgende Bericht geht detailliert darauf ein, das Ergebnis von mehr als 1.260 weltweit befragten Personen zu teilen, die identifizierten, welche Fähigkeiten als entscheidend für DevOps und digitale Transformation gelten.

Einige wichtige Erkenntnisse sind:

• Die heute hauptsächlich verwendeten DevOps-Topologien stellen eine große Herausforderung dar.
• Die DevOps-Transformationsreise ist für mehr als 50 % immer noch sehr schwierig.
• Agile, DevOps und ITIL bekommen starke Konkurrenz durch SRE.
• Der DevOps-Mensch als hybrider Job und Rolle.

2021 Accelerate State of DevOps Report

Schließlich haben wir den Accelerate State of DevOps Report für 2021, der vom DevOps Research and Assessment Team von Google Cloud – auch bekannt als DORA – stammt. Die Umfrage wurde über sieben Jahre durchgeführt. Insgesamt haben mehr als 32.000 technische Fachkräfte aus aller Welt teilgenommen.

Historisch betrachtet ihre Forschung vier wichtige Softwarelieferkennzahlen, um zu bestimmen, wie gut DevOps-Teams funktionieren. Die diesjährige Forschung bestätigte jedoch eine zusätzliche fünfte Kennzahl für DevOps-Teams zur Erfolgsmessung:

• Einsatzfrequenz
• Vorlaufzeit für Änderungen
• Zeit zur Wiederherstellung des Dienstes
• Fehlerrate ändern
• (Neu) Von der Verfügbarkeit zur Zuverlässigkeit

Über die Lieferkennzahlen hinaus fand der Bericht auch viele neue DevOps-Trends, und das sind einige Highlights:

• Eine gesunde Teamkultur mildert Burnout in schwierigen Zeiten (wie wir alle kürzlich erlebt haben).
• Die besten Leistungsträger setzen weiterhin die Messlatte höher.
• SRE und DevOps ergänzen sich.
• Cloud-Akzeptanz steigert die Leistung.
• Die Sicherung Ihrer Software-Lieferkette ist unerlässlich – und steigert die Leistung.
• Gute interne Dokumentation ist ein Sprungbrett für die erfolgreiche Implementierung von DevOps.

Schritte zur erfolgreichen DevOps-Einführung

Nun, mit all diesen Erkenntnissen aus der Branchenforschung, wenden wir uns nun der Schaffung der richtigen Grundlage für DevOps zu. Jahr für Jahr nutzen Organisationen diese Schritte als Grundlage für ihre DevOps-Einführung.

Vorschritt: Aufbauen Sie ein Fundament

Es ist Schicksal, dass die Transformation von DevOps mit ihrer eigenen Entwicklung beginnt, beginnend mit einer Grundlage, die DevOps wirklich durch und durch unterstützen kann. In dieser Vorphase der Entwicklung werden Unternehmensleiter und andere Stakeholder:

• Erkennen Sie den Bedarf an besserer Kommunikation und Zusammenarbeit.
• Beginnen Sie mit schnellen Genehmigungen, um verschiedene Technologien einzusetzen, um die Lücke zu schließen.

Auch wenn dieser Prozess vielleicht überstürzt beginnt, ist es nichts, was man schnell erreichen kann. Im Laufe der Zeit beginnen Unternehmen, ihre Herangehensweisen zu verfeinern und die Technologie an ihre Ziele anzupassen. Schließlich entsteht eine Plattform, die DevOps im gesamten Unternehmen erleichtern kann. Wenn dies geschieht, befinden sich Organisationen an einem Punkt, an dem sie Ideen, Technologie, Wissen und Kennzahlen austauschen.

Anzeichen dieser Phase? Unternehmen, die...

• Große Softwarekäufe tätigen
• Schnelle Einführung neuer Praktiken

Schritt 1: Normalisiere die Tech-Stacks

Im ersten formellen Schritt der DevOps-Entwicklung beginnen Unternehmen, ihre Technologie-Stacks zu normalisieren. Wenn Teams organisch agile Praktiken auswählen, die zu ihnen passen, und beginnen, neue Methoden in Betracht zu ziehen, werden Sie diesen Schritt im Prozess erkennen können.

Ein wichtiger technischer Marker für diesen Schritt ist die Versionskontrolle. Teams implementieren sie und andere Praktiken, die als frühe Phasen der kontinuierlichen Integration gelten. Die Normalisierung von Tech-Stacks kann auch darin bestehen, Redundanz in der Infrastruktur zu reduzieren oder Anwendungen umzustrukturieren. Die Notwendigkeit, Redundanz zu reduzieren, steht im nächsten Teil des Prozesses im Vordergrund, aber sie beginnt bereits in Phase eins.

Schritt 2: Standardisieren

Da die Beseitigung von Redundanz in den Fokus rückt, implementieren Teams mehr Praktiken, die darauf abzielen, Varianzen in einem Tech-Stack zu verringern und zu standardisieren. In dieser Phase werden DevOps-Teams die Anzahl der Betriebssysteme als eine Form der Konsolidierung begrenzen.

Hier haben Teams, die sich unabhängig konsolidieren, die Möglichkeit zur Zusammenarbeit. Das übergeordnete Ziel ist eine standardisierte Familie von Technologien, die Hand in Hand zusammenarbeiten, um Zusammenarbeit und Entwicklung zu fördern.

Diese Phase führt zu weniger Gesamtkomplexität, was Teams eine größere Gelegenheit gibt, über mehrere Anwendungen hinweg zu arbeiten und ihr Fachwissen bestmöglich zu nutzen. Vorteile dieser Phase umfassen:

• Schnellere Anwendungsbereitstellung
• Fehlerreduktion
• Verbesserung der Servicequalität

Aus diesen Gründen ist Standardisierung ein zentrales Element im Stand von DevOps.

Schritt 3: Probieren Sie DevOps-Praktiken aus

In der vorherigen Phase findet die Standardisierung statt, während die Teams die inneren Abläufe ihrer Plattformtechnologie erkunden. Außerdem lernen sie das System wirklich kennen. In der DevOps-Praxisphase wechseln die Teams von der einfachen Erkundung des Systems hin dazu, Empfehlungen zu geben und es für DevOps zu nutzen.

Dies ist ein guter Zeitpunkt, um Schmerzpunkte zu bewerten. In der Regel erfordert dieser tiefgehende Ansatz, dass Organisationen alle Schwierigkeiten in der Bereitstellungsphase anerkennen. Die Implementierung kann für viele Organisationen, die DevOps-Best Practices noch nicht ausgearbeitet haben, schwierig sein.

Ein häufiges Problem ist, dass die Verbesserungen in früheren Entwicklungsschritten dazu geführt haben, dass Entwickler schneller zur Bereitstellung übergehen, als der Bereitstellungsprozess es unterstützen kann. Dies führt zu Engpässen der Operationen. Es ist entscheidend, dies schnell durch die Einführung zusätzlicher DevOps-Praktiken bei der Bereitstellung zu beheben. Dazu gehört, immer wieder dieselben Bereitstellungsmuster zu verwenden und die Bereitstellung vor Erreichen dieses Stadiums zu testen.

Schritt 4: Infrastruktur automatisieren

Mit hochprioritären Ergebnissen hilft Automatisierung, Teams noch erfolgreicher zu werden.

Zu den hohen Punkten gehören meist Bereitstellung und Systemkonfiguration. Wenn Teams die Infrastrukturbereitstellung automatisieren, lösen sie das Problem, das entsteht, wenn der Entwicklerdurchsatz die Bereitstellung übersteigt. Deshalb ist dies ein entscheidender nächster Schritt nach DevOps-Praktiken. Darüber hinaus hilft die Automatisierung der Konfiguration Teams, Software schneller bereitzustellen.

Automatisierung ist ein wichtiger Vorläufer von Self-Service. Sie ist der Katalysator für den letzten Schritt im DevOps-Prozess. Sie fördert Self-Service und führt zu größerer Effizienz in der gesamten Organisation.

Schritt 5: Selbstbedienung

In der Self-Service-Phase findet die IT-Praxis in einer gesamten Organisation statt und ist möglicherweise nicht auf ein einziges Kostenzentrum beschränkt. Dies ermöglicht Fortschritte innerhalb der Organisation, die den Self-Service optimieren.

Die Zusammenarbeit in dieser letzten Phase vervielfacht die Vorteile in früheren Schritten. Die bedeutendsten Fortschritte werden realisiert, wenn die Anwendungsautomatisierung die Standardisierung überschreitet und sich weiterentwickelt, um Cloud-Migration und andere höherwertige Prozesse einzubeziehen. Sicherheit entwickelt sich auch dadurch, die unmittelbaren Bedürfnisse des Teams zu erfüllen, um eine Grundlage für die Einhaltung der gesamten Organisation zu schaffen.

DevOps verstehen

Die Verfolgung der Forschung zum "Stand von DevOps" kann IT-Organisationen helfen, sich selbst zu vergleichen und Verbesserungsmöglichkeiten basierend auf dem Feedback anderer zu suchen. Die Aussichten für DevOps (und SRE) im Jahr 2022 sind vielversprechend, da Anwendungsbereitstellung und Automatisierung von Releases für eine erfolgreiche Organisation immer wichtiger werden.

Verwandte Literatur

• BMC DevOps Blog
• BMC Workload Automation Blog
• DevOps-Leitfaden mit 30+ Artikeln
• Der vollständige DevOps-Zertifizierungsleitfaden 2021-2022
• Workload Automation (WLA) vs. Robotic Process Automation (RPA): Was ist der Unterschied?
• Wie man eine Continuous Integration & Delivery (CI/CD)-Pipeline einrichtet

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.