Devops macht IT-Abteilungen leistungsfähiger und ihre Mitarbeiter zufriedener – das besagt eine aktuelle Studie. Welche Zutaten stecken konkret in dem modischen Rezept? Eine Einführung.

Buzzword-Alarm! Der Begriff Devops, in dem Development (Entwicklung) und Operations (IT-Betrieb) verschmelzen, findet sich derzeit fast überall: Es gibt Blogs, Bücher, Artikel, Schulungen und Software zum Thema.

Die neue Art der Zusammenarbeit von Entwicklern und Admins haben unter anderem John Allspaw und Paul Hammond auf der kalifornischen Velocity-Konferenz 2009 bekannt gemacht. Ihre Folien [1] beschreiben, wie die Techies der Foto-Community Flickr zehn oder mehr Deploys am Tag durchführen.

Verändertes Berufsbild

Diese Praxis ist mittlerweile Alltag auch in deutschen Internetfirmen. “Mein Eindruck ist, dass man als Firma mit den alten Arbeitsmodellen nicht mehr wirtschaftlich bestehen kann”, erklärte beispielsweise Schlomo Schapiro, Systemarchitekt bei Immobilienscout24, dem Linux-Magazin [2].

Es gibt immer mehr IT-ler, die sich selbst als Devops beschreiben, ja es gibt sogar Devops-Abteilungen. In der Studie “2014 State of Devops Report” [3] gaben 31 Prozent der über 9000 Befragten an, ihre Stellenbeschreibung sei Devops Engineer. In einer Devops-Abteilung arbeiten laut der Umfrage 16 Prozent.

Der Bericht, bei dem nach 46 Prozent aus den USA immerhin 25 Prozent der Befragten aus Europa stammen, entstand im Auftrag von Puppet Labs, IT Revolution Press und Thoughtworks. Man sollte im Hinterkopf behalten, dass diese Unternehmen Software, Publikationen und Dienstleistungen rund um Devops anbieten, weshalb das Porträt dieser Arbeitsmethode im Zweifel eher positiv ausfallen dürfte.

Jedenfalls konnten die Autoren aus den Selbstauskünften Folgendes ermitteln: Überdurchschnittlich leistungsfähige Abteilungen wenden Devops-Techniken an. Die Leistung der IT-Abteilung bemisst die Studie dabei nach der Häufigkeit von Deployments, der für Änderungen (Changes) benötigten Zeit sowie nach der Mean Time to Recover, also der benötigten Zeit, um nach Ausfällen den Betrieb wieder herzustellen. Diese Korrelation macht neugierig, was die Devops-Anhänger anders machen.

Devops-Prinzipien

Die Devops-Prinzipien sind im Grunde noch die bereits 2009 beschriebenen (siehe Kasten “Devops-Regeln”). Kernpunkt ist die engere Zusammenarbeit von Entwicklern und Admins, üblicherweise in einem gemeinsamen produktspezifischen Team. Es gilt nicht mehr, dass die Entwickler nur für neue Softwarefeatures zuständig sind und die Admins für einen zuverlässigen und effizienten IT-Betrieb (Abbildung 1) – sie arbeiten gemeinsam an allen diesen Zielen.

Abbildung 1: Die Devops-Philosophie schafft die traditionellen Grenzen zwischen Entwicklung und Betrieb ab.

Eine Einführung in Devops in nur sieben Minuten liefert ein Video [4]. Der auch für Meetings geeignete Kurzfilm stammt vom Hoster Rackspace – der ebenfalls Devops-Dienste anbietet. Er erklärt unter anderem, dass Devops auf das Deployment kleiner übersichtlicher Features für Produktivsysteme setzt, wie das die agile Schule schon lange empfiehlt. Sie lassen sich leicht testen und ohne große Eingriffe in die Infrastruktur ausrollen.

Gegen den Reformstau

Diese Politik der kleinen, aber häufigen Schritte verhindert, dass interne Anwender oder Kunden lange auf neue Features warten müssen, sie verkürzt die Produkteinführungszeiten. Gleichzeitig stellt die Vorgehensweise sicher, dass sich die Systemumgebungen von Entwicklung und Betrieb nicht auseinanderentwickeln.

Laut der Devops-Studie 2014 spielen erfolgreiche Abteilungen 30-mal so häufig neuen Code auf Produktivsysteme wie ihre schwächeren Konkurrenten. Damit das glattgeht, sind weitere Maßnahmen erforderlich. Aller Code muss unter Verwaltung eines Versionskontrollsystems stehen. Das erlaubt bei Problemen auch das Rollback der Änderungen. Continuous Delivery, das automatische Bauen der Software aus dem jüngsten Quellcode, verhindert Wartezeiten.

