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.

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.

"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-ProzessDevOps-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. Alles zu DevOps auf CIO.de

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.

Zur Startseite