SCHNELLER UND AGILER MIT DEVOPS? TEIL 2 – VORAUSSETZUNGEN FÜR DEN ERFOLG

Im zweiten Teil seines Blogbeitrags geht Florian Hieber auf die Voraussetzungen ein, die für eine erfolgreiche Umsetzung des DevOps Modells notwendig sind. Er beschreibt die Vorteile dieser agilen Softwareentwicklungsmethode und die Herausforderungen, die in der Praxis zu bewältigen sind.

Wichtige Voraussetzungen für die DevOps

Für die erfolgreiche Einführung bzw. Umsetzung von DevOps werden folgende Maßnahmen empfohlen:

• Erstellung von Business Cases zum Belegen der Notwendigkeit von DevOps (Link)
• Erfolgreiche Business Cases zur Steigerung der Akzeptanz durch Anwender und Management (Link)
• Aufbau einer ganzheitlichen Kultur der Zusammenarbeit,
• Umsetzung von Maßnahmen zur Nutzung von Automatisierung,
• Gemeinsame Metriken zur Messung des Erfolgs für Dev- und Ops-Teams oder
• Harmonisierung mit (bestehenden) IT-Standards oder -Frameworks wie ITIL.

DevOps funktioniert also dann, wenn Administratoren und Entwickler von Anfang an zusammenarbeiten. Wenn man im Unternehmen durch alle Ebenen hindurch eine neue Kultur für die Entwicklung erschaffen hat und wenn alle Vorgehensmodelle im Unternehmen mit DevOps harmonisieren. In der Praxis gestaltet sich dies erfahrungsgemäß eher schwierig, da die Zeit der Administratoren genauso knapp ist, wie die der Entwickler und beide Gruppen Mehraufwand einplanen müssen. Hier ist es hilfreich, die oft räumliche Trennung der Teammitglieder zu unterbrechen, denn üblicherweise sind die Entwicklungszyklen bis zur Produktivschaltung deutlich kürzer als bei der agilen Entwicklung. In einigen mir bekannten Fällen sind es mehrere Zyklen am Tag. Ein Administrator hat in diesem Fall nur noch wenig Zeit für die anderen Systeme, die er betreut.

Wie schon erwähnt sind als Voraussetzung zwingend Business Cases notwendig, die messbar gestaltet sein müssen. Für den Erfolg eines Business Cases ist es wichtig, die Parameter für den Erfolg vorher zu setzen. Diese Aufgabe ist recht umfangreich und findet leider in der Praxis nur selten Beachtung. Ohne einen Business Case kommt es zu „Bauchentscheidungen“, die meist wieder rückgängig gemacht werden müssen.

Daneben muss eine neue Kultur der Zusammenarbeit etabliert werden. Dies ist wohl der größte und wichtigste Schritt für die erfolgreiche Einführung von DevOps. Entwicklung und Betrieb müssen nicht nur an einen Tisch gebracht, sondern zu einer einheitlichen Marschrichtung motiviert werden. Das ist bei den verschiedenen Berufsgruppen und den damit einhergehenden unterschiedlichen Mentalitäten oft ein langer Weg. Die Harmonisierung der zu überwachenden Parameter einer Anwendung ist demgegenüber eher schnell gemacht. Man kann sich in einem ersten Schritt zum Beispiel auf die Summe aller Parameter einigen und im Laufe der Zeit die als unnötig identifizierten Parameter wieder aus der Überwachung entfernen.

Die Vorteile von DevOps

Ein Vorteil liegt klar auf der Hand: die schnelle Reaktionszeit, die sich bis auf den Benutzer auswirkt. Fehler und Probleme können binnen kürzester Zeit behoben werden. Durch die Einbindung der Administratoren in die Entwicklung wird der langwierige und teure Prozess der Betriebsübergabe beschleunigt. Außerdem werden die Administratoren das Produkt schnell als „ihr“ Produkt annehmen, da sie von Beginn an daran mitgewirkt haben. Entwicklung und Betrieb arbeiten daher miteinander und nicht gegeneinander.

Durch die Einbindung der Administratoren erhält der Entwickler neue Perspektiven auf das Produkt. So wird der Administrator den Aspekt Sicherheit deutlich stärker in den Fokus der Entwicklung stellen, als Entwickler dies tun würden. Auch wird das Thema Logging und Monitoring sicher mehr Beachtung finden und auch die zu überwachenden Parameter eventuell andere sein, als ohne die Mitarbeit von Administratoren am Produkt.

Die Herausforderungen

IT-Administratoren sind Fachkräfte, die Systeme warten und in Betrieb halten. Neuerungen bedeuten für sie immer eine Gefahr, dass es zu Problemen mit alten Betriebszuständen kommen kann. Auch kann die Sicherheit der Systeme gefährdet werden. Dementsprechend sind Administratoren eher darauf bedacht, keine Neuerungen einzuführen oder neue Produkte in die laufenden Systeme einzubinden. Einen Administrator in eine neue Entwicklung zu integrieren, ist damit schwerer als einen Entwickler, der vom Charakter her eher Neuem aufgeschlossen gegenübersteht. Dazu kommt noch, dass DevOps als agiles Team sich selbst motivieren soll. Hier kann es deutlich größere negative Auswirkungen haben, wenn eine Person im Grunde gegen die Neuerung arbeitet und den Fortschritt durch ständiges Hinterfragen torpediert. Und diese Gefahr ist gegeben.

Ich denke, die Qualität der Entwicklung wird sich nicht, wie im V-Modell auf allen Ebenen mit Tests durchziehen lassen können. Bei DevOps wird man mit Unit Tests und mit User Acceptance Tests (UAT) arbeiten können. Integrations- und Systemtests sind bei so kurzen Entwicklungszyklen eher nicht möglich und in der Praxis wurde mir dies auch bestätigt. Der UAT wird damit auch direkt am Benutzer durchgeführt, was unter Umständen für Frustration sorgen kann.

Die Dokumentation ist in vielen deutlich längeren Entwicklungszyklen eher problematisch. Ich kann mir nicht vorstellen, dass bei DevOps im Sinne des Change-Managements halbwegs nachvollziehbar ist, wann-wie-welcher Fehler behoben wurde.

Mein persönliches Fazit

DevOps ist ein sehr interessantes Modell, das in der Praxis allerdings nur dann erfolgreich ist, wenn einige Grundregeln beachtet werden. Ein schulmäßig aufgesetztes DevOps Team konnte ich bisher in meiner beruflichen Praxis noch nicht begleiten. In meinen Projekten wurde - besonders in der letzten Zeit - häufig versucht, die Betriebsseite zu einem sehr frühen Zeitpunkt mit in das klassisch geführte Projekt zu nehmen. Das gelang mal gut, mal weniger gut.

In jedem Fall war ein deutlich erhöhter Aufwand damit verbunden, ein funktionierendes Team aus IT-Mitarbeiterinnen und Mitarbeitern mit sehr unterschiedlichen Einstellungen und Erfahrungshorizonten zu bilden. Es hat meist deutlich länger gedauert, bis Fortschritte zu erkennen waren. Außerdem gab es häufiger Reibereien innerhalb des Teams, die schnell zu eskalieren drohten. Hier sind teambildende Maßnahmen und Softskills gefragt. Sobald die Zusammenarbeit funktionierte, war jedoch ein sehr gutes Ergebnis erzielbar, das am Ende die Kosten im Projekt senken konnte und Auslieferungszeiten deutlich verkürzt hat.