Strategien


Agile Projekte, die scheiterten

Die größten DevOps-Katastrophen



Simon Hülsbömer betreut als Senior Research Manager Studienprojekte in der Marktforschung von CIO, CSO und COMPUTERWOCHE. Zuvor entwickelte er Executive-Weiterbildungen und war rund zehn Jahre lang als (leitender) Redakteur tätig. Hier zeichnete er u.a. für die Themen IT-Sicherheit und Datenschutz verantwortlich.
Bob Violino arbeitet als freier IT-Journalist für InfoWorld und Network World in den USA.
Auch Sie können von DevOps profitieren. Aber nur, wenn Sie nicht die gleichen Fehler machen wie diese Unternehmen.

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.

DevOps-Methoden können im Unternehmen einschlagen wie eine Bombe - andererseits aber auch für eine große Katastrophe sorgen, wenn sie nicht richtig durchdacht wurden.
DevOps-Methoden können im Unternehmen einschlagen wie eine Bombe - andererseits aber auch für eine große Katastrophe sorgen, wenn sie nicht richtig durchdacht wurden.
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.

Zur Startseite