zurück zum Artikel

DevOps trifft auch unter IT-Fachleuten noch häufig auf Skepsis. Es ist an der Zeit, die Missverständnisse auszuräumen und die Vorteile in den Fokus zu rücken.

DevOps beeinflusst schon seit mehr als einem Jahrzehnt die professionelle Softwareentwicklung. Innerhalb der IT stellt es bereits eine eigene Epoche dar. Von der ursprünglichen Idee hinter DevOps haben sich viele weitere abgeleitet. Das ist nachvollziehbar, führt aber häufig zu Missverständnissen, Stilblüten und Fehlern bei der Umsetzung. Worin liegt die Essenz von DevOps, welche Vorteile liefert das Konzept und welche Konsequenzen leiten sich daraus ab?

DevOps ist eine Grundeinstellung

Ende der 2000er-Jahre erkannte man in Entwicklung und Betrieb von Software, dass die strikte Trennung der Bereiche zu kritischen Problemen führt. Entwicklerinnen und Entwickler (Dev) reichten ihren Anwendungscode einfach an den Betrieb (Ops) weiter und lösten sich damit aus jeglicher Verantwortung. Traten während des Betriebs Fehler auf, galten als Schuldige stets die Developer. Übergaben fanden häufig manuell und in langwierigen Prozessen statt, der Informationsaustausch stockte oder brach komplett ab. Der Entwicklungsprozess schritt langsamer voran als notwendig. Das kostete nicht nur Geld und senkte die Qualität, sondern beschädigte auch das Vertrauen und verhinderte Innovation.

Die Erfindung von DevOps​

Patrick Debois, IT-Berater und Unternehmer, störte sich an den organisatorischen Hindernissen, die zwischen Entwicklung und Betrieb von Software bestanden. Sein Ziel war es, diese Hindernisse auszuräumen und die Zusammenarbeit zu verbessern. Die von ihm organisierte Konferenz DevOpsDays 2009 [1] im belgischen Gent schuf dafür die Grundlage.

Seitdem hat sich die Idee von DevOps nicht nur verbreitet, sondern als Standard sowohl in der agilen, klassischen als auch hybriden Softwareentwicklung etabliert.

Auf der ersten DevOps-Konferenz folgte daher die Entscheidung, daran etwas ändern zu wollen. Eine neue Grundeinstellung musste her, die auf drei einfachen Prinzipien basiert: vereinte Verantwortung, automatisierte Arbeitsabläufe und rasche Rückmeldungen.

Erreichen lässt sich das gesteckte Ziel nur durch einen massiven, organisatorischen Eingriff. Entwicklung und Betrieb müssen zusammenwachsen – getrennte Abteilungen sind passé. Teams müssen zusammenarbeiten. Das bedeutet, bisher oftmals getrennte Unternehmensteile aufzulösen, bisher getrennte Teams zusammenzulegen, bisher separiertes Wissen zusammenzuführen und bisher mangelndes Verständnis aufzubauen. Vorwürfe wie "Aus den Augen, aus dem Sinn!" weichen der Maxime "You build it, you run it!" Dieser Leitsatz fasst die Grundeinstellung von DevOps bis heute perfekt zusammen.

DevOps ist mehr als eine Grundeinstellung

Sobald die Entscheidung getroffen ist, gemeinsam Verantwortung tragen zu wollen, ergeben sich zwangsläufig Konsequenzen. Erfolgreiche Partnerschaften basieren nicht auf Diktat, sondern auf Kompromissen.

Zuerst müssen sowohl diejenigen, die Software [2] entwickeln, als auch diejenigen, die sie betreiben, das gemeinsame Ziel festlegen, die eigenen Absichten und Wünsche und die der anderen verstehen und zusammenbringen. Niemand darf mehr darauf bestehen, an bisherigen Gewohnheiten und Gepflogenheiten festzuhalten. Im Konsens gilt es zu klären, wie sich Prozesse und Werkzeuge harmonisieren lassen. Vereinte Verantwortung erfordert auch ein gemeinsames Verständnis und ein gemeinsames Einverständnis für ein bestimmtes Vorgehen. Rücken alle Teammitglieder auch räumlich zusammen, dann betrifft die Konsolidierung selbstverständlich auch die gesamte Hardware-Ausstattung, von der IT-Infrastruktur bis zum Arbeitsplatzrechner. Selbstredend muss auch das Unternehmen die entsprechende Zusammenarbeit ermöglichen.

