Gewohnheit #5: Scheitern ist keine Option

Obwohl es viele Wege gibt, DevOps richtig zu machen, gibt es auch einige Wege, wie DevOps häufig falsch gemacht wird. Oft sind diese schlechten "Gewohnheiten" nur Relikte der alten Vorgehensweise. In dieser Blog-Serie packen wir sieben dieser Szenarien aus, damit Unternehmen lernen können, wie man DevOps richtig einsetzt . Diese Woche gehen wir der Frage nach, warum das Mantra "Scheitern ist keine Option" Teams oft zurückhält.

Oft aktualisiert sich die Mentalität nicht so schnell wie die Technologie. Das ist wirklich bedauerlich, denn dadurch entgehen den Teams einige der Vorteile, die der technologische Fortschritt bietet.

Der Glaube, dass Scheitern keine Option ist, ist eine Denkweise, die aus früheren technologischen Beschränkungen resultiert, aber immer noch verbreitet ist. Bei den traditionellen Entwicklungszyklen wurde die Software nach einem Release-Kalender in Produktion gegeben, der nicht viele Möglichkeiten bot, Dinge richtig zu machen oder Fehler zu korrigieren. Sobald die Software in Produktion ging, waren seit der Erstellung des Codes zwei oder drei Monate vergangen. Die Details waren nicht mehr frisch in den Köpfen der Entwickler. Die Freigabe von Versionen war eine entmutigende Aufgabe, bei der Fehler sehr teuer waren. Unter diesen Umständen ist es verständlich, dass die Teams extrem risikoscheu wurden. Sie wollten sich vor dem Start von allem sicher sein.

Diese starke Risikoaversion wirkte sich auf die Unternehmenskultur aus. Die Mitarbeiter zögerten, etwas zu sagen, wenn sie auf ein Problem stießen oder feststeckten. Das traditionelle Arbeitsumfeld war sehr hierarchisch, und die Manager konzentrierten sich auf Leistungsindikatoren (KPIs) und andere Metriken. Wenn Fehler entdeckt wurden, war die Mentalität eher: "Wer ist schuld?" und nicht: "Wie können wir ihn beheben?" Offensichtlich ist Letzteres produktiver.

Reagieren in Echtzeit

Zum Glück macht die moderne Technologie viele der kostspieligen und zeitaufwändigen Prozesse überflüssig, die die Menschen dazu veranlasst haben, risikoscheu zu werden. Fehler können fast sofort behoben werden, so dass das Risiko viel geringer ist.

Jetzt ist es möglich, Bereitstellung und Freigabe zu trennen. Eine neue Version eines Produkts kann in Produktion gegeben werden, was eine Bereitstellung ist, aber die Freigabe der Funktionen in diesem neuen Produkt muss nicht gleichzeitig erfolgen. Feature-Toggles oder andere Produkte mit der gleichen Funktion können so implementiert werden, dass sich die neue Version weiterhin wie die vorherige Version verhält. Bevor irgendetwas anderes mit dem Produkt gemacht wird, kann das Team erneut überprüfen, ob es tatsächlich funktioniert. Sobald die Funktionalität bestätigt ist, ist der nächste Schritt, zu sagen: "OK, legen wir den Schalter um und nutzen wir die neuen Funktionen."

Die Möglichkeit, die Anzahl der Benutzer, die die neuen Funktionen sehen, zu begrenzen, mindert das Risiko weiter. Bei einem Webshop zum Beispiel könnte die neue Version auf 1 % der Benutzer beschränkt werden, während der Rest der Benutzer weiterhin die alte Version sieht. Auf diese Weise ist im Falle von Problemen nur ein kleiner Prozentsatz der Benutzer betroffen und es kommt nicht zum Absturz der gesamten Website, was zu Umsatzeinbußen führen würde. Releases können schrittweise erfolgen. Bugs können in Echtzeit behoben werden. Die Sorgen um "Big Bang"-Releases gehören wirklich der Vergangenheit an.

[embed]https://youtu.be/jK-6jpPDA1c[/embed]

Geteilte Verantwortung

Ein gleichberechtigteres Arbeitsumfeld trägt dazu bei, dass sich die Mentalität ändert. Anstatt dass ein Manager alle endgültigen Entscheidungen trifft, entscheiden die Teams gemeinsam. Die Bildung von Silos ist weniger wahrscheinlich. Anstatt sich auf eine bestimmte Sache zu konzentrieren, konzentrieren sich die Teams eher auf das große Ganze. Wenn die Mentalität lautet: "Wir sitzen im selben Boot", ist der Gedanke an ein Scheitern weniger beängstigend.

Die DevOps-Arbeitsweise macht die Arbeit auch transparenter. Die Menschen arbeiten eng zusammen und stehen in ständiger Kommunikation, während Entwickler traditionell von ihrem Vorgesetzten eine Aufgabe erhalten und diese dann alleine an ihrem Schreibtisch bearbeiten. Wenn man in ständigem Kontakt steht, ist es schwierig, auftretende Probleme zu verbergen. Eine kollaborativere Arbeitsumgebung wirkt sich positiv auf den Arbeitsablauf und die gesamte Unternehmenskultur aus.

Letztendlich wird der Fortschritt dadurch behindert, dass Misserfolge als schlecht oder negativ angesehen werden. Scheitern ist ein wichtiger Teil des Lernens. Mit der heutigen Technologie können Fehler fast sofort korrigiert werden. Scheitern als Teil des Prozesses zu akzeptieren, führt tatsächlich zu besseren Ergebnissen.

Machen Sie den nächsten Schritt in Richtung DevOps - nehmen Sie Kontakt auf!

Wir möchten Unternehmen dabei helfen, die DevOps-Arbeitsweise zu optimieren. Diese Blogserie ist nur der Anfang dessen, was wir anbieten können! Setzen Sie sich mit uns in Verbindung, um mehr darüber zu erfahren, wie wir Ihrem Team helfen können, DevOps richtig einzusetzen.

Bis dahin erfahren Sie beim nächsten Mal, warum "unsere Superhelden beheben Produktionsprobleme immer sehr schnell" die sechste Angewohnheit eines höchst ineffektiven DevOps-Teams ist.