DevOps-Methoden stehen hoch im Kurs. Softwareentwickler stellen ihre Zusammenarbeit und Kommunikation mit anderen IT-Bereichen sowie dem Management komplett auf den Kopf und Automatisierungsprozesse in der Auslieferung sowie dem Updaten von Software auf eine neue Grundlage. DevOps beschleunigen die Entwicklung, das Testen und den Release von Software und macht den gesamten Ablauf zuverlässiger - unverzichtbar in einem stark umkämpften Wettbewerbsumfeld. Es gibt viele Beispiele dafür, wie DevOps Unternehmen aller Branchen zu Erfolgen verholfen haben.
Foto: Razvan Ionut Dragomirescu - www.shutterstock.com
Doch nicht immer läuft alles gut. Auch DevOps-Projekte können scheitern - wie die folgenden Fälle zeigen, die tatsächlich so geschehen sind.
Fehlender Weitblick aufs Projekt
IBM begann sein erstes DevOps-Projekt schon 2003 - einige Jahre, bevor der DevOps-Begriff als solcher überhaupt gebräuchlich war. Für ein neues Produkt führte der Konzern die agile Softwareentwicklung ein - schnelle und flexible Entwicklungszyklen, um die Frequenz neuer Releases im Sinne der Kunden zu erhöhen. Das Vorhaben war unterdurchschnittlich erfolgreich - freundlich ausgedrückt. Die Entwicklung war schnell, die operative Einbindung des Ganzen ins restliche Geschäft hingegen zog nicht mit - die Kunden erhielten ihre fertigen Produkte nicht schneller als vorher.
IBM entschied daraufhin, die Code-Entwicklung zu automatisieren - der gesamte Entwicklungszyklus wurde aber auch dadurch nicht schneller. Also nahm man eine "Wertschöpfungskettenanalyse" vor und stellte fest, dass der Hemmschuh nicht auf Seiten der Agilität oder Automatisierung zu finden war, sondern dass die übergreifende Projektentwicklung und -organisation nicht stimmte. Man konnte die Entwicklungszyklen noch so sehr verkürzen - auf die Dauer bis zur Fertigstellung des Projekts auswirken würde sich das nicht.
Mustafa Kapadia von IBM Global Business Services gibt zu, dass damals der Weitblick aufs Gesamtprojekt gefehlt habe: "Wir hätten erst einmal ein paar Basisfragen beantworten und die Probleme identifizieren müssen, die wir lösen wollten, bevor wir anfingen. Da haben wir versagt." Man habe sich auf "künstliche Probleme" gestürzt, die herstellerseitig kreiert worden, aber gar nicht wirklich existent gewesen seien - anstatt sich auf die wirklichen Fragen zu konzentrieren. Erst als die Projektmanager ihre Prozesse wirklich verstanden hatten und wussten, wo die Hindernisse lagen, waren sie in der Lage, von den DevOps-Methoden zu profitieren.
Zu viele Möglichkeiten - zu schlechte Ausbildung
Im Jahr 2006 rief SlideShare, die mittlerweile zu LinkedIn und damit zu Microsoft gehörende Plattform für den Austausch von Präsentationsunterlagen, ein DevOps-Modell ins Leben, um Prozesse zu beschleunigen und vor dem Wettbewerb zu bleiben. "Das Entwicklerteam saß zu einem Teil in San Francisco und zu einem anderen Teil in Neu Dehli - die Infrastruktur war entsprechend kompliziert", erklärt Ex-Mitarbeiter Sylvain Kalache, heute tätig an der von ihm mitgegründeten Holberton School für Softwareentwickler in San Francisco.
Das Ziel von DevOps ist, die größtmögliche Effizienz innerhalb des Entwicklerteams zu erreichen und das technische Wissen so weit zu tragen wie möglich, sodass die Auswirkungen beispielsweise auch bei Urlaub oder Kündigung gering ausfallen. "In einer DevOps-Umgebung zu arbeiten, bringt jeden Mitarbeiter ans Arbeiten und dazu, verschiedene Teil zum fertigen Produkt beizutragen", sagt Kalache. "Ein Team zu haben, das sich blind versteht, ist sehr wichtig - und das lässt sich nur erreichen, wenn Menschen miteinander zu tun haben und einander helfen."
Eine der wichtigsten Ideen hinter DevOps sei ein umfassenderes Verständnis von Zuständigkeiten - und "deshalb müssen Sie Teile der Infrastruktur zugänglich machen, auf die Entwickler in der Regel keinen Zugriff haben", rät Kalache. Er erzählt von einem Vorfall aus seiner SlideShare-Zeit: Dort hätten die Programmierer auch Zugriff auf Produktivserver und Produktionsdatenbanken gehabt.
Ein Entwickler, der an einem Datenbank-Projekt arbeitete, testete nun ein neues Tool aus, um eine MySQL-Datenbank über eine grafische Oberfläche zu verwalten. "Er wollte die Spalten der Datenbank so umstellen, dass er mit den Daten mehr anfangen konnte", erzählt Kalache. "Was er nicht wusste, war, dass er die Anordnung auch im Produktivsystem änderte - was wiederum sofort zur Folge hatte, dass SlideShare.net nicht mehr erreichbar war." Der Entwickler merkte jedoch gar nicht, dass er tatsächlich Aktionen ausführte - so dauerte es geschlagene 15 Minuten gemeinschaftlicher Anstrengung, bis er als Fehlerquelle identifiziert werden konnte.
Zum Video: Die größten DevOps-Katastrophen
"Zwei Dinge konnten wir aus dieser Geschichte mitnehmen", erklärt Kalache. "Erstens: Auch wenn DevOps überall möglichst sofort Einfluss auf den Produkt- und Service-Zyklus nehmen sollen, müssen sich Unternehmen gut überlegen, wem sie welchen Zugriff gewähren und ob das etwas bringt. Im Fall des beschriebenen Datenbank-Ausfalls war die Gewährung von Zugriff auf die Produktionsdatenbanken zum einen nicht hilfreich und zum anderen auch noch gefährlich. Der Entwickler hätte sein Ziel auch mit einer Offline-Datenbankkopie erreichen können, ohne das gesamte Unternehmen zu gefährden."
Zweitens: Bilden Sie Ihre Entwickler besser für Infrastrukturarbeiten aus - schließlich sind viele von ihnen noch nie mit Produktivsystemen in Berührung gekommen. Kalache: "DevOps basieren gewissermaßen auf einer Arbeitsweise, die sich mehr an menschlicher Interaktion orientiert. Sie können aber nicht von jedem erwarten, dass er die versteckten Regeln kennt. Darum ist es so wichtig, die Mitarbeiter dort abzuholen, wo sie stehen."
DevOps nur halbherzig umgesetzt
Manchmal liegt der Fehler in der Art und Weise, wie DevOps in einem bestimmten Projekt zur Anwendung kommen. So arbeitet ein Fahrzeug-Leasingunternehmen mit diversen Partnerfirmen in der gesamten USA zusammen. Alle Kundendaten und Leasingwünsche aller Partner werden in einer eigens entwickelten Softwarelösung verarbeitet. Ein großer Teil der Daten muss aber durch Drittanbieterdienste verifiziert werden, weil es sich hier um Finanztransaktionen handelt und die hier involvierten Dienstleister wiederum eigene Systeme betreiben (müssen).
"Das DevOps-Setup für diese Software baut auf Servermetriken auf - wie Antwortzeiten und Systemausfälle, Entwicklungsstatistiken und Automatisierung", erklärt Nathaniel Rowe, der das genannte Leasingunternhmen in Softwarefragen berät. "Weil die Systemüberwachung fehlerhaft war, fiel vor einigen Wochen das gesamte System aus", erzählt er. "Ein notwendiger Drittanbieterservice, der Leasingnehmer validiert, hatte einen Netzausfall, was zum Crash der gesamten Infrastruktur führte."
Das sollte de facto kein Problem darstellen. Da die Software - im Übrigen günstig ausgelagert - aber so konstruiert war, dass alle externen Prozesse auf den genannten Service zugreifen mussten, ging nichts mehr. "In einem Unternehmen wie diesem brechen dadurch die Umsätze sofort ein", resümiert Rowe.
Wo lag also das Problem? DerDevOps-Prozess war einfach nicht von vorne bis hinten komplett umgesetzt - man verließ sich viel zu sehr auf die genannten Servermetriken, anstatt in aktive Überwachung externe Dienste zu investieren, die für einen Betrieb unabkömmlich waren. "Das war förmlich ein schwarzes Loch bei uns - wir haben es aber nicht entdeckt, weil 99 Prozent der Probleme sonst immer auf fehlerhaften Code zurückzuführen sind und nicht auf weiter außenliegende Störungen", erklärt Rowe.
Als der Ausfall bekannt wurde, machte sich das Entwicklerteam daran, den betroffenen Validierungsdienst zu isolieren und Prozesse einzubauen, um ihn zu umgehen - dadurch ließen sich wenigstens die Kundendaten retten, die die Partnerunternehmen ins System gegeben haben.
"Wir konnten die Ursache dadurch identifizieren, dass wir den Service-Anbieter kontaktierten und von ihm mitgeteilt bekamen, was genau geschehen war", sagt Rowe. "Um sich künftig vor derartigen Incidents zu schützen, wird künftig jedes Mal wenn ein analoger Netzfehler auftritt, eine Aktion ausgelöst, die den Anmeldevorgang umleitet und alle Partnerunternehmen informiert, dass der Service offline ist." Wenn man der ganzen Geschichte etwas Positives abgewinnen möchte, dann die Tatsache, dass den Entwicklern nun eigens Zeit und Geld zur Verfügung gestellt wurde, um auch die übrigen Systeme auf Schwachstellen zu überprüfen.
Menschen einfach vergessen
Als Brian Dawson, heute DevOps-Evangelist beiCloudBees, vor einigen Jahren im Auftrag einer US-Regierungsbehörde als Prozessberater für einen Hersteller tätig war, machte er erste Erfahrungen mit DevOps. Und zwar keine guten. Die Behörde startete ein wichtiges Web-Anwendungsprojekt. "Als Hersteller, der für das Lifecycle Management der Anwendung zuständig war, kümmerten wir uns um die Werkzeuge und Arbeitsabläufe für alle Projektschritte - Planung, Code-Entwicklung und Release - in einer kollaborativen und Open-Source-ähnlichen Weise", so Dawson.
Konfiguration und Einsatz der unterstützenden DevOps-Tools waren erfolgreich - "leider lassen sich DevOps nicht ausschließlich mit Tools umsetzen", warnt er. "Es braucht auch ein Augenmerk auf die beteiligten Menschen, Kulturen und Arbeitsabläufe."
Mehrere Teams hatten den Projektzeitplan strikt einzuhalten, der aber sehr eng gestrickt war - was die Projektleitung dazu veranlasste, sich auf die Tools-Plattform zu konzentrieren. Dawson: "Wir waren in der Lage, eine Plattform mit robusten agilen Planungswerkzeugen, einem modernen Software Configuration Management und dem webbasierten Software-System Jenkins für die Integration der entwickelten Tools zu bauen."
Bei all den schönen Tools ignorierte man jedoch die Menschen, die die Plattform später dann nutzen sollten. "Obowohl wir also eine DevOps-Plattform hatten, wurde sie lediglich als Unterstützung der alten eingefahrenen Arbeitsmethoden verwendet - die Entwickler scherten sich nicht um agile Methoden, die automatisierte Qualitätsprüfung wurde nie vollständig integriert, kaputte Versionen regten niemanden auf und Produktions-Workloads in produktionsähnlichen Umgebungen wurden nie ausgetestet."
Das führte dazu, dass es sofort zu sehr kritischen Fehlern kam, als die Web-Anwendung auf den Clients ausgespielt wurde - sie war schließlich niemals von "echten" Nutzern ausgetestet worden. Die Regierungsbehörde benötigte viele zusätzliche Wochen Entwicklungszeit, um die Website zum Laufen zu bekommen - erschwerend hinzu kamen in dieser Zeit die langsamen Antwortzeiten des Services.
Die technischen Schwierigkeiten waren so nach ein paar Monaten behoben - das Grundproblem konnte nach Dawsons Auskunft aber erst sehr viel später gelöst werden: Es mussten zuerst klare Project Owner benannt werden, um alle DevOps-Facetten auch im menschlichen und kulturellen Bereich abdecken zu können. Erst danach war die Behörde "vollständig bereit für DevOps."
Dieser Beitrag erschien im englischen Original bei unserer US-Schwesterpublikation InfoWorld.