Suche

Areas, Layer und Maturity Levels: Die Kodifizierung von DevOps-Praktiken

Michael Thomas

© Shutterstock.com/Kidsana Maimeetook

Im Rahmen seiner Mitarbeit an dem DevOps-Buch „The Phoenix Project“ stellte sich für Patrick Debois die Frage nach einem mentalen Modell für DevOps. Sein Artikel „Codifying devops practices“ stellt trotz seines bereits etwas fortgeschritteneren Alters einen lesenswerten Versuch dar, DevOps-Praktiken zu kodifizieren.

Debois unterscheidet zwei Arten von DevOps: DevOps (die Zusammenarbeit und Optimierung der gesamten Organisation, bzw. über die Organisation hinaus) und DevOps „lite“ („nur“ die Zusammenarbeit von Dev und Ops). Dabei geht er, Damon Edwards (Konferenz-Speaker und Mitgründer von DTO Solutions, einem Anbieter von DevOps- und Automatisierungslösungen) folgend, davon aus, dass es bei DevOps in erster Linie nicht um Technologie, sondern um Business-Probleme geht. Die Engpasstheorie geht beispielsweise davon aus, nicht einzelne Silos, sondern das gesamte System zu optimieren. Für Debois ist das gesamte System dabei die komplette Wertschöpfungskette eines Unternehmens. Flaschenhälse, egal an welcher Stelle einer Organisation sie auftreten, können potentiell auch die Bereiche Entwicklung und Betrieb beeinträchtigen.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Folglich, so Debois, müssen auch in Bereichen, die nicht direkt mit Entwicklung und Betrieb zusammenhängen, Verbesserungen vorgenommen werden. Aufgrund der Unvorhersehbarkeit, welche dies sind, kann es für ihn allerdings keine allgemeingültige Lösung des „DevOps-Problems“ geben. Besser sind Debois zufolge Sammlungen von Praktiken, die aus realen Fällen abgeleitet wurden.

Areas, Layer und Maturity Levels

Wie gestaltet sich Debois‘ mentales Modell für DevOps nun im einzelnen? Zunächst identifiziert er vier Schlüsselbereiche, sogenannte „Areas“:

  1. Extend delivery to production
  2. Extend Operation to project
  3. Embed Project (Dev) into Operations
  4. Embed Production (Ops) into Project

In all diesen Areas kommt es zu einem wechselseitigen Austausch von Wissen und Feedback zwischen Dev und Ops. Area 1 und 2 tendieren Debois zufolge dazu, Tool-lastiger zu sein, während Area 3 und 4 seiner Ansicht nach eher mit Menschen und kulturellen Änderungen zusammenhängen. Dev und Ops behalten zwar ihre eigenen, spezifischen internen Prozesse, verzahnen sich jedoch miteinander und dehnen ihre Zuständigkeit auf die Produktion respektive die Entwicklung aus.

In jeder Area kann kann im Hinblick auf eine von drei Schichten interagiert werden: Diese Layer finden sich in den Bereichen Prozesse (sollte man es tun?), Tools (kann man es auch technischer Hinsicht tun?) und Menschen/Kultur (wird man es tun?). Praktiken können Debois zufolge dabei Einfluss auf verschiedene Layer haben. Das (hypothetische) ultimative DevOps-Tool könnte auf alle Areas und Layer angewendet werden; eine DevOps-Toolchain, die miteinander interagierende Tools in jeder Area bietet wäre also allen anderen vorzuziehen. Dabei gibt Debois jedoch zu bedenken, dass Tools in der Regel nicht „von sich aus“ DevOps-Tools sind, sondern erst von ihrem Anwender und ihrem Einsatzzweck dazu gemacht werden.

Das letzte Element von Debois‘ Modell wird von den sog. „Maturity Levels“, also von „Reifegraden“ gebildet. Diese helfen einem dabei, die erreichten Fortschritte im DevOps-Übergangsprozess nachzuverfolgen. Zu diesem Zweck empfiehlt Debois beispielsweise die von Adrian Cockroft vorgeschlagenen CMMI-Level sowie das Continuous Integration Maturity Model, die jeweils fünf Stufen der „Reife“ identifizieren.

Praktiken, Muster und Prinzipien

Eine Praktik kann Debois zufolge theoretisch alles sein: Anekdotisch gestütztes Handeln ebenso wie systematische Ansätze. Ähnliche Praktiken können zu einem Pattern gruppiert werden (ähnlich den Entwurfsmustern in der Softwareentwicklung). Praktiken und Patterns wiederum beruhen auf Prinzipien, die einen bei ihrer Anwendung leiten. Diese Prinzipien können dabei aus den unterschiedlichsten Bereichen, z. B. Lean, der Systemtheorie oder auch der Psychologie, entlehnt werden.

Areas, Layer und Maturity Levels bieten Debois‘ Fazit zufolge ein Framewok, um neue Praktiken (und Erfahrungsberichte) aufzuzeichnen bzw. zu entwickeln. Zudem können sie genutzt werden, um verbesserungswürdige Bereiche innerhalb einer Organisation zu identifizieren.

Aufmacherbild: businesswoman, practices concept von Shutterstock / Urheberrecht: Kidsana Maimeetook

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: