DevOps Simulation – Learning by Doing

Es gibt viele Wege, den Mehrwert von DevOps für die eigene Organisation zu erkennen. Eine davon ist die DevOps Simulation. Im folgenden ein Erfahrungsbericht aus einigen bereits durchgeführten DevOps Simulationen.

 

Die Frage vorweg: Wieso DevOps und wieso eine Simulation?

«Schneller – Besser». So lassen sich die Ziele von DevOps grob zusammenfassen. Im Zeitalter der Digitalisierung bietet insbesondere Schnelligkeit – die Fähigkeit mit neuen digitalen Ideen schnell auf den Markt zu gehen oder diese am Markt zu testen – einen Wettbewerbsvorteil. DevOps Ansätze wie Continuous Integration und Continuous Delivery helfen, den Fluss massiv zu beschleunigen und gleichzeitig die Qualität zu erhöhen. Die Cloud und Automatisierungstechnologien spielen dabei als Enabler eine zentrale Rolle. Vieles in DevOps ist nicht wirklich neu. Neu ist aber die explizite Zielsetzung dahinter und deren konsequente Messung (schneller-besser). Neu ist auch das Zusammenführen verschiedenster Ansätze aus Lean, Agile & ITSM zur Erreichung dieser Ziele und die Notwendigkeit einer neuen Form der Zusammenarbeit. Es gilt den klassischen Graben zwischen IT Entwicklern und Betrieblern zu überwinden, eine end-to-end Sicht einzunehmen, gemeinsame Anreize zu schaffen (statt Veränderung versus Stabilität) und auszumisten (Lean IT). DevOps ist tief verwurzelt in der Welt von Lean und Agile und insbesondere für die Ops-Seite bedeutet die Adaption des agilen Mindsets einen kultureller Wandel.  Simulationen sind ein ausgezeichnetes Hilfsmittel, Konzepte anhand von Real-Live Szenarien und Rollenspielen verständlich zu machen und die Akzeptanz zu fördern. Und manchmal ist es halt wie Fahrradfahren – man kann gewisse Dinge nur erlernen, wenn man sie ausprobiert.

 

Die DevOps Simulation – das Setup

Wir haben die Simulation mit 15 Personen durchgeführt und 3 Runden gespielt. Jede Runde schloss mit einer Diskussion von  Verbesserungsmassnahmen, welche dann für die nächste Runde implementiert wurden. Die Mannschaft wurde in 5 Gruppen aufgesplittet, nach klassischer Rollenverteilung:

 

Die Simulation spielt im Rahmen eines Unternehmens in der Lebensmittel-Branche, welche ihre Produkte klassisch (Instore) und online vertreibt. Diverse IT Services unterstützen das Business und es besteht auch immer wieder Bedarf nach neuen IT Services und Anpassung von bestehenden IT Services. Die Simulations-Teilnehmer unterstützen dabei und wie in der Realität gibt es auch immer wieder Incidents. Ein real-time Dashboard zeigt jederzeit auf, was die Konsequenzen des Handelns jedes einzelnen auf die IT und das Business sind ($$$):

 

Runde 1: Chaos und erste Verbesserungsmassnahmen

Die erste Runde bot ein beträchtliches Frustrationspotential. Ein typisches Szenario bestand in der Entwicklung und Inbetriebnahme neuer Services. Zunächst hat jedes Team vor sich hingewerkelt, zwar mit klar definierten Inputs/Outputs und schön entlang des Lifecycles, (d.h. Anforderung, Entwicklung, Deployment und Betrieb) aber das Ganze dauerte einfach zu Lange. Von den 20 Services konnten wir kurz vor Rundenende mit grossem Aufwand grade mal mit 2 Services produktiv gehen und die Stabilität liess dann auch zu wünschen übrig. In der Realität hätte uns das Business vermutlich zum Teufel geschickt und die Konkurrenz uns abgehängt. Aber zum Glück war es nur eine Simulation.

 

 

Nach einem Review dieser Resultate und anschliessender Diskussionsrunde haben wir uns die Frage gestellt, wie wir schneller und besser werden können. Hier kamen von den Teilnehmern einige sehr gute Ideen, ganz im Sinne von DevOps:

• Kolokation der Entwickler und Tester (Bessere Kollaboration & Parallelisierung)
• Kolokation der beiden Entwicklerteams, die zwar an den gleichen Services arbeiten, aber geographisch voneinander entfernt waren
• Automatisierung des Software Release-Prozesses
• Einführung von KANBAN Boards, um Transparenz über den aktuellen Stand zu schaffen und die Zusammenarbeit zu verbessern
• Einführung von Application Component Libraries (Wiederverwendung statt jedes Mal das Rad neu erfinden)
• Besser Priorisierung von Business-Anfragen (nach Business Value)
• Besserer Einbezug des Service Desks (Knowledge Base)

 

Runde 2: Verbesserung

Für Runde zwei ging es nun darum, die aus Runde 1 beschlossenen Verbesserungmassnahmen zu implementieren und zu leben. Die Wirkung liess nicht auf sich warten, was die Resultate nach Rundenende deutlich zeigten:

 

 

Wie die anschliessende Diskussion zeigte, hatten wir aber weiterhin verschiedene Ineffizienzen und Brüchen zu kämpfen. So war beispielsweise das Testing ein echter Bottleneck. Wir haben daraus wiederum einige gute Verbesserungsmassnahmen abgeleitet:

• Virtualisierung der Test Umgebung
• Aufbau internal & external Analytics 
  Nutzung von ‘Idle time’, freigewordene Ressourcen im Operations Bereich kümmern sich um Stabilisierungsmassnahmen
• Das Produkt, nicht das Projekt in den Vordergrund stellen
• Continuos Dev/Integration: Einbau von Feedback Loops
• Verbesserung des KANBAN Tools
• Einführung Test- & Behavior Driven Development

 

Runde 3: Optimierung

Die letzte Spielrunde war für alle eine echte Freude, es hat richtiggehend ‘geflutscht’. Repetitive Prozesse waren weitgehend automatisiert, Teams haben übergreifender zusammengearbeiten, es entstand eine echte ‘One Team Culture’. Dies hat sich wiederum in den Resultaten gezeigt:

 

 

Das abschliessende Feedback der Teilnehmer war durchwegs positiv:

• Die Teilnehmer fanden es bereichernd, während der Simulation auch mal in eine Rolle zu schlüpfen, welche sie bis anhin noch nicht so gut kannte
• Die richtige Kultur ist für den Erfolg match-entscheidend, die Simulation zeigt dies gut auf
  Erst wenn von jedem eine End-to-end Sicht eingenommen wird, können echte Verbesserungen gemacht werden

Von Alex Lichtenberger