In diesen Prozess binden die Beteiligten zudem Tests ein, die im Rahmen eines Build ebenfalls nach jeder Code-Änderung automatisch ablaufen, um die Qualität sicherzustellen. Continuous-Integration-Software wie Jenkins [5] oder der Dienst Travis CI [6] helfen den Devops-Anhängern dabei.

Außerdem gehört nicht nur der Quelltext der Anwendungen unter Versionskontrolle. Auch die Infrastruktur nimmt immer öfter die Form von Software an. Aller Code, den Admins für den Betrieb schreiben, muss also auch in Git oder Subversion landen. Das verbessert die Mean Time to Recover bei Infrastrukturproblemen, weil die Admins rasch eine ältere Version ausrollen können.

Zum Verteilen der Konfiguration bietet sich die Automatisierung mit Systemen wie Chef [7] oder Puppet [8] an. Monitoring-Software sorgt daneben dafür, dass die Admins frühzeitig von Störungen erfahren und vorbeugend aktiv werden können, bevor größere Ausfälle eintreten.

Metriken

Devops-Praktiker setzen zudem auf Messgrößen, die die Arbeitsprozesse abbilden: Wie lange dauert es, bis ein neues Feature in den Betrieb geht? Wie viele Tickets sind offen und wie schnell arbeitet der Service Desk sie ab? Hält die IT-Abteilung die Service Level Agreements mit den Kunden und die internen Betriebsvereinbarungen ein? Nur anhand solcher Performance-Indikatoren kann ein Unternehmen überhaupt feststellen, ob es von neu eingeführten Methoden profitiert.

Doch allein mit der Korrelation von Devops-Methodik und Leistung in der 2014er Studie ist vermutlich noch kein Entscheider zu überzeugen, den Beweis müssen die Praktiker individuell antreten. Daneben machen manche Abteilungen die Metriken auch öffentlich, etwa auf einem Display im Büro oder der Cafeteria. Ob diese Kennzahlen eher der Motivation oder der Einschüchterung der Mitarbeiter dienen, hängt allerdings vom allgemeinen Betriebsklima ab.

Eine Kulturfrage

Neben den eher handfesten Aspekten der neuen IT-Methodik, die viel mit Technik und Tools zu tun haben, sollte niemand die menschlichen Faktoren vergessen, die auch in der IT die Arbeit prägen. Dazu zählt beispielsweise die Zufriedenheit am Arbeitsplatz. Devops birgt durch die Produktivitätssteigerung die Chance, auch diese zu erhöhen. Bevor das stattfinden kann, sind allerdings einige Voraussetzungen zu erfüllen.

Die nicht technischen Bedingungen für Devops lassen sich als Organisationskultur beschreiben [9]. Dazu gehört es, bei Fehlern und Störungen keine Sündenböcke zu suchen (Abbildung 2). Wenn die Entwickler den Linux-Admins die Schuld in die Schuhe schieben und diese mit dem Finger auf die Netzwerk-Leute zeigen, bringt das den Anwendern wenig. Anschaulich beschreibt das Gene Kim in seiner lehrreichen Geschichte “The Phoenix Project” (siehe den Kasten “Devops-Roman”).

Devops-Roman

Das englischsprachige Buch “The Phoenix Project” [11] liest sich wie ein Roman, vermittelt aber gleichzeitig die Devops-Prinzipien. Geschrieben hat es der Unternehmer Gene Kim zusammen mit einigen Co-Autoren. Kim programmierte als Student das Intrusion-Detection-Tool Tripwire und gründete später die gleichnamige Firma. Seit 2000 beschäftigt er sich mit IT-Organisation, schreibt Bücher darüber und hält Vorträge.

Der Roman erzählt die Geschichte des Angestellten Bill Palmers, der vom kleinen Abteilungsleiter überraschend zum Chef des firmenweiten IT-Betriebs befördert wird. In seiner neuen Rolle hat er jede Menge Schwierigkeiten zu meistern: Schon am ersten Tag geht die Lohnabrechnung schief und das Unternehmen macht Negativ-Schlagzeilen in der Presse. Daneben liegt die neue Softwarerelease mit dem Codenamen “Phoenix” bereits um zwei Jahre hinter dem Zeitplan. Als wäre das alles nicht schon schlimm genug, steht auch noch der Sarbanes-Oxley-Auditor mit einer langen Liste Beanstandungen vor der Tür.

