Wie reif ist euer DevOps? – Einige Gedanken zur Messung des Fortschritts

Spoiler: Es ist ehrlich gesagt nicht von Bedeutung.

In letzter Zeit haben wir des Öfteren von Kunden eine Frage gestellt bekommen:

Wie misst man Fortschritt in Bezug auf Dev(Sec)Ops? Gibt es hierfür ein Maturity Model oder eine Menge an Skills, welche man bei allen Beteiligten voraussetzen oder schulen kann?

Dies ist insbesondere für größere Organisationen von Bedeutung, wenn sie ein solches Zusammenarbeitsmodell für eine größere Anzahl an Teams ausrollen wollen. Um einen Ausblick auf die Antwort zu geben: Ich glaube, die Frage zielt in die falsche Richtung.

Aus Gründen der Lesbarkeit werde ich für den Rest des Posts den Begriff DevOps benutzen. Dies liegt daran, dass die zugrundeliegenden Prinzipien auch dort greifen und somit DevSecOps mit einbeziehen. Wenn ihr euch unsicher seid, ob ihr mit eingeschlossen seid: Fühlt euch mit einbezogen.

Um das Problem zu verstehen, müssen wir zunächst einen Blick darauf werfen, was „DevOps” ist. Es bedeutet, dass Produktteams die Verantwortung für eine ganzheitliche Lösung eines Problems übernehmen. Dies beinhaltet unter anderem die Auswahl von Methoden, Technologien, Sicherheits- und Betriebsthemen und vieles, vieles mehr. Das Ergebnis wird oft auch auf folgenden Ausspruch komprimiert: “You build it, you run it!”. Obwohl dies bereits den Charakter ganz gut zusammenfasst, fehlt ein kleiner, aber sehr wichtiger Teil: “You decide!”

Maturity Models

Somit ist es also an den Teams, diese wichtigen Entscheidungen selbst zu treffen. Wie kollidiert dies nun mit einem Maturity Model? Nun, ein Maturity Model erzeugt implizit ein paar Nebeneffekte in einer Organisation:

• Einheitslösungen („Nach dieser KPI machen 97 % unserer Teams richtiges DevOps!”)
• Messungen („Mein DevOps ist besser als Dein DevOps!”)
• Endgegner („Wenn wir Problem x gelöst haben, sind wir mit DevOps fertig!”)

Diese Effekte kollidieren direkt mit der Natur von DevOps. Aus Prinzip ist DevOps ein Infinite Game wie von Simon Sinek beschrieben . Das heißt, dass kein absolutes Ziel angestrebt werden kann. Stattdessen versuchen die Mitspieler, eine nachhaltige Zukunft in ihrem Bereich aufzubauen und so lange wie möglich mitzuspielen. Und jedes Mal, wenn man ein Problem erfolgreich überwunden hat, werden sich neue Herausforderungen einstellen oder bisher ausreichende Lösungen sich als nicht mehr praktikabel erweisen.

Um dies zu illustrieren, möchte ich ein Beispiel aus der Praxis anbringen. Vor einiger Zeit arbeitete ich in einem Projekt, in dem die CI/CD-Pipeline extrem langsam war und sehr lange brauchte, um Software bereitzustellen. Wir hatten ebenfalls eine Testsuite, die zwar einige Zeit benötigte, aber verglichen mit dem Deployment war dies ein geringeres Problem. Nach ein paar Wochen waren alle genervt von den Laufzeiten der Pipeline. Somit wurde einiges an Arbeit und Entwicklung darin investiert, diese schneller zu machen und wir waren in der Lage, in einem Bruchteil der Zeit zu deployen. Auf einmal war die Testsuite, welche vor einer Woche noch ein kleineres Problem war, unsere größte zeitliche Hürde auf dem Weg in die Produktion.

Heißt dies, dass die Testsuite von Anfang an nicht ausreichend war? Nein. Sie war ausreichend für die Umgebung, in der am Anfang operiert wurde. Aber wenn sich die Bedingungen ändern, muss man den Zustand neu bewerten. Und dies ist die Basis des Problems mit einem Maturity Model. Diese bieten meistens eine absolute Einschätzung bezüglich der Lage ein. Damit ist man aber nicht in der Lage, ein sich bewegendes Ziel zu treffen.

Basis-Fertigkeiten

Herkömmlicherweise werden Teams oft so zusammengestellt, dass sie und ihre Fähigkeiten sich ergänzen. Ergibt es daher hier vielleicht Sinn, eine minimale gemeinsame Liste von Fähigkeiten als Grundvoraussetzung zu definieren? Dies beißt sich ebenfalls mit der Definition, die wir oben gesehen haben. Durch eine zu enge Auswahl von Technologien und Fertigkeiten nimmt eine Organisation effektiv den Teams diese Entscheidung ab. Und wenn Teams eine Entscheidung nicht mehr treffen, erzeugt dies eine potentielle Sollbruchstelle.

Aber was kann an dieser Stelle getan werden? Wenn man sich den DORA State of DevOps report 2019   anschaut, gibt es hier gute empirische Daten, wie so eine Transformation erfolgreich sein kann. Anstatt eine Liste an Fähigkeiten zu definieren und die Mitarbeiter danach zu schulen oder einzustellen, haben sich Communities of Practice und andere Bottom-up-Ansätze als wesentlich erfolgreicher erwiesen. Ein erfolgsversprechender Weg ist es daher, eine Kultur von Lernen und Kollaboration zu etablieren. Diese muss allerdings von der Organisation durch die Bereitstellung von Zeit und entsprechenden Ressourcen unterstützt werden.

Der weitere Weg

Um auf die initiale Frage zurückzukommen: Wie misst man denn nun seinen DevOps-Fortschritt? Am Ende spielt diese Messung keine Rolle. Weil die Frage uns keine Orientierungshilfe auf unserer DevOps-Reise gibt.