Was ist eigentlich… DevOps?

Was ist eigentlich… DevOps?

Wie können wir neue Ideen schneller umsetzen? Wie reagieren wir flexibler auf Kundenwünsche und Marktveränderungen? Und wie stellen wir trotz kürzerer Innovationszyklen stabile und fehlerfreie Software sicher? Um in dynamischen Märkten wettbewerbsfähig zu bleiben, muss moderne IT hohen Anforderungen gerecht werden. In diesem Zusammenhang ist immer häufiger von „DevOps“ die Rede - eine Philosophie, die auf ein engeres Zusammenrücken der konkurrierenden Bereiche Softwareentwicklung (Development) und IT-Betrieb (Operations) setzt. Aber was genau ist der Grundgedanke der Bewegung, die bei Unternehmen wie Netflix, Walmart, Amazon oder Facebook bereits erfolgreich im Einsatz ist?

Dev & Ops = DevOps: Miteinander statt Gegeneinander

Der belgische IT-Consultant Patrick Debois ahnte im Oktober 2009 nicht, dass die von ihm mitorganisierte Konferenz „DevOps Days“ einen neuen Begriff in der Software-Entwicklung prägen würde. Gemeinsam mit Gleichgesinnten intensivierte Debois die Diskussion um eine effizientere Zusammenarbeit zwischen Entwicklung und Betrieb. Der Durchbruch von DevOps erfolgte 2011, als Analysten von Gartner dem Denkansatz das Zeug zur „Mainstream-Managementtechnik“ attestierten. Nur vier Jahre später kam Gartner in der DevOps-Umfrage 2015 bereits zu dem Ergebnis, dass rund 60 Prozent der Unternehmen die DevOps-Idee einsetzen oder zumindest planen.

Obwohl DevOps in einer technologischen Umgebung geboren wurde, geht es im Kern weniger um ein Framework oder Tool, sondern um eine Unternehmenskultur, die auf Respekt und gegenseitigem Aufgabenverständnis beruht und Silodenken vermeidet.

Der Konflikt zwischen Entwicklung und Betrieb

Aber warum ist die Zusammenarbeit zwischen Entwicklung und Betrieb eigentlich so schwierig? Kurz gesagt ist es das Ziel der Entwickler, die vom Auftraggeber gewünschten Features zeitnah umzusetzen – je mehr Releases, desto besser. Der Betrieb hingegen trägt die Verantwortung für eine stabil laufende Anwendung – jeder Release bedeutet Veränderung und damit ein erhöhtes Risiko. Obwohl beide Abteilungen im Grunde für dasselbe Ziel arbeiten – zufriedene Anwender – ist die Kollaboration zwischen Entwicklung und Betrieb traditionell konfliktbelastet.

Der Einsatz agiler Methoden verschärft die Spaltung häufig noch weiter – nämlich dann, wenn Agilität auf das Entwicklungsteam beschränkt bleibt. Werden Software-Releases zwar in kurzen Iterationen erstellt, dann aber von Wasserfall-Methoden im Betrieb ausgebremst, verpufft der Mehrwert von Scum & Co und neues Konfliktpotenzial entsteht. Der Betrieb wird zum „Flaschenhals“, so dass sich Time-to-Market im schlimmsten Fall nicht nennenswert verringert.

Die DevOps Trinity

Bei DevOps geht es aber nicht nur darum, dem IT-Betrieb agile Methoden aufzuoktroyieren, sondern Softwareentwicklung und Betrieb müssen an einen Tisch gebracht werden.

„And remember it‘s all about putting the fun back into IT“
Patrick Debois


Obwohl es keine verbindliche Definition von DevOps gibt, haben sich in den letzten Jahren drei wesentliche Säulen herauskristallisiert, deren Optimierung zu reibungsloseren Abläufen zwischen den beiden Abteilungen beiträgt:

  • Zusammenarbeit („People & Culture“)
    Kulturelle Basis von DevOps ist das gegenseitige Vertrauen, ein kontinuierlicher Informationsfluss zwischen Entwicklung und Betrieb, das Teilen von Wissen und Lernbereitschaft, gemeinsame Werte statt Schuldzuweisungen.
  • Prozesse („Process & Practices“)
    Die Einführung des DevOps erfordert darüber hinaus definierte (schlanke) Prozesse. Ziel ist es, Verschwendung zu vermeiden und Workflows transparenter zu gestalten.
  • Automation („Tools & Technologies“)
    Alles, was effektiv automatisiert werden kann, sollte auch automatisiert werden. So werden Mitarbeiter von sich wiederholenden Aufgaben befreit, Fehler reduziert und Prozesse optimiert.

Eine ähnliche, aber inhaltlich im wesentlichen vergleichbare DevOps-Definition nach John Willis ist C.A.L.M.S. – ein Konzept, das auf den Komponenten Culture, Automation, Lean, Measurement, Sharing beruht.

Unfriendly Takeover?

Ein häufiges Missverständnis ist die Sorge, dass der Betrieb von der Entwicklung „mit übernommen“ werden soll („NoOps“) oder dass künftig eine Elite an Alleskönnern gesucht wird („Full Stack Developer“). Ja, DevOps-Entwickler sollten über ein Breitenwissen verfügen, um die Bedürfnisse im Betrieb verstehen zu können – und umkehrt. Nichtsdestotrotz bleibt die Spezialisierung der Bereiche erhalten, Teams werden vielmehr crossfunktional besetzt, um alle benötigten Fähigkeiten abzudecken.

„To be a master of anything, you must understand two layers above and two levels below the layer you‘re targeting.“
Chris Johnson
 

Fazit: Agilität zu Ende gedacht

Im Zentrum von DevOps stehen die Menschen und die Art und Weise, wie sie zusammenarbeiten. Agilität soll die Grenzen der Entwicklungsabteilung sprengen und abteilungsübergreifend etabliert werden, um ihr volles Potenzial entfalten. Ohne eine entsprechende Unternehmenskultur wird die Einführung von DevOps deshalb zwangsläufig scheitern.
 

Weitere Infos:

Erklärvideo: DevOps in 7 Minuten
https://www.youtube.com/watch?v=_I94-tJlovg

Buch „DevOps Handbook“
Autoren: Gene Kim, Jez Humble, Patrick Debois, and John Willis
http://itrevolution.com/devops-handbook

Unser neues Büro in München ist eröffnet!
4 Jahre Teamprove: ein neuer Look zum Geburtstag