Die Zeit drängt und Bill tut, was er kann. Dabei entdeckt er zunächst die herrschenden Missstände: Die rechte Hand weiß nicht, was die linke tut, das meiste Wissen über die Systeme ist bei einem einzigen Mitarbeiter konzentriert und niemand hält sich an Prozesse oder schreibt Dokumentation.

Dabei sind die beschriebenen Probleme, Personen und Dialoge so treffend aus dem Leben gegriffen, dass jeder IT-ler das Leid des Protagonisten mitempfindet. Die Firma benötigt etwa dringend irgendeine Art von Change-Management-Tool, damit die Änderungen einander nicht auf die Füße treten. Doch Bills Mitarbeiter Wes protestiert: “Es dauert zwanzig Minuten, um die ganzen verdammten Felder auszufüllen, auch wenn es nur um eine einfache Fünf-Minuten-Aufgaben geht!”

Wer verfolgt, wie es Bill ergeht, lernt vieles über die Probleme einer IT-Organisation – und über deren Lösung. Insbesondere als der mysteriöse Dr. Reid auftaucht, der zu einer Art Mentor für ihn wird.

Gene Kim, Kevin Behr, George Spafford:

The Phoenix Project

IT Revolution Press, 2013

350 Seiten

16 Euro (E-Book 8 Euro)

Abbildung 2: Anderen die Schuld an Pannen zuzuschieben ist bei Devops verpönt. Stattdessen gilt es, gemeinsam aus Fehlern zu lernen.

Fehler gehören dazu

Allspaw und Hammond forderten in ihrem Vortrag 2009 eine gesunde Einstellung zu Fehlern: Pannen gebe es auf jeden Fall, aber man könne sie beheben und aus ihnen lernen – etwa indem die Mitarbeiter die Behebung in einer Knowledge Base festhalten oder einen Notfallplan aufstellen. Das Internetunternehmen Netflix treibt diese Devise besonders weit. Es verwendet eine Software namens Chaos Monkey [10], die zufällig ausgewählte Dienste abschaltet – um die Widerstandsfähigkeit der Cloud zu testen und die Arbeitsabläufe für die Fehlerbehebung zu trainieren.

Zu den Werten der Devops-Kultur gehört zudem Respekt: Vorurteile gegenüber Entwicklern, sie seien faul und leichtsinnig, oder Stereotype von Admins als bürokratische Neinsager haben hier keinen Platz. Alle arbeiten an einem gemeinsamen Ziel und tauschen Meinungen und Wissen aus. Als inakzeptabel gilt es beispielsweise, anderen Informationen vorzuenthalten, um eigene Fehler zu vertuschen oder seine eigene Position zu stärken. Solche Machtspiele kosten Zeit und Energie und behindern den Unternehmenserfolg. Stattdessen setzt Devops auf Vertrauen zwischen den Akteuren, etwa wenn Administratoren es Programmierern erlauben, bestimmte Änderungen an Systemen vorzunehmen.

Vorbildlich

Die Einstellungen von Angestellten kann man freilich nicht am grünen Tisch planen. Meist ist ein Entwicklungsprozess mit langsamen Änderungen erforderlich. Die Beraterin Mandi Walls [9] empfiehlt unter anderem, leitende Angestellte und respektierte Fachleute als Vorbilder einzusetzen. Daneben eignet sich ihrer Meinung nach am ehesten ein klar definiertes Pilotprojekt zur Erprobung und Einführung der neuen Vorgehensweise.

Devops für neue Projekte

Ähnlich sieht das Udo Seidel, Manager Linux-Strategie und Server-Automatisierung bei Amadeus, einem IT-Dienstleister für die Reisebranche: “Devops ist ein Paradigmenwechsel, den gewachsene Rechenzentren wie Amadeus nicht so einfach vollziehen können. Das erfordert ein Umdenken in den Köpfen und muss sich auch im Aufbau der Organisation und unserem ganzen Prozesswesen widerspiegeln. Wir beginnen mit den Bereichen, die neue Geschäftszweige umfassen. Dort starten wir etwas mehr auf einer grünen Wiese und haben weniger historischen Ballast.”

Devops einzuführen mag nicht gar so einfach sein, wie manche begeisterten Blogposts und Konferenzbeiträge suggerieren. Die damit erreichbaren Ziele sind aber so attraktiv, dass es sich für viele Unternehmen lohnt, sich zumindest an einem Pilotprojekt zu versuchen. Die Artikel in diesem Schwerpunkt sollen dabei Hilfestellung leisten.