Close

Der Weg zu einem besseren Vorfallmanagement beginnt hier

Wird das Prinzip "you build it, you run it" (wer die Software entwickelt, ist auch dafür verantwortlich) dem Hype gerecht?

Die Einführung dieses Prinzips liegt nun 13 Jahre zurück. Hat es sich bewährt?

Vor dreizehn Jahren hat sich die Forderung nach einer Kombination der Bereitstellung und des Betriebs von Software in ein Interview eingeschlichen und infolgedessen IT-Prozesse auf der ganzen Welt auf den Kopf gestellt. Heute befolgen mehr Unternehmen als je zuvor den kollaborativen Ansatz von DevOps und die in der Regel damit einhergehende Philosophie "you build it, you run it". Doch ist dieses Konzept nach über einem Jahrzehnt des Wandels immer noch relevant? Hat es die versprochenen Vorteile gebracht?

Die Geschichte des Wandels

Alles begann 2006 in einem Interview mit Amazon CTO Werner Vogels:

"Den Entwicklern operative Verantwortung zu geben, hat die Qualität der Services sowohl aus Kunden- als auch aus technologischer Sicht erheblich verbessert. Im traditionellen Modell befindet sich zwischen der Entwicklung und dem Betrieb der Software eine Trennwand, und nach Inbetriebnahme der Software wird diese von Entwicklern nicht mehr weiter beachtet. Nicht so bei Amazon. 'You build it, you run it.' Dies bringt Entwickler in Kontakt mit dem täglichen Betrieb ihrer Software. Es bringt sie auch in täglichen Kontakt mit den Kunden, und diese Kundenfeedbackschleife ist für die Verbesserung der Servicequalität unerlässlich."

Dies war der Beginn von "you build it, you run it" – einer neuen Herangehensweise, die gut mit dem anschließenden Aufstieg der kollaborativen DevOps-Bewegung kombinierbar war, da das vorrangige Ziel darin bestand, die Mauern zwischen Entwicklung und Support einzureißen.

Die Idee verbreitete sich – und das aus gutem Grund. Die Überbrückung der Kluft zwischen Entwicklung und Operations ist sehr sinnvoll. Warum sollte das Team, das den Code geschrieben hat – das Team, das mit dem Produkt eng vertraut ist – nicht auch dasjenige sein, das seine Superheldenumhänge umwirft, wenn ein Vorfall eintritt? Diese Praxis verkürzt nicht nur die Behebungszeit, sondern bringt die Entwickler auch näher ans Kundenfeedback und an Echtzeitprobleme, um zuverlässige Serviceverfügbarkeit sicherzustellen.

Klare Vorteile … und klare Herausforderungen

Wie bei allen Prozessänderungen brachten die Vorteile auch eine Reihe von Herausforderungen mit sich – und es gab viel Widerstand von traditionell strukturierten Unternehmen.

Zu den Vorteilen gehörten weniger Druck auf IT-Teams, produktionsfertiges Design, schnellere Reaktionszeiten und Code, der gründlicher getestet wurde (wenn du um 1 Uhr nachts aufgefordert wirst, einen Fehler zu beheben, wirst du höchstwahrscheinlich das nächste Deployment genau überprüfen). Das Konzept brachte auch bessere, vielseitigere Entwickler hervor, da sie sich neue Fähigkeiten aneignen und das Geschäft aus einem neuen Blickwinkel betrachten mussten.

Da die Verantwortung für den Code beim selben Team bleibt, hat dieser Ansatz auch einen positiven Einfluss auf die Prävention von Vorfällen. Ein Bericht ergab, dass Unternehmen, bei denen der Code vor dem Deployment von externen Teams geprüft wird, dieselbe Erfolgsquote aufwiesen wie Unternehmen ohne Codeüberprüfung. Peer-Reviews von Entwicklern, die das Produkt bereits kennen, wirkten sich hingegen positiv auf die Vorfallprävention aus.
Mit einigen der Herausforderungen dieses neuen Konzepts für das Vorfallmanagement befasste sich unser Team hier: "Die Herausforderung der [Dezentralisierung des Vorfallmanagements] ist, dass in Unternehmen trotzdem noch eine gewisse Zentralisierung erforderlich ist. Führungskräfte brauchen Zugang zu Berichten und Dokumentation. Unternehmens-Stakeholder wollen Updates. Sie möchten Metriken zu Vorfällen sehen, wie die mittlere Problemlösungszeit und die mittlere Bestätigungszeit. Sie erwarten klare Informationen, Post-Mortem-Berichte zu Vorfällen und Behebungsmaßnahmen.

Für viele Unternehmen, die sich in Richtung Dezentralisierung bewegen [und das Prinzip 'you build it, you run it' einführen möchten] und dies gut machen, ist die Antwort auf diese Herausforderung eine Technologie, die eine Dezentralisierung und Teamautonomie ermöglicht, um die Behebung von Vorfällen flexibel zu halten und dennoch Informationen zu zentralisieren, um die Geschäftsabteilung auf dem Laufenden zu halten."

Die andere zentrale Herausforderung besteht darin, dass in vielen Unternehmen, die das Prinzip "you build it, you run it" befolgen, Teamstrukturen und die interne Unternehmenskultur geändert werden müssen. Es erfordert eine Offenheit für die Zusammenarbeit, neue Herangehensweisen an Produkte und neue Teamstrukturen, die Kommunikationsbarrieren abbauen. Änderungen wie diese sind anspruchsvoll und erfordern einen sehr spezifischen Ansatz, wenn sie erfolgreich sein sollen.

Hält das Prinzip "you build it, you run it" also, was es versprochen hat?

Trotz der Herausforderungen lautet die Antwort unserer Erfahrung nach "Ja". "You build it, you run it" verändert die Branche immer noch und selbst traditionelle IT-Teams wenden sich langsam diesem Modell zu.

Es gibt keine Studien zur Einführung von "you build it, you run it", aber nach unserer Erfahrung geht dies oft mit der allgemeinen Einführung von DevOps-Prinzipien einher. Und hierfür haben wir Zahlen. Im Jahr 2017 hatten laut einem Forrester-Bericht 63 % der Unternehmen DevOps implementiert. Weitere 27 % hatten eine Implementierung im Laufe des Jahres geplant. Nur 1 % äußerte kein Interesse an einer Änderung.

Noch viel überzeugender ist aber, dass Unternehmen bei der Einführung von DevOps-Prinzipien einen durchschnittlichen Anstieg der Kundenzufriedenheit um 45 % und eine Steigerung der Mitarbeiterproduktivität um 43 % verzeichneten.