DevOps?! Gerne aber richtig!

Dieser Artikel ist erstmal erschienen in der Java aktuell 01/20

Viele Organisationen gehen den Weg in Richtung DevOps. Einige von ihnen schon länger und sehr erfolgreich. Von diesen Teams lässt sich lernen, wie eigenständige Teams mit zufriedenen Mitarbeitern schnell Features an ihren spezifischen Markt bringen und dabei eine stabile Produktionsumgebung gewährleisten.

Bevor der DevOps-Frust einsetzt, sollte man sich Gedanken um die Transformation machen, denn DevOps ist weniger Technologie als vielmehr Zusammenarbeit, Kultur, Lean-Produktmanagement und Lean-Management. In Studien und Umfragen wird erforscht, was Organisationen umsetzen, die erfolgreich DevOps einsetzen. In diesem Artikel stelle ich einige Ergebnisse aus meiner Erfahrung aus Ministerien, Behörden und der öffentlichen Hand Deutschlands, der Wirtschaft und mehreren Studien vor.

Was ist DevOps?

Für DevOps gibt es keine allgemeingültige Definition. Das habe ich in den Organisationen, die bereits auf dem Weg sind und die ich begleitet habe, kennengelernt. Dadurch kommt es oft zu Missverständnissen und enttäuschten Erwartungen. Alle Definitionen, die ich kenne, lassen sich für mich jedoch damit zusammenfassen: „DevOps ist eine Reihe von Methoden, die es Organisationen erlauben, Änderungen an Systemen schnell durchzuführen, ohne die Qualität der Systeme zu beeinträchtigen“ [1]. Konkret heißt dies, dass wir Features mit DevOps schnell und in hoher Qualität an unsere Kunden bringen können. Um das zu ermöglichen, ist es nötig, dass die einzelnen Teams verantwortlich für den kompletten Lifecycle ihres Produktes sind; von der Konzeption über die Entwicklung und Integration bis hin zum Betrieb.

Mehr Features durch DevOps

Ein Aspekt, wieso Organisationen auf DevOps setzen, ist, dass sie mehr Features an den Markt bringen möchten. Die Thesen der „State of DevOps“-Studien unterstützen dieses Vorhaben. Beispielsweise verbringen Organisationen und Teams, die als „Elite“ klassifiziert wurden, 50 Prozent ihrer Zeit mit der Entwicklung neuer Features [2], wohingegen „Low-Performer“ nur 30 Prozent ihrer Zeit in neue Features investieren. Sie investieren hingegen das Doppelte [2] ihrer Zeit in Bugs und Security-Probleme. Außerdem ein Vielfaches in klassische Customer-Support-Tätigkeiten (siehe Abbildung 1).

Der DevOps-Weg

Wenn eine Organisation sich entschieden hat, den DevOps-Weg zu gehen, entscheidet sie sich dafür, all ihre Prozesse und Kriterien zu überdenken. Silos zwischen Betrieb und Entwicklung werden abgerissen. Alte Wege werden von anderen Menschen beschritten und neue Wege tun sich auf. Deswegen ist es wichtig, dass dieser Weg durch regelmäßige Retrospektiven begleitet und neu ausgerichtet wird. Fortschritte sollten messbar sein, damit Experimente evaluiert werden können.

Erfolge messen

Wie für jede Organisation ist es für DevOps-Organisationen wichtig, KPIs (Key Performance Indicators/Kennzahlen) zu erfassen, die neben finanziellen Aspekten den Erfolg der Organisation messen. Integraler Bestandteil einer KPI ist es, die Leistung eines Systems auf den Punkt zu bringen. Der Mehrwert, den DevOps Organisationen bietet, ist meist die bedarfsgerechte Entwicklung und der Betrieb von Software. In manchen Fällen nutzen Organisationen nur betriebsrelevante KPIs, um den eigenen Erfolg zu messen. Die Erfahrung zeigt, dass es hier kein allgemeingültiges Bild auf DevOps-KPIs gibt. Da passiert es oft, dass es Dev- und DevOps-Teams gibt. DevOps löst die Silos „Dev“ und „Ops“ auf. Als Team sollten wir jedoch Verantwortung für den gesamten Prozess übernehmen und einer Trennung entgegenwirken.

