Ein Maturity-Modell für DevOps

15. Oktober 2019

Daniel Meixner

Dieser Blogbeitrag ist ein Repost und stammt im Original aus dem Tech-Blog von TechWiese, der in diesen Blog integriert wurde.

DevOps ist endgültig im Mainstream angekommen und Firmen aller Größen interessieren sich dafür. Donovan Brown definierte „People, Process, Products“ als die Hauptzutaten auf dem Weg zur DevOps-Organisation, mit dem Ziel kontinuierlich „Value“ an die Kunden zu liefern.  

In der Diskussion um DevOps wird dabei häufig auf einen einzelnen Aspekt fokussiert: Die vollständige Automatisierung von der Änderung im Code bis zum ausgelieferten Feature. Tatsächlich handelt es sich bei dieser „Pipeline“ um ein Kernkonstrukt. Allein das Erstellen dieser Pipeline für ein reales Projekt kann sehr aufwendig sein und wird sich in vielen Fällen nicht nur durch „Products“ erschlagen lassen, sondern erzwingt bereits eine Investition in „People“ und „Process“.  

So werden durch die Automatisierung zwangsweise Teams aus dem Entwicklungs- und Operationsbereich miteinander sprechen müssen – schließlich will man ja, dass am Ende alles reibungslos klappt. Gleichzeitig ändern sich genau dadurch auch altgediente, bewährte Prozesse: Dinge, die vorher manuell gemacht wurden, werden automatisiert. Abläufe werden schneller geändert oder ganz weggelassen. All das bietet genug Potential für viel Arbeit, viele Konflikte und ist am Ende dennoch lohnenswert. Das kann jeder bestätigen, der auf eine funktionierende Pipeline zurückgreifen kann. Aber dennoch ist das nur der erste Schritt auf dem Weg zur DevOps-Organisation. 

Gene Kim hat im Buch The Phoenix Project“ anhand einer Metapher drei Wege zur DevOps-Organisation beschrieben. Zahllose Gespräche und Consulting-Missionen bei Kunden haben mir gezeigt, dass diese drei Wege aber nicht nur eine sinnvolle Wegbeschreibung darstellen, sondern auch gleichzeitig sehr gut den Reifegrad der jeweiligen Organisation darstellen – ähnlich zu einem Maturity-Modell. Auf diese Weise wird die „DevOpsyness“ einer Organisation messbar. Demzufolge könnte ein Maturity-Modell für DevOps folgende Level aufweisen: 

Level 0  

Im Stadium „Level 0“ ist das Thema DevOps noch völlig unangetastet und noch nicht strategisch angegangen. 

Level 1 – System Thinking 

Analog zu Gene Kims Metapher wird im Stadium „Level 1“ versucht, durch systemweites Denken dafür zu sorgen, dass die Prozesse allgemein besser laufen, keine Flaschenhälse entstehen und das Gesamtsystem zuverlässiger wird.  

Bildlich gesprochen und um Genes Metapher aufzugreifen: Man sorgt dafür, dass in einer Fabrikhalle die Fließbänder laufen. In Bezug auf Software übersetzt: Man setzt auf weitgehende Automatisierung – im besten Fall hat man eine Pipeline, wodurch der Weg „von links nach rechts“ beschleunigt wird. 

Level 1 ist die Grundlage für die nächsten Level – aber keinesfalls das Endstadium, auch wenn, wie oben beschrieben, im Zusammenhang mit DevOps oftmals nur von Pipelines gesprochen wird. Ist die Konzentration auf Level 1 vielleicht ein Hinweis darauf, in welchem Stadium man sich selbst befindet? 

Level 2 – Amplify Feedback  

Der zweite Weg nach Gene Kim beschreibt ein System, welches Feedback ermöglicht. Feedback kann vom Kunden kommen, kann aber auch von allen Beteiligten jederzeit geliefert werden. Das Ziel von Feedback ist es, immer eine Möglichkeit zu schaffen, bestehende Missstände zu ändern – im besten Fall schnell, um größeren Schaden abzuwenden.  

Ein reales Beispiel in der Automobilindustrie ist das vielzitierte Andon-Cord: Eine Schnur, die – angeblich – in den Produktionsstätten von Toyota über den Fertigungslinien hängt. Wenn einem Werksmitarbeiter am Band auffällt, dass etwas nicht stimmt, kann er daran ziehen und die komplette Linie steht, was generell zu vermeiden ist, da es ja mit hohen Kosten verbunden ist. Durch die Möglichkeit am Kabel zu ziehen, hat der einzelne Mitarbeiter nicht nur mehr Gewicht in seinem Feedback, sondern es wird auch dafür gesorgt, dass Fehler, die potentiell Folgefehler nach sich ziehen oder später nur verschleiert werden, schnellstens behoben werden müssen. 

Im Softwarekontext darf man hier die Frage stellen: Wie oft passiert es, dass man Features weiterentwickelt, bei denen klar ist, dass man sie nicht braucht? Wie oft passiert es, dass der Build fehlschlägt, aber es wird dennoch fleißig weiter Code gepushed? Wie oft passiert es, dass man auf Fehler stößt, aber der Zusammenhang zu Builds, Codeänderungen und Arbeitsauftrag unklar ist? 

Ein gutes Feedbacksystem muss es ermöglichen, schnelle Reaktionen zuzulassen, und baut auf ein System auf, das Rückschlüsse auf vorausgegangene Ereignisse zulässt. Unterm Strich ermöglicht Level 2 den Weg von Information „von rechts nach links“. Hier hilft sicherlich das richtige Werkzeug – aber vor allem braucht es auch jemanden, der sich für das Feedback interessiert, was im einfachsten Fall durch erhöhte Transparenz über den aktuellen Systemzustand motiviert werden kann.  

Ist der Brian the Build Bunny in der Software-Entwicklung vielleicht das Gegenstück zur stehenden Produktionslinie im Automobilbau? 

Level 3 – Experimentation and Learning 

Ich habe bisher sehr wenige große Organisationen erlebt, die bereits erfolgreich den dritten Weg eingeschlagen haben. Was sicher auch daran liegt, dass dieser meist eine Änderung der Unternehmenskultur erfordert. Wenn Level 1 und 2 erreicht sind, kann ich schnell und zuverlässig liefern (Level 1) und erhalte schnelles, zuverlässiges Feedback (Level 2) und weiß auch damit umzugehen. Genau diese beiden Fähigkeiten versetzten mich theoretisch in die Lage, um zu experimentieren – schließlich würde ich über den Feedback-Kanal (von rechts nach links) schnell mitbekommen, wenn das Experiment fehlschlägt. Und über meine Pipeline (von links nach rechts) könnte ich im Notfall schnell korrigieren.  

In der Praxis bedarf es aber mehr als nur Technik: Wenn die Unternehmenskultur nicht darauf ausgelegt ist zu akzeptieren, dass Experimente missglücken können müssen, dann wird dieses dritte Level nicht praktizierbar sein. Wer wird sich schon eingestehen, dass das neue, teure Feature am Ende doch niemand nutzt? Wie steht man als Team da, wenn man ständig Experimente durchführt, die missglücken? Liegt es umgekehrt nicht in der Natur der Sache, dass Experimente auch fehlschlagen müssen, weil es sonst keine Experimente sind? Und ist nicht fast jede Entwicklung, erstmal eine Wette auf eine unbestätigte Hypothese dazu, wie Menschen die Software verwenden werden? 

Microsoft hat selbst vor einigen Jahren begonnen, die Transformation zur DevOps Company anzutreten. Es gibt dazu Videos und Dokumente, außerdem natürlich jede Menge offizieller Docs, die Azure DevOps erläutern. Wer das Thema DevOps auf unterhaltsame Weise vertiefen will, dem sei Gene Kims Roman ans Herz gelegt. Unter Berücksichtigung der drei Level, der damit notwendigen Investitionen und der zu erwartenden Dauer gilt auch beim Thema DevOps, dass der Weg das Ziel ist. Eine Pipeline macht noch kein DevOps – aber es ist der erste Schritt in die Richtung.  

Der Autor

Daniel Meixner (Azure AppDev Specialist) stellt euch im Rahmen dieses Gastbeitrages das Thema DevOps vor und gibt damit einen hervorragenden Überblick dazu. Daniel ist auch auf Twitter unter @DanielMeixner zu finden