[Kostenlos] Building Secure & Reliable Systems (PDF, O'Reilly) - und 2 andere SRE Bücher! (kostenlos durch Google Cloud)

Hi,

Kommt leider super stark auf gewisse Faktoren an. Wenn es darum geht ein Buy-In für "DevOps" über Namensbezeichnungen hinaus zu bekommen, braucht man Vertrauen in den technologischen Ansatz und den kulturellen Wandel, sowie eine gewisse Bereitschaft in der Einführungsphase weniger Kapazität für Feature Delivery zu haben, weil man einige nicht-funktionale Themen anfassen muss (Automatisierung, Team Setup, Tooling, ggf. neue Tests etc...). Das sich das mit sehr hoher Wahrscheinlichkeit lohnt steht außer Frage, ist aber vielen nicht bewusst. Der State of DevOps Report oder das Buch "Accelerate" von Nicole Forsgren et Al. (beides Management-tauglich) liefern hier einige Argumente, die Dir nutzen könnten.

Für das Buy-In werden aber zudem folgende Punkte wichtig sein: Welche Rolle spielt Software oder IT allgemein im Unternehmen? Wird es als strategisch wichtig wahrgenommen? Wie stark ist der Zusammenhang zu den Endprodukten/Dienstleistungen, welche das Unternehmen verkauft, bzw. hat mal jemand holistisch draufgeblickt und ist in der Lage Mehrwerte zu identifizieren (z.B. Produktivität, Umsatz, Kundenzufriedenheit, etc...)?

Wenn das alles nicht der Fall ist, ist es natürlich immer schwer auf der Ebene zu argumentieren. Ansatzpunkte können trotzdem Themen wie "typische" DevOps Benchmarks sein, welche nachweislich auch den allgemeinen Unternehmenserfolg positiv beeinflussen können, wie z.B. Lead-Time-to-Deploy, Time-to-Restore etc., oder andere Vorteile, wie gesteigerte Attraktivität des Unternehmens am Arbeitsmarkt.

Aus technologischer Sicht kann man es glücklicherweise einfacher angehen. Wichtig ist erstmal zu definieren, was man eigentlich erreichen möchte, da "DevOps weil ist halt gerade angesagt", wie bereits von Dir erwähnt, selten funktioniert. Beispiele wären: 100% Automatisierung, max. 15 Minuten Deployment-time (was ich oftmals kritisch sehe, da einige Arten von Tests, wie z.B. Mutation Tests dann eventuell nicht mehr durchgeführt werden können), max. 5 Minuten Time-to-Restore, 1% Error Budget, >90% Zufriedenheit der Entwickler/Anwender etc... Wenn man das gemacht hat und weitere potentiell vielversprechende Prinzipien nach und nach evaluiert (z.B. Code Reviews oder später ggf. GitOps), findet das Team in der Regel auch einen Weg selbstständig in einen "richtigen" DevOps oder SRE Modus zu kommen. Wichtig ist es meiner Erfahrung nach auch hierbei die Ziele team-intern ambitioniert zu halten, da dies nachweislich zu besseren Resultaten führt. Ich will jetzt nicht das OKR-Fass aufmachen, aber speziell die Philosophie über Ambitionen, welche dahinter steckt, hat eigentlich noch keinem geschadet.

Mal so als grobe Zusammenfassung aus meinen Erfahrungen
Viele Grüße

Wobei eines meiner O'Reilly Lieblingsbücher nicht mal ein Tier auf dem Cover hat.

Als 2nd Edition im Web
docstore.mik.ua/ore…htm

Wird bei Amazon trotz 1154 Seiten und 1,4 kg als Taschenbuch geführt.

Du liest im Urlaub Büro Kram? Sowas liest man wenn überhaupt in Arbeitszeit...

und wie kommst du zu dieser Erkenntnis?

nicht von O'Reilly