Aus dem Zusammenlegen beider Bereiche lassen sich fünf KPIs ableiten, die zu einer übergeordneten KPI zusammengefasst wird. Der erste Indikator Delivery Lead Time To Change beschreibt, wie viel Zeit zwischen Fertigstellen der Änderung (commit) und tatsächlichem Übergang in die Produktion vergeht (siehe Tabelle 1). Die Kennzahl Deployment Frequency beinhaltet, wie oft Änderungen in die Produktion gebracht werden (siehe Tabelle 2). Außerdem die Change Fail Rate: die Anzahl der fehlgeschlagenen Änderungen, den erfolgreichen Änderungen (zum Beispiel Bugs und zurückgerollte Releases) gegenübergestellt. Unter Mean Time To Restore versteht man, wie viel Zeit nach einem Ausfall vergeht, bis die Systeme wieder normal operieren (siehe Tabelle 1). Zuletzt benötigen wir noch die Availability, also die Verfügbarkeit im Jahresmittel der Produktionsysteme. Diese fünf KPIs lassen sich unter dem Dach der Software Delivery Performance zusammenfassen. Als DevOps-Organisation ist die Software Delivery Performance unsere KPI. Sie fasst alle Themengebiete zusammen, in denen wir Experten sind.

---

---

Diese KPIs können verwendet werden, um den DevOps-Weg zu beobachten und zu prüfen. Experimente, Methoden und Technologien zeigen ihre Auswirkungen und sind echte Daten, nicht nur ein Gefühl. Gerade am Anfang lohnt es, sich die Frage zu stellen, wie man innerhalb dieser KPIs steht. Die „State of DevOps“-Studie 2018 [2] hat ihre Teilnehmer in mehrere Kategorien aufgeteilt: Elite-, High-, Medium- und Low-Performer. Beim Vergleich von High- und Low-Performern zeigen sich große Unterschiede.

So deployen High-Performer ihre Software beispielsweise 46 Mal (siehe Abbildung 2) öfter in die Produktion als Low-Performer. Die benötigte Zeit von Änderungen bis hin zum Übergang in die Produktion ist ganze 440 Mal kleiner (siehe Abbildung 3). Im Falle eines Ausfalls können High-Performer ihre Systeme 170 Mal schneller in den Normalzustand zurückversetzen (siehe Abbildung 4). Außerdem resultieren Änderungen fünf Mal seltener in Rollbacks oder Bugs (siehe Abbildung 5). Das allein sind starke Argumente für den DevOps-Weg.

Capabilities

Gerade bei Themen mit Technologie-Fokus nutzen wir oft Reifegradmodelle, um unseren Fortschritt zu messen. Reifegradmodelle beschreiben einen statischen Pfad, sind unterteilt in mehrere Stufen und charakterisieren einen finalen Zustand. Das passt nicht zum DevOps-Weg. Ähnlich wie eine agile Transition hat es viel mehr mit Menschen als mit Technologie zu tun. Das lässt sich nur schwer in Grade einteilen und wird nie wirklich fertig. Deswegen kann ein flexibleres Modell, dass auf Capabilities (Kompetenzen/Fähigkeiten) setzt, auf die Bedarfe einzelner Organisationen besser eingehen. Basierend auf den „State of DevOps“-Studien der letzten Jahre, wurden 24 Capabilities in fünf Kategorien identifiziert [3], die auf die Software Delivery Performance eingehen: Continuous Delivery, Architektur, Produkt und Prozesse, Lean-Management oder -Monitoring sowie Kultur.

1. Continuous Delivery Capabilities

Ein Teil der 24 Capabilities lässt sich unter Continuous Delivery klassifizieren. DevOps-Teams können viele dieser Methoden ohne Abhängigkeiten einsetzen und so den Grundstock für eine erfolgreiche Transition schaffen.

1.1 Versionskontrolle – überall

Die Nutzung moderner Versionskontrollsysteme bildet das Fundament für den DevOps-Weg. Dennoch sollte nicht nur der Code der Anwendungen versioniert werden, auch die Konfiguration der Anwendung, Skripte für die Automatisierung, System- und Umgebungskonfigurationen sollten versioniert werden.

1.2 Vollautomatisierte Deployment-Prozesse

Deployments, die ohne einen manuellen Schritt durchgeführt werden, beschleunigen das Team beim Rollout überdurchschnittlich. Gleichzeitig erfordert dies verlässliche Tests.

1.3 Regelmäßige Check-ins – Continuous Integration

Als erster Schritt, um Continuous Delivery zu implementieren, gilt Continuous Integration. Wenn wir Continuous Integration einsetzen, dann checken wir regelmäßig unseren Code ein. Dieser Check-in wird automatisiert getestet und Fehler können frühzeitig behoben werden. Der Continuous-Integration-Prozess erstellt die ersten Artefakte, die später „released“ und „deployed“ werden können.

1.4 Weg mit den langlebigen Branches – Trunk-Based Development

Trunk-Based Development ist eine Methode, Versionsverwaltung zu nutzen. Dabei werden maximal drei Branches genutzt. Branches haben generell eine sehr kurze Laufzeit, beispielsweise von maximal einem Tag, bevor sie in den Master zurückgeführt werden. Diese Methode ermöglicht disziplinierten Teams, durch die Anwendung von Feature-Toggles, eine Code-Freeze-freie Entwicklung. Die „State of DevOps“-Studien zeigen, dass Trunk- Based Development die Methode ist, die hoch-performante DevOps-Teams ausmacht.

1.5 Test-Automatisierung

Gute Automatisierung der Tests zeichnet sich dadurch aus, dass sie verlässlich funktioniert und ohne manuellen Aufwand in unseren Softwareentwicklungsprozess eingebunden ist. Wir müssen uns darauf verlassen können, dass Tests echte Bugs finden und nicht falsch-positive Ergebnisse liefern. Als Entwickler sollten wir für diese Tests verantwortlich sein. Diese Merkmale zeichnen eine gute Test-Automatisierung aus.

1.6 Testdaten-Management

Tests erfordern Daten. Diese müssen regelmäßig und sorgfältig gepflegt werden. Daten, die für die automatisierten Tests benötigt werden, sollten zu jeder Zeit verfügbar und anpassbar sein und nicht durch die Anzahl der Tests oder die Anzahl der Ausführungen limitiert werden. Bei Testdaten gilt der Grundsatz, wie bei Applikationscode: Weniger ist mehr.

1.7 Integration von Security in den Softwareentwicklungsprozess – DevSecOps

Security-bezogene Bugs zählen zu den schwerwiegendsten Problemen. Sie von Anfang an zu vermeiden muss das oberste Ziel sein. Wenn Info-Sec-Experten bereits frühzeitig in das Design, die Entwicklung und das Testing hinzugezogen, Security Reviews abgehalten und geprüfte Security-Bibliotheken verwendet werden, dann können viele Bugs im Vorfeld vermieden werden. Teams lernen von diesen Experten und können die Expertise aus dem Team heraus in die Projekte tragen. Sicherheitsrelevante Features sollten in den automatisierten Test-Suites getestet werden.

1.8 Continuous Delivery implementieren

Continuous Delivery ist eine Methode, mit der Software zu jeder Zeit imstande ist, ausgerollt zu werden, und das zu jedem Zeitpunkt im Entwicklungszyklus. Diesen Zustand zu halten, ist, noch vor neuen Features, von höchster Priorität. Durch Transparenz und schnelles Feedback zu Qualität und Deploybarkeit können Probleme schnell durch das ganze Team behoben werden. Ziel ist es, bei Bedarf die Systeme in der Produktion zu jeder Zeit aktualisieren zu können.

Weitergehendes wird im Buch „Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation“ (ISBN 9780321601919) von Jez Humble angesprochen.

2. Architektur-Capabilities

Klassische Architektur fokussiert sich auf Tool- und Technologieauswahl. Erfolgreiche DevOps-Teams wissen, welche Tools und Technologien sie benötigen. Architekten in diesem Umfeld arbeiten mit den Teams eng zusammen, damit sie bessere Ergebnisse erzielen können, zeigen ihnen neue Wege, Tools und Technologien auf.

2.1 Lose gekoppelte Architekturen

Eine lose gekoppelte Architektur ermöglicht es Teams, das Test- und Deploy-Stadium ohne Abstimmungsaufwände mit anderen Teams und Services durchzuführen. Damit erreicht das Team eine Eigenständigkeit, die das Entwickeln und Ausliefern beschleunigen kann.

2.2 Architektur für eigenständige Teams

Architekten in DevOps-Teams können Teams am besten unterstützen, indem sie gemeinsam Fragestellungen bearbeiten. Der Fokus des Architekten sollte darauf liegen, die Ergebnisse des Teams zu optimieren. Dabei können beispielsweise die Minimierung der Bedarfe für Integrationstests und die Unabhängigkeit des Teams bei Test und Deployment Thema sein. Teams wissen, mit welchen Tools und Technologien sie am besten arbeiten können. Eine mögliche Fragestellung kann sein, wie man noch mehr aus diesen Tools herausholen kann.

3. Produkt- und Prozess-Capabilities

Diese Capabilities aus dem Lean-Product-Management zahlen direkt auf die Software Delivery Performance ein, wobei die Software Delivery Performance das Lean-Product-Management positiv beeinflusst. Das heißt, dass das Produktmanagement den DevOps- Weg unterstützen kann. Teams können gleichzeitig das Produktmanagement selbst betreiben oder mit Daten unterstützen.

3.1 Kundenfeedback sammeln und implementieren

Um die Produktentwicklung positiv zu beeinflussen, haben Teams eine Reihe von Möglichkeiten. Neben der Erhebung anonymisierter Daten zu Nutzerverhalten und dem Messen von erfolgreichen und gescheiterten Vorgängen ist das direkte Feedback von Nutzern eine weitere Größe, die in das Design und die Entwicklung des Produktes einfließen kann.

3.2 Experimente fördern

Basierend auf diesen Daten und der Möglichkeit, Spezifikationen direkt anzupassen, kann die Innovation direkt aus den Teams erfolgen. Die Nähe zum Produkt, den Kunden und den Daten erlaubt es, Experimente zu starten und aus ihnen zu lernen. Damit kann das Team direkt neue Werte am Produkt schaffen, ohne „von oben“ einen Segen zu erhalten.

3.3 Arbeitsabläufe sichtbar machen

Das Verständnis und die Sichtbarkeit, wie neue Arbeitspakete zum Team gelangen, von Business-Seite bis zum Kunden, hilft Teams, fundierte Entscheidungen im Alltag zu treffen. Die Verwendung von Bibliotheken bis hin dazu, wie Systeme geschnitten werden, ändert sich mit dem Kontext, den das Team hat.

3.4 Arbeiten mit kleinen Paketen

Continuous Delivery ermöglicht es, jederzeit neue Features an den Kunden zu bringen. Im Produktmanagement sollte dies ein Gegenstück haben: Ein großes Projekt wird in kleine Features zerlegt, die in schnellen Zyklen ausgerollt und verbessert werden. Das ermöglicht frühes Feedback durch Methoden wie A/B-Testing.

4. Lean Management und Monitoring Capabilities

Nach den klassischen Ansätzen im Management von Software-Entwicklungsteams und der Adaption agiler Methoden steht nun mehr und mehr Lean im Fokus. Diese Capabilities legen den Fokus auf die Produktivität der Teams.

4.1 Changes ohne aufgeblasene Prozesse

Die Forschung durch DevOps-Studien zeigt [3], dass die Freigabe von Changes durch teamfremde Change-Approval-Boards die Software Delivery Performance negativ beeinflusst und nicht für die Stabilität sorgt, die damit verbunden wird. Leichtgewichtige Prozesse, wie Peer-Reviews, wirken sich hingegen positiv auf die Software Delivery Performance aus.

4.2 Fundierte Entscheidungen durch Monitoring

Die Daten, die Anwendungen und Infrastruktur produzieren, können dafür genutzt werden, um technische Maßnahmen zu ergreifen. Das Produktmanagement profitiert von diesen Daten und kann datengestützte Entscheidungen treffen.

4.3 Proaktives Monitoring

Erfolgreiche DevOps-Teams überwachen Systeme mithilfe von Schwellwerten und Warnungen bei Änderungsraten. So können diese Teams verbeugende Maßnahmen für Probleme treffen und laufen ihnen nicht hinterher.

4.4 Work-in-Progress Limits

Ein Work-in-Progress Limit, also das bewusste Limitieren von Paketen, die gleichzeitig abgearbeitet werden, wirkt sich positiv auf den Durchsatz und die Prozesse aus. Außerdem werden Randbedingungen und Beziehungen zwischen Arbeitspaketen transparenter.

4.5 Transparenz bei Qualität und Arbeit für das ganze Team

Tools, die Monitoring, Deploybarkeit und Code-Qualität sowie den aktuellen Stand der Work-in-Progress-Pakete auf einer Website oder einem für das ganze Team sichtbaren Monitor zeigen, geben dem Team mehr Transparenz. Diese ist wichtig, um bei Ereignissen wie Ausfällen oder Problemen bei der Deploybarkeit gegenzusteuern.

5. Kultur-Capabilities

Eine Kultur in Technologie-Organisationen erscheint auf den ersten Blick schwer messbar. Ron Westum fasst die meisten Kulturen mit seinem Paper [4] zusammen: pathological (machtorientiert), bürokratisch (regelorientiert) und generative (leistungsorientiert).

5.1 Produktive Unternehmenskultur schaffen und fördern

Die „generative“-Kultur unterstützt die Software Delivery Performance durch Vertrauen, ein hohes Maß an Kooperation, starken Informationsfluss, geteilte Risiken, Neugier sowie offene und ausgeprägte Kommunikation zwischen Teams [5].

5.2 Lernen

Kontinuierliches Lernen ist kritisch für die stetige Veränderung des modernen Arbeitslebens. Als Arbeitgeber und Arbeitnehmer sollte das nicht als einmalige Investition verstanden werden, sondern als ein dauerhafter, beidseitiger Prozess.

5.3 Zusammenarbeit von Teams fördern

Produktive Unternehmenskulturen reduzieren das Silodenken zwischen Teams und fördern die Zusammenarbeit. Nicht nur bei Themen wie Entwicklung, Operations- und Information-Security, sondern zwischen dem klassischen Business und der Software- Delivery-Organisation.

5.4 Innovative Führungskultur etablieren

Innovative Führungskultur (Transformational Leadership) bedeutet, dass Führungskräfte durch Inspiration und Motivation Menschen zu Bestleistungen herausfordern. Diese Führungskräfte bringen eine Vision in die Organisation, kommunizieren klar, offen und inspirierend, fordern heraus, unterstützen und erkennen persönliche Leistungen an.

5.5 Tools und Ressourcen bereitstellen

Kritisch für die Zufriedenheit im Berufsalltag ist für viele, dass sie ihre Arbeit gut erledigen. Führungskräfte verstehen es, je nach Situation, das bereitzustellen, was benötigt wird. Sei es der Kontext, die Befähigung, etwas zu erledigen, neue Skills oder einfach nur Hard- oder Software.

Fazit: DevOps ist die Leistung einer kompletten Organisation

Erfolgreiche DevOps-Transformationen werden von der kompletten Organisation gelebt. Sie werden durch eine starke Übernahme von Verantwortung in den Teams gekennzeichnet und von offenen Retrospektiven begleitet. Damit wird es der Organisation ermöglicht, an ihrer Transformation zu wachsen. Wenige KPIs ermöglichen transparente Experimente, die Fehlschläge erlauben und Lernen fördern. Also: Gehen wir es richtig an!

Quellen

[1] en.wikipedia.org/wiki/DevOps
[2] Dr. Nicole Forsgren, Jez Humble, Gene Kim (2018): Accelerate: State of DevOps 2018: Strategies for a New Economy, DevOps Research and Assessment LLC
[3] Dr. Nicole Forsgren, Jez Humble, Gene Kim (2018): Accelerate: Building and Scaling High Performing Technology Organizations, IT Revolution Press
[4] Ron Westrum (2014): A typology of organisational cultures
[5] continuousdelivery.com – Culture