DevOps - Never work alone!

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

"A fool with a tool ist still a fool"

So wichtig wie die Werkzeuge und die Haltung aus Praktiken wie z.B. Continuous Delivery sind, so gibt es damit allein doch oft hohe Hürden und große Schwierigkeiten, einen gut funktionierenden Deliveryprozess zu etablieren. Beim Flow von der Idee bis zum Kunden werden viele Skills aus diversen Disziplinen benötigt, die in vielen klassischen Organisationen in unterschiedlichen Abteilungen organsiert sind. Das führt nicht selten zu langwierigen und dokumentenlastigen Übergaben und Abstimmungen, Kompetenzgerangel und gegenseitigen Schuldzuweisungen zwischen Abteilungen wie Product Management, Entwicklung, QA & Test, Operations und Help Desk.

DevOps überträgt und kombiniert Ideen, Prinzipien und Praktiken unter anderem aus den Bereichen Lean Production, Agile, Agile Infrastruktur und Continuous Delivery.

In dem Buch The Phoenix Project werden die Drei Wege als die zugrundeliegenden Prinzipien von DevOps formuliert:

1. Der erste Weg ist die Optimierung des Flows von Arbeitsergebnissen von der Entwicklung bis zum Betrieb bzw. dem Kunden, d.h. die Verringerung der Zeit, die eine Änderung benötigt, bis sie für den eigentlichen Benutzer nützlich und wertschöpfend ist. Dabei sind insbesondere Techniken wie z.B. Value Stream Mapping, das Sichtbarmachen von Arbeit und Single Piece Flow hilfreich.
2. Der zweite Weg ist die Optimierung von Feeback von rechts nach links, so dass Fehler, die spät im Auslieferungsprozess gefunden werden, in Zukunft schon in der vorherigen Stage vermieden bzw. gefunden werden, indem vorher fehlendes Wissen oder fehlende Informationen besser kommuniziert werden. Das Shift Left Paradigma bedeutet, dass wenn spät im Delivery Prozess ein Fehler auftritt, z.B. bei der Installation oder im Akzeptanztest, dieser Fehler in Zukunft so früh wie möglich - also links im Prozess - erkannt und vermieden werden soll, am besten durch den Compiler oder schnelle Unittests.
3. Der dritte Weg ist das Etablieren einer Kultur, in der gemeinsames Lernen und kontinuierliche Verbesserung einzelner und der ganzen Organisation möglich ist. Dazu gehört das regelmäßige und geplante Lernen und Lehren ebenso wie die selbstverständliche Reflexion über die Organisation und ganz wesentlich der konstruktive Umgang mit Fehlern, Abweichungen oder Incidents, um diese zwar nicht wünschenswerten aber unvermeidlichen Ereignisse zu verwenden, die Organisation jedes Mal etwas besser und stärker zu machen.

DevOps steht für die Umstellung der Organisation, so dass nicht mehr verschiedene Abteilungen mit unterschiedlichen Zielen, die durch stille Post oder Konkurrenz verbunden sind, sondern ein einziges, querschnittlich besetztes Team für den kompletten Prozess von der Codierung der Anwendung bis deren Betrieb und Montoring verantwortlich ist.

Diese Organisationsform erlaubt es dem Team, auch wirklich die Verantwortung für alle Belange des Produktes zu übernehmen. Das ganze Team bekommt direkt und unmittelbar Feedback zum gesamten Wertschöpfungsprozess, d.h. auch Programmierer lernen etwas über die Probleme und Schwierigkeiten des Betriebs von Software und Betriebsexperten lernen den Umgang mit Methoden wie Test Driven Development und Everything as code.

Das bedeutet nicht, dass auch jedes Teammitglied alle für das Produkt benötigten Skills mitbringen muss - das wird eher nicht geschehen. Ebenso können und sollen sich Verantwortliche aus den Bereichen Architektur, Testen und Betrieb der verschiedenen Produkte sich austauschen, um in ihren jeweiligen Bereich Know-how und Lösungen zu verbreiten und zu diskutieren.

Unter der Annahme, dass die Produkte die primäre Wertschöpfung erzielen und nicht die Disziplinen wie z.B. Testen, geht es bei DevOps um eine Ausrichtung der Organisation an eben dieser Wertschöpfung.

Die Optimierung der Prozesse und Produkte findet nicht mehr lokal, z.B. in der Softwareentwicklungsabteilung - aber ohne Berücksichtigung des Betriebs, sondern global statt. Die DevOps-Kultur ermöglicht es allen,  sicher und bewusst Risiken einzugehen, um Marktchancen zu nutzen und aus Erfolg wie aus Misserfolg gemeinsam zu lernen.

State of DevOps Report: DevOps zahlt sich aus!

Dass DevOps und die damit verbundenen Praktiken nicht ein Steckenpferd ambitionierter Techniker oder Aushängeschild einiger meist sehr großer Internet-Vorzeigeunternehmen sind, zeigt der seit einigen Jahren herausgegebene State of Dev Ops Report. Beim Vergleich von High Performance und Low Performance Unternehmen zeigt dieser Report seit Jahren, dass die High Performer über 40 Mal so oft neue Softwareversionen installieren, eine nur ein Zehntel bis ein Fünftel so hohe Fehlerrate bei Änderungen aufwiesen und Fehler fast 100 Mal (2018 : 2604 Mal!) schneller als die Low Performer korrigieren konnten. Außerdem ist die Arbeitszufriedenheit und die Identifikation mit dem Unternehmen in DevOps-Organisationen deutlich höher als in anderen Unternehmen. Die Autoren von The DevOps Handbook fanden zudem heraus, dass High Performer ein deutlich stärkeres Wachstum des Aktienkurses verzeichnen konnten als vergleichbare Low Performer. DevOps ist deshalb eine Sammlung von Haltungen und Praktiken, die, wie es im Untertitel des DevOps Romans The Phoenix Project heißt: "Helping Your Business Win".

Wenn Sie mehr über DevOps wissen wollen, was das ist, wie das geht und ob das etwas für Ihr Unternehmen ist, was jetzt auf den Visitenkarten stehen soll, ob Sie ein DevOps Tool brauchen und wenn ja welches ... dann kommen Sie zu open-oose, in unser DevOps Seminar oder kontaktieren Sie mich direkt!