Das gemeinsame Ziel jedes DevOps-Teams sollte dabei aus mindestens zwei Komponenten bestehen: qualitativ hochwertige Softwaresysteme für die Kunden schaffen und gleichzeitig eine steigende Ausliefergeschwindigkeit garantieren. Die entscheidenden Stichworte in diesem Zusammenhang sind Customer Experience und Time-to-Market. Darunter darf aber die Developer Experience nicht leiden. Development- und Operations-Mitarbeitende sollen durch DevOps nicht zu hochgetakteten Robotern mutieren. DevOps ist also eine Grundeinstellung, die aber ebenso Praktiken und Werkzeuge kombiniert – und einen Wandel der Unternehmenskultur erfordert.

SecDevOps und Co. sind Mythen

Kaum hatte sich DevOps verbreitet und halbwegs etabliert, entwickelte der Begriff eine Eigendynamik, die in Auswüchsen wie DevSecOps oder SecDevOps, aber auch DesignOps, TestOps oder gar ArchOps mündete. Das führte zu Irritation, weil es verschiedene Aspekte vermischt, die konträr oder quer zueinander liegen.

DevOps leitet sich von Development und Operations ab. Das sind zwei Disziplinen des Software-Engineering, die sich als vertikale Aspekte bezeichnen lassen und deshalb lange getrennt behandelt wurden. Es lässt sich nur betreiben, was zuvor entwickelt wurde. Der Betrieb folgt also auf die Entwicklung.

Kürzel und Zusätze wie Sec für Security, Arch (für Architecture), Test oder Design greifen weitere Aspekte auf. Diese sind aber nicht vertikal, sondern horizontal. Sie sind während der Entwicklung und während des Betriebs relevant (siehe Abbildung 2). Sie treten während des gesamten Engineering-Prozesses immer wieder auf. Design, Sicherheit, Architektur und Test sind nicht per se unwichtiger oder wichtiger als Development und Operations, sondern immer wieder von unterschiedlicher Relevanz und Umfang.

In der Praxis lässt sich DevOps nicht immer nach dem Idealbild umsetzen, weil häufig die Strukturen und Organisationen dafür fehlen. Beispiele liefern Auftragslösungen, bei denen die Entwicklung des Softwaresystems im Kundenauftrag erfolgt, der Kunde die Anwendung dann allerdings selbst betreibt. Hier lassen sich die Organisationsstrukturen nicht aufbrechen, die drei Prinzipien vereinte Verantwortung, automatisierte Arbeitsabläufe und rasche Rückmeldungen gelten aber dennoch.

Entwicklungs- und Betriebsteam fungieren in einem solchen Fall als virtuelles DevOps-Team mit vereinter Verantwortung, automatisierten Arbeitsabläufen und raschen Rückmeldungen. Prozesse und Werkzeuge bilden die Teams entsprechend ab. Das organisatorisch und räumlich – eventuell auch hinsichtlich Entwicklung und Betrieb – getrennte Team arbeitet also vollständig transparent zusammen. Hier lässt sich dann eventuell von Dev+Ops sprechen. Auch weitere Kombinationen sind möglich – und dass sie funktionieren, beweisen zahlreiche Open-Source-Projekte tagtäglich in der Praxis. In Mischformen können also Kompetenzen aus den Bereichen Entwicklung und Betrieb quer über mehrere Unternehmen verteilt sein.

Das Business gehört dazu

Im Gegensatz zu horizontalen Aspekten wie Sicherheit oder Design, Test oder Architektur ist das Business sehr wohl ein vertikaler Aspekt, der viel zu oft unter den Tisch fällt. Streng genommen müsste stets von BizDevOps die Rede sein.

Business deckt alle relevanten Aspekte ab, die sich mit dem Sinn und Zweck eines Softwaresystems sowie dessen Anforderungsanalyse und Planung beschäftigen. Das Business klärt, was zu entwickeln ist, Development klärt, wie es zu entwickeln ist, Operations klärt, wo es betrieben wird.

Vergesst die DevOps Engineers

Jedem der bereits erwähnten Schlagworte lässt sich in der Regel auch eine fachliche Spezialisierung oder Rolle zuordnen. DevOps Engineers stehen hoch im Kurs. Was genau ein DevOps Engineer ist, welche Aufgaben zu dieser Fachspezialisierung gehören und welches Wissen dafür notwendig ist, lässt sich jedoch kaum zuverlässig klären. Als echter DevOps Engineer darf sich streng genommen nur bezeichnen, wer von der Softwareentwicklung bis zu kleinsten Aspekten des Betriebs alles beherrscht.

Anstelle solcher Einzelkämpfer gelten in der DevOps-Praxis crossfunktionale Teams als Königsweg. Das bedeutet, dass in einem DevOps-Team Personen mit sowohl differenzierenden als auch sich überschneidenden Fähigkeiten gemeinsam arbeiten. Dazu gehören beispielsweise Entwickler, die UI-Design verstehen, Ops-Verantwortliche, die Software entwickeln können, Datenbank-Administratoren, die UI-Design und Testing beherrschen und so weiter. Die Kombinationen sind beliebig; Hauptsache, alle im Team benötigten Kenntnisse sind vorhanden, idealerweise mehrfach auf viele Köpfe verteilt. Fällt eine Person aus, können andere die Aufgaben übernehmen. Das Team bleibt stabil und arbeitsfähig.

Die Stabilität geht jedoch verloren, wenn eine einzelne Person die komplette Rolle als DevOps Engineer ausfüllen muss. Häufig sollen sich diese Einzelkämpfer dann um alle DevOps-Aspekte kümmern, die Werkzeuge und Prozesse etablieren und pflegen, den Betrieb organisieren und garantieren. Fällt die Person aus, ist das gesamte Team aufgeschmissen. Die vereinte Verantwortung lastet dann auf einer einzelnen Person – das widerspricht dem wichtigen DevOps-Grundprinzip.

Für alles gibt’s ein Werkzeug

Für jede Aufgabe gibt es nicht nur ein Werkzeug, eine Methode oder eine Technologie, sondern es existieren viele verschiedene, die immer unterschiedlich gut geeignet sind. Um Licht in dieses Dickicht zu bringen, greifen viele DevOps-Teams auf etablierte Muster und Blueprints anderer Teams zurück – in der Hoffnung, sich den Aufbau eines individuellen Werkzeugkastens ersparen zu können. Das ist jedoch eine Fehleinschätzung, die allzu oft in Missverständnissen und Dogmatismus mündet, wie Beispiele namhafter Unternehmen zeigen.

Das Unternehmen Spotify etwa gilt als einer der Vorreiter in Sachen Agilität. Der Streaming-Dienst hat eine Auswahl an Werkzeugen, Methoden und Technologien sondiert und daraus ein auf das Unternehmen, dessen Produkt sowie den adressierten Markt passgenaues Arbeits-Set zusammengestellt. Spotify hat diesen Ansatz auch sehr offensiv publik gemacht, unter anderem im Rahmen verschiedener Konferenzen, sodass sich schnell die Bezeichnung Spotify-Modell etablierte. Daraufhin fühlten sich viele Unternehmen motiviert, genau dieses Modell exakt so wie Spotify aufzugreifen und anzuwenden. Das Setup ist allerdings auf Spotify maßgeschneidert. Bei dem Streaming-Dienst passt das Spotify-Modell perfekt, bei anderen Unternehmen hingegen nicht.

Jedes DevOps-Team muss sich aus den vorhandenen Werkzeugen, Methoden und Technologien ein eigenes maßgeschneidertes Set zusammenstellen. Einflussfaktoren für die Auswahl sind Erfahrung und Vorlieben, Organisation und Zielsetzung. Dass beispielsweise ein ganzer Industriezweig ein bestimmtes Werkzeug favorisiert, heißt noch lange nicht, dass es auch für jedes DevOps-Team geeignet ist.

Die Wahrheit liegt im Code

Kaum finden sich Fachanalysten, Developer, Entwicklerinnen und Betriebler im selben Team wieder, starten die Diskussionen über die Vorgehensweisen. In der Softwareentwicklung haben sich über die Jahrzehnte hinweg viele als sinnvoll geltende Regeln, Erfahrungen und Praktiken etabliert. Diese Regeln eignen sich auch im DevOps-Kontext. Sie bilden die Grundlage für automatisierte Arbeitsabläufe und rasche Rückmeldungen.

Für alle Developer gilt dabei, dass sie lesbaren Code schreiben müssen. Dieser Code muss für alle Beteiligten einsehbar und verständlich sein. Das setzt einen professionellen, einheitlichen Programmierstil und selbstverständlich Tests voraus; unverständlicher Code ist in jedem Fall zu überarbeiten. Der fachliche Aspekt, was zu entwickeln ist, muss im Code nicht nur verankert sein, sondern sich auch unmissverständlich daraus ablesen lassen. Dazu kommen konsequenterweise Versionskontrollsysteme sowie Programme zur Fehlerverfolgung zum Einsatz. Sämtliche DevOps-Teammitglieder müssen mit diesen Werkzeugen umgehen können und Zugang zu ihnen haben.

Zu guter Letzt sind noch einige wichtige Weisheiten und Prinzipien zu beachten, wie etwa KISS für "keep it simple, stupid", YAGNI für "you aren’t gonna need it" und DRY für "don’t repeat yourself". Denn je mehr unterschiedliche Personen zusammenarbeiten, desto mehr Ideen und Wünschen fließen ein, desto mehr Interpretationsvielfalt entsteht und desto wahrscheinlicher ist es, dass ein Team in die falsche Richtung abbiegt.

Kontinuität etablieren

Wer mit seinen Produkten den gewachsenen Marktanforderungen gerecht werden will, muss regelmäßig und in kurzen Zeitabständen neue oder verbesserte Softwaresysteme ausliefern. Sei es, neue Funktionen nachzulegen oder wichtige Sicherheitskorrekturen bereitzustellen, um am Markt relevant zu bleiben. Das gelingt durch kontinuierlich ablaufende Arbeitsschritte, erfordert allerdings auch ein hohes Maß an Erfahrung.

Kontinuität zu gewährleisten, ist ab dem Punkt entscheidend, an dem der fertige Code in das Versionskontrollsystem übertragen ist. Dazu bedarf es einer maßgeschneiderten und optimal konfigurierten Pipeline, die hinterlegte Tests ausführt, die Qualität des Codes prüft und Codeänderungen in die Basis sowie Artefakte in andere Systeme integriert. Über die Pipeline läuft zudem das Paketieren für unterschiedliche Plattformen, das Verteilen der Pakete über die entsprechenden Kanäle sowie gegebenenfalls das Installieren auf Zielsystemen.

Welche Bereiche die Pipeline im Detail abdecken soll, muss das DevOps-Team individuell entscheiden: Von Continuous Testing bis Continuous Delivery ist alles möglich. Die Verteilfrequenz einer Anwendung steigt dadurch erheblich, lässt sich mit entsprechenden Maßnahmen aber gezielt justieren.

Automatisierung leben

Kontinuität bedeutet schlicht, bestimmte Aufgaben regelmäßig abzuarbeiten, sobald ein bestimmtes Ereignis eintritt. Automatisierung bedeutet hingegen, manuelle, aufwendige, wiederkehrende Arbeitsschritte ohne menschlichen Eingriff durchzuführen. Kontinuität kann also manuell sein, Automatisierung muss nicht kontinuierlich erfolgen.

Auch Automatisierung ist ein Aspekt, der die Ausliefergeschwindigkeit erheblich reduzieren kann. Gleichzeitig erfordert sie eine Investition in die erstmalige Automatisierung der Aufgaben und danach in deren Pflege. Zudem ist immer wieder ein signifikantes Maß an Erfahrung notwendig, um zu wissen, was sich wie in welcher Situation automatisieren lässt. Und wann es unangebracht wäre.

Im Zuge der Automatisierung ist dann auch deren Überwachung relevant. Denn sobald etwas unbeobachtet abläuft und das DevOps-Team auftretende Probleme nicht rechtzeitig erkennt, droht die Gefahr massiver Ausfälle. Das Höchstmaß an Automatisierung stellt derzeit der GitOps-Ansatz dar, der allerdings auch die Komplexität erhöht.

Alles lässt sich verbessern

Perfektion gibt es nicht; nur einen temporären Idealzustand, der den aktuellen Stand der Gesellschaft, der Unternehmen und der Technologie adaptiert. Deshalb existiert auch kein dauerhaft perfektes DevOps-Team. Es gibt immer wieder neue Möglichkeiten der Verbesserung. Kein DevOps-Team sollte sich scheuen, diese zu suchen und umzusetzen – oder zumindest auszutesten.

Regelmäßig prüfen sollte ein DevOps-Team, wie die Zusammenarbeit miteinander und nach außen funktioniert. Ursachen für Störungen können eine veränderte Team-Zusammensetzung sein oder sich ändernde Kundenwünsche. DevOps-Teams müssen nicht nach Scrum arbeiten, dennoch sind agile Methoden wie etwa Retrospektiven hilfreich. Das Team sollte klären, wie sich die Arbeitsprozesse verbessern lassen, neue oder bessere Methoden, Technologien und Werkzeuge suchen und adaptieren, fehlendes Wissen aufbauen oder ausgleichen. Mit dem DORA DevOps Quick Check [3] und DevOps Research and Assessment [4] stehen gute Hilfsmittel zur Verfügung.

Entscheidend ist am Ende die Qualität des Teams. So anschaulich und verlässlich Zahlen auch erscheinen mögen, als alleiniges Kriterium sind sie mit Vorsicht zu genießen. Werte wie 4,76 von 5 Sternen, eine um 15 Punkte gestiegene Auslieferungsrate oder eine in der vergangenen Woche 0,2 Sekunden schnellere Rückmeldezeit sind irrelevant, wenn Maßnahmen zur Optimierung allein auf die Zahlen fokussiert erfolgen.

Der Weg ist individuell

Der Weg zu DevOps ist individuell. Vereinte Verantwortung, automatisierte Arbeitsabläufe und rasche Rückmeldungen sind essenziell. Sobald Silos abgeschafft sind und sich eine gemeinsame Zusammenarbeit etabliert hat, findet automatisch ein positiver Kulturwandel in Projekten, Bereichen, Unternehmen und Partnerschaften statt. Dabei muss nichts von Grund auf neu erfunden werden. Es existieren zahlreiche etablierte und individuell passende Praktiken, Methoden und Werkzeuge. Aus diesem Fundus lässt sich das herausgreifen und zusammenstellen, was die individuellen Bedürfnisse eines DevOps-Teams abdeckt. Sogar das Projektvorgehen lässt sich flexibel gestalten: klassisch, agil oder hybrid. Mit dem Willen zur stetigen Verbesserung lassen sich Kosten senken, die Qualität und die Auslieferungszeiten weiter verbessern. Kontinuität und Automatisierung entlasten alle Beteiligten und stabilisieren das Team, wenn eine oder mehrere Personen ausfallen sollten.

Mark Lubkowitz
ist Journalist und Software Engineer. Er arbeitet bei msg als Software-Architekt im Bereich Forschung und Entwicklung und setzt sich kritisch mit neuen Technologien auseinander. (map [5])

URL dieses Artikels:
https://www.heise.de/-9585334

Links in diesem Artikel:
[1] https://legacy.devopsdays.org/events/2009-ghent/
[2] https://www.heise.de/thema/software
[3] https://dora.dev/quickcheck/
[4] https://www.devops-research.com/research.html
[5] mailto:map@ix.de

Copyright © 2024 Heise Medien