DevOps Essentials

Eines Vorweg: DevOps ist kein Framework, kein Standard, der kodifiziert in einem Buch nachzulesen ist. DevOps ist vielmehr ein “Grassroot-Movement”, das sich laufend weiterentwickelt. DevOps wird unterschiedlich interpretiert. Dennoch gibt es so etwas wie einen aktuellen gemeinsamen Nenner, welchen ich im Folgenden versuche zusammenzufassen.

 

DevOps Motivation & Ziele

“Schneller & besser” – so lassen sich die Ziele von DevOps grob zusammenfassen. “Schneller” bezieht sich primär auf die Time to Market, die Fähigkeit, neue Services in kurzer Zeit produktiv zu bringen, d.h. von der Anforderung bis der Benutzer dessen Umsetzung das erste Mal nutzt.  Häufigere Releasezyklen gehören ebenfalls auch in diese Kategorie. “Besser” bezieht sich auf Dinge wie Mean Time to Restore Service, Performance und Verfügbarkeit. Um dies zu erreichen, kämpft DevOps gegen eines der Urprobleme in der IT an, welches sich sehr schön in diesem Bild darstellt:

Um den typischen Zielkonflikt von Stabilität versus Flexibilität zu lösen, bricht DevOps den Graben zwischen Entwicklung und Betrieb auf, indem die Sicht der Value Streams entlang von Produkten oder Services eingenommen wird. Und der Value Stream beginnt natürlich schon im Business, daher müsste es eigentlich BizDevOps heissen, dazu aber später.

 

Die DevOps-Unicorns als Vorbild

Firmen wie Netflix, Etsy, Spotify und Google haben DevOps in den Anfängen geprägt. DevOps entspricht ganz einfach ihrer Kultur, der Art und Weise, wie dort Dinge angegangen werden. Die Basis dafür war zunächst die agile Entwicklung um Produkte herum, d.h. in kleinen Teams, mit end-to-end Verantwortung,  inkrementell und adaptiv. Agil macht aber erst richtig Sinn mit DevOps. Der eine Aspekt dabei ist, nicht jedes Mal 2 Wochen auf eine Infrastrukturumgebung warten zu müssen (Frage: Wie lange dauert dann ihr Sprint?), daher der Druck Richtung Cloud, Infrastructure as a Code und Microservices-Architektur. Ein weitere Aspekt ist die Durchsetzung einer neuen ‘Definition of Done’, d.h. bei jedem Check-In werden alle Tests automatisiert durchgeführt, so dass man jederzeit produktiv gehen könnte (dann spricht man von Continuous Delivery).

 

Die Unicorns hatten es da relativ einfach, da ihr Setup von Anfang an auf DevOps ausgerichtet war, gebaut auf der grünen Wiese. Sie mögen sich jetzt fragen, wie sich das in Ihrem Umfeld realisieren lässt, das vermutlich von Legacy, langen Releasezyklen und vielfältigen Abhängigkeiten geprägt ist. Die Frage ist aber nicht primär, ob DevOps möglich ist, sondern der Punkt ist, dass DevOps notwendig ist, wenn man im Zeitalter der Digital Economy überleben will. Sonst macht es ein anderer. EBeispiele gibt es genügend, wie dies im Enterprise Umfeld umgesetzt wurde. Und auch klar, dass das nicht für alle Bereiche relevant ist, sondern v.a. für digitale Services, über welche man sich als Firma nach aussen differenzieren will.

 

DevOps Werte & Prinzipien

Die Werte von DevOps lassen sich zusammenfassen unter dem Stichwort “CALMS”: Culture, Automation, Lean, Measurement und Sharing.

Ganz zentral bei der Umsetzung sind die “3 Ways”, welche ihre Ursprünge konzeptionell in der Lean Production haben und im Buch “The Phoenix Project” von Gene Kim das erste Mal formuliert wurden:

Zusammengefasst geht es darum, schneller und besser (=Ziele von DevOps) zu werden, indem…. 

• First Way: Increase Flow
  Die IT wird als Value Stream betrachtet mit folgenden darunterliegenden Prinzipien:
  • Understanding the flow of work
  • Increasing flow by understanding and removing constraints
  • Never passing a known defect downstream
  • Never allowing local optimization to cause global Degradation
• Second Way: Feedback
  Kurze und schnelle Feedbacksloops einbauen (Scrum lässt grüssen), mit folgenden Prinzipien:
  • Understand and respond to the needs of all customers – both internal and external
  • Shorten and amplify all feedback loops
  • Create and embed knowledge where needed
• Third Way: Continous Experimentation & Learning
  • Aus Fehlern lernen
  • Experimente als Quelle für Innovation

 

Die 3 Ways implizieren zwischen den Zeilen auch eine neue Organisations- und Führungskultur, ohne die DevOps nicht funktionieren kann: Weg von klassischen Management (Command & Control) hin zu einer selbstorganisierten Teams mit einer starken Verbesserungskultur. Weg vom Manager, hin zum Leader/Coach, welcher die Vision vorgibt und die richtigen Fragen stellt.

 

DevOps Praktiken

Nach all der interessanten Theorie nun zu den DevOps Praktiken, welche die ‘3 Ways’ konkret umsetzen. Vieles davon kommt aus der Lean und Agile Welt, aber auch aus dem IT Service Management. Schlussendlich nützt alles, was einen schneller und besser macht:

• Continuous Integration & Continuous Delivery Praktiken
  Ziel: Software jederzeit in einem ‘Releaseable’ State halten. Schaffung einer “Continous Pipeline”, Testautomatisierung, Cotinous Testing, Tool Chain, Cloud als Enabler, and so on
• Value Stream Mapping
  Eine bewährte Lean Praktik, mit der auch IT Value Streams & Bottlenecks identifiziert und letztere eliminiert werden
• Kanban
  Die Arbeit in Teams nach Lean Prinzipien managen. Oft ein erster Schritt
• Rugged DevOps
  Security Praktiken früh in der Continuous Pipeline einbauen
• DevSecOps
  “Jeder ist verantwortlich für Security”
• ChatOps
  Störungsbehebungszeit drastisch reduzieren durch die Verwendung von Collaboration Tools über alle Support Levels hinweg
• Toyota Improvement KATA
  Eine struktuierte Methode, umd eine Lern- und Verbesserungskultur zu schaffen
• ITIL Praktiken wie Problem Management und Event Management
  Unterstützen v.a. den “Second Way”, d.h. Feedback aus Operations zur Verbesserung der Stabilität

 

Getting started

Wie gehe ich das nun an? Dafür gibt es kein Rezeptbuch. Jedes Unternehmen ist anders. Ein guter Startpunkt ist immer, sich über das eigene “Why DevOps?” im Klaren zu werden. Ohne ein Dringlichkeitsgefühl, z.B. das dein nächster härtester Konkurrent ein Startup mit einer App wird, ist jede Transformation zum scheitern verurteilt. Entscheidend ist auch klare Ziele zu formulieren und messbar zu machen (z.B. Time to Market). Sonst wird man nie feststellen können, wo man steht und ob man besser wird. Und: DevOps ist kein Endzustand, sondern eine Reise die nie aufhört. Das kann mit kleinen Dingen beginnen, wie Value Streams identifizierne und Schritt für Schritt Bottlenecks zu eliminieren. Und zu guter bildet die richtige kulturelle Basis den Kern, denn “Culture eats strategy for breakfast“. Wenn die agile und lean Kultur nicht ins Herzblut der Mitarbeiter eindringt, scheitert eine DevOps Transformation.

Von Alex Lichtenberger