Techniken für leistungsstarke DevOps-Teams

Videotranskript

Wir haben ChatGPT genutzt, um die Grammatik und Syntax des Transkripts zu verbessern.

Hallo zusammen. Danke, dass ihr gekommen seid. Ich bin Branislav. Ich bin Engineering Lead bei Platform.sh. Außerdem bin ich Ingenieur, Vater, Ehemann und ein Fan von Abfallvermeidung – was in dieser Präsentation noch nützlich sein wird. Heute werde ich über Performance-Optimierung sprechen und darüber, welche Strategien Unternehmen anwenden können, um ihre Prozesse zu optimieren.

Bevor wir anfangen: Wie viele von euch sind Manager? Wie viele von euch sind Ingenieure, die dazu neigen, Manager zu werden? Und wie viele von euch sind DevOps? Super! Dann seid ihr hier genau richtig.

Nun, wie viele von euch wissen, wer das ist? Das ist Bruce McLaren, geboren 1937 und verstorben 1970. Er war ein Pionier im Rennsport und schuf einige der beeindruckendsten und fortschrittlichsten Autos der Geschichte. Auch nach seinem Tod war McLaren weiterhin erfolgreich und gewann acht Konstrukteurs- und zwölf Fahrer-Meisterschaften in der Formel 1. Die wissen ein oder zwei Dinge darüber, wie man hochleistungsfähige Maschinen baut.

Es gibt allerdings ein Problem – diese Maschinen sind absolute „Schneeflocken“. Was bedeutet das? Stell dir vor, du startest einen Formel-1-Wagen. Du drehst nicht einfach den Schlüssel um. Stattdessen schließt man das Auto an eine externe Maschine an, die das Öl erwärmt. Sobald das Öl die richtige Temperatur hat, wird es in das Auto gepumpt, wodurch der Motor langsam geschmiert und erwärmt wird. Dieser Vorgang wird von zahlreichen Technikern mithilfe leistungsstarker Computer gesteuert, alles unter der Aufsicht eines „Engine-Starting-Supervisors“ – eine echte Berufsbezeichnung! Erst dann ist alles bereit, um den Motor zu starten. Wie gesagt, es ist eine hochspezialisierte Maschine, ein „Snowflake“.

Was ist das meistverkaufte Auto der Welt? Es ist kein McLaren, sondern der Toyota Corolla. Seit seiner Einführung in den 1960er Jahren wurden mehr als 50 Millionen Exemplare verkauft. Toyota schneidet als Hersteller viel besser ab als McLaren. Wenn man darüber nachdenkt, schneiden Ford, Volkswagen und so ziemlich jeder Autohersteller besser ab als McLaren. Warum?

Lerne diesen Mann kennen: Eiji Toyoda. Er wurde 1913 geboren und wurde 100 Jahre alt. Er war ein japanischer Industrieller und Vorsitzender von Toyota. Seine Geschichte ist faszinierend. Nach dem Zweiten Weltkrieg wurde er von den Amerikanern eingeladen, die Produktionsstätten von Ford zu besuchen, um Massenproduktion und Fabrikorganisation zu verstehen. Er kehrte zu einem angeschlagenen Toyota zurück, das manchmal mehr als 1.000 Autos pro Monat produzierte, und versuchte, bessere Prozesse einzuführen. Er erfand das, was man „The Toyota Way“ nennt.

Als Teil des Toyota Way führte er zwei Techniken ein. Die eine ist Kanban. Wer hier nutzt Kanban nicht? Ein, zwei, drei Leute. Er war Mitautor dieses Prozesses. Die zweite ist Kaizen, und darüber werde ich heute sprechen. „Kai“ bedeutet Veränderung und „Zen“ bedeutet gut. Es ist also eine gute Veränderung oder eine Verbesserung. Diese Methodik konzentriert sich auf kontinuierliche Verbesserung in kleinen Schritten, ohne große Innovationen oder Revolutionen und ohne drastische Veränderungen.

Warum? Das liegt auf der Hand. Ein großes Unternehmen, das eine massive Veränderung einführt, stoppt die Produktionslinie, unterbricht den Prozess und macht es allen schwer. Dann muss man langsam alles von Grund auf neu starten. Diese Methodik legt auch Wert auf Prozesse, also auf Vertrautheit. Wenn du eine gute Dokumentation und eine vertraute Umgebung hast, kann sich dort Kreativität entfalten. Schließlich fördert Kaizen die Automatisierung, die der Schlüssel zur performance ist.

Kaizen basiert auf 10 Prinzipien, bei denen es darum geht, fundierte Entscheidungen zu treffen. Es ist wichtig, den Status quo in kleinen, schrittweisen Schritten zu durchbrechen. Perfektionismus hat hier keinen Platz; der Fokus liegt darauf, das Ziel Schritt für Schritt zu erreichen. Dieser Ansatz fördert analytisches Denken und nutzt das kollektive Wissen aller in der Organisation. Er priorisiert die Wirtschaftlichkeit von Veränderungen, was bedeutet, dass du den kleinsten, einfachsten Hebel findest, um das bestmögliche Ergebnis zu erzielen. Und das zehnte Prinzip lautet „Hör nie auf, umzusetzen“, was bedeutet, dass der Prozess fortlaufend und zyklisch ist – er endet nie. Jeder Zyklus sollte der Organisation ein wenig mehr Verbesserung bringen.

In der Praxis sieht das so aus: Zuerst planst du – definierst das Problem, schlägst Lösungen vor und legst Maßnahmen fest, um den Erfolg zu messen. Dann setzt du den Plan um und testest kleine Änderungen, um sicherzustellen, dass du auf dem richtigen Weg bist. Sobald das erledigt ist, überprüfst und bewertest du alle Daten, um sicherzustellen, dass die Abweichungen zwischen dem, was du erwartet hast, und dem, was du bekommen hast, minimal sind. Schließlich standardisierst du die Änderungen in der gesamten Organisation.

Das Ziel ist es, die Performance zu steigern, indem Verschwendung reduziert wird. Was ist Verschwendung? Denkt an verschwendete Zeit – Meetings, bei denen ihr nicht gebraucht wurdet oder andere Prioritäten hattet. Denkt an Arbeit, die verworfen werden musste, weil sie doppelt vorhanden oder irrelevant war. Für diejenigen in der Fertigung – auch wenn hier wohl niemand aus diesem Bereich ist – denkt an verschwendete Materialien. Für den Rest von uns ist es verschwendeter Strom, CPU, RAM, Speicherplatz, Bandbreite – alles, was das Hosting teurer macht.

Wir versuchen also, die performance zu steigern, aber woher wissen wir, ob wir uns tatsächlich verbessert haben? Wie können wir messen, ob wir auf dem richtigen Weg sind? Laut dem State of DevOps-Bericht – wie viele von euch haben den übrigens gelesen? Hand hoch. Okay, ihr wisst, wovon ich rede. Laut dem „State of DevOps“-Bericht, der jedes Jahr veröffentlicht wird, ist die Deployment-Häufigkeit einer der wichtigsten Indikatoren, auf die man achten sollte. Seit sieben oder acht Jahren sagen sie jedes Jahr dasselbe: Deployment-Häufigkeit und die Vorlaufzeit bis zur Wiederherstellung sind die beiden wichtigsten Kennzahlen.

Was bedeutet das? Ihr solltet nicht jeden Monat oder gar jede Woche ein Deployment durchführen. Ihr solltet ein Deployment durchführen, wann immer es nötig ist – auf Abruf. Das Vermeiden von Ausfällen ist nicht das Ziel, denn der beste Weg, Ausfälle zu vermeiden, ist, gar nichts zu tun. Stattdessen müsst ihr sicherstellen, dass ihr euch schnell erholen könnt, wenn doch mal ein Ausfall passiert. Hochleistungsfähige Teams sind solche, die sich in weniger als einer Stunde erholen können.

Der aktuelle State of DevOps-Bericht führt zudem das Konzept der „ausgewogenen Teams“ ein. Das sind Teams mit hoher Performance, hoher organisatorischer Effektivität, hoher Arbeitszufriedenheit und geringem Burnout – eine Neuerung im diesjährigen Bericht. Ausgewogene Teams nutzen Technologie nachhaltig und erzielen dadurch bessere Leistungen.

Lass mich das wiederholen: Hohe Performance geht mit häufigeren Deploys einher. Das ist die Kennzahl, auf die du achten musst. Die Zeit zwischen Ausfällen ist nicht so wichtig. Was zählt, ist, wie schnell du dich von einem Ausfall erholst.

Wenn du alle für hohe Performance erforderlichen Fähigkeiten kategorisieren möchtest, kannst du sie in drei Gruppen einteilen: technische Fähigkeiten, Prozessoptimierung und eine Kultur der psychologischen Sicherheit. Ich werde auf jeden dieser Punkte etwas näher eingehen, aber fangen wir mit den technischen Fähigkeiten an.

Der erste Punkt ist, sich von veralteter Technologie zu trennen. Das scheint offensichtlich, aber wenn du mit nicht mehr unterstützten Laufzeitversionen arbeitest, hast du schon ein Problem. Wer hier arbeitet mit PHP 8 oder älter? Wenn ja, hast du ein Problem. Nicht mehr unterstützte Anwendungsversionen, Abhängigkeiten oder überflüssige Technologien können dich ebenfalls bremsen. Oder stell dir vor, du hast ein Datenmodell, das deinen Anforderungen nicht mehr entspricht – wie oft musstest du deinen Stakeholdern schon sagen: „Das geht nicht, weil die Datenbank es nicht zulässt“? Das ist ein Problem. Enge Kopplungen sind ein weiteres Problem, da sie deine Flexibilität einschränken.

All diese Dinge – nicht unterstützte Technologien, veraltete Systeme, enge Kopplung – verursachen technische Schulden. Technische Schulden entstehen meist aus vielen Gründen, aber ein Hauptgrund ist das Festhalten an veralteten Technologie-Stacks. Stattdessen sollten wir über moderne Architektur nachdenken.

Denkt darüber nach, cloudfreundliche, cloudnative Designs oder Design Patterns einzuführen. Beginnt mit lose gekoppelten Architekturen. Ich spreche nicht unbedingt von Microservices, aber Microservices könnten eine Lösung sein. Die Idee ist, sich auf kleine, schrittweise Verbesserungen zu konzentrieren, anstatt ein einziges riesiges Update zu implementieren, das kläglich scheitern könnte. Ihr wollt kleinere Änderungen testen und das Risiko minimieren.

Natürlich sind kontinuierliche Integration, Bereitstellung und Deployment entscheidend, wenn ihr sie bewältigen könnt – das sollte euer Ziel sein. Ich möchte einen bestimmten Punkt hervorheben: unveränderliche Container. Wer von euch hostet auf unveränderlichen Containern? Nur eine Handvoll von euch. Gefällt es euch? Einigen von euch wahrscheinlich nicht. Aber unveränderliche Container sind entscheidend, weil sie die Integrität eurer Anwendung garantieren, sobald sie live ist.

Denkt außerdem über APIs nach, die Anwendungen verbinden, und gestaltet sie so, dass sie antifragil sind. Was bedeutet das? Es bedeutet, dass das System einzelne Ausfälle verkraften und trotzdem weiter funktionieren kann. Selbst wenn etwas schiefgeht, ermöglicht es euch eine schnelle Wiederherstellung.

Der nächste Schritt ist die Reduzierung von Verschwendung durch Standardisierung. Was bedeutet das? Schaut euch die Betriebssysteme an, die eure Organisation nutzt – denkt an die Lizenz- und Wartungskosten. Denkt auch an Entwicklungsstandards. Wenn diese von Anwendung zu Anwendung unterschiedlich sind, werdet ihr Schwierigkeiten haben, Mitarbeiter zwischen Projekten zu versetzen, funktionsübergreifende Teams zu bilden oder neue Mitarbeiter einzuarbeiten. Längere Einarbeitungsprozesse, langsamere Code-Reviews und die Anpassung an unterschiedliche Standards kosten allesamt Zeit.

Standardisierung sollte ein ultimatives Ziel haben: Automatisierung. Sobald du standardisiert hast, kannst du automatisieren, und das ist entscheidend. Automatisiere alles. Im Hosting und bei DevOps bedeutet das, produktionsähnliche Umgebungen für Testzwecke zu haben.

Um das zu erreichen, haben wir „Infrastructure as Code“ eingeführt, ein Konzept, das bereits relativ bekannt ist. Die Idee dahinter ist, das Rezept für die Bereitstellung der Infrastruktur in einer Datei, also im Programmcode, zu haben. Dieser Code kann versionsverwaltet werden, sodass du Änderungen nachverfolgen und deine Infrastruktur bei Bedarf feinabstimmen kannst. Denk an Ereignisse wie den Black Friday, bei denen du deine Infrastruktur möglicherweise schnell anpassen musst.

Nun kommt ein entscheidender Punkt: Dein erster Deployment in die Produktivumgebung sollte nicht der eigentliche erste Deployment in der Produktivumgebung sein. Wer weiß, was das bedeutet? Eine Person? Okay. Das bedeutet, dass du vor dem Deployment in der Produktivumgebung alles in einer Umgebung testen musst, die die Produktivumgebung exakt widerspiegelt. Du brauchst eine eins-zu-eins-Kopie der Produktionsumgebung, Byte für Byte, in der du alles sicher testen kannst – Code, Infrastruktur, Datenbanken, Caches usw. Das Testen in einer solchen Umgebung ist unerlässlich, um Überraschungen bei der Inbetriebnahme zu vermeiden.

Es ist schön und gut, eine solche Testumgebung zu haben, aber sie kann schwierig zu warten sein. Einige von euch denken vielleicht schon an Kubernetes oder ähnliche Tools. Das Endziel hier ist die Kommerzialisierung. Was bedeutet das? Es bedeutet, dass man jede benötigte Infrastruktur bedarfsgerecht und im Self-Service-Modus bereitstellen kann.

Bei Platform.sh, dem Unternehmen, für das ich arbeite, bieten wir euch genau das. Es ist Platform-as-a-Service, und unser neuestes Produkt, Upson, wurde entwickelt, um diese Anforderungen zu erfüllen. Das knüpft an die erste Säule an – die technischen Fähigkeiten. Kommen wir nun zur zweiten Säule: schlanke Prozesse.

Was sind schlanke Prozesse? Du brauchst deine Rituale und Prozesse, aber sie sollten so gestaltet sein, dass sie sich darauf konzentrieren, dem Kunden einen Mehrwert zu bieten. Das ist das Hauptziel. Alles, was du tust, was nicht direkt einen Mehrwert schafft, ist Verschwendung.

Wie stellen wir also den Nutzer in den Mittelpunkt? Es gibt verschiedene Techniken, aber was bei uns gut funktioniert, sind funktionsübergreifende Initiativen. Diese ermöglichen es Teams, bei Bedarf Entscheidungen zu treffen, ohne alles an höhere Führungsebenen eskalieren zu müssen. Dieser Ansatz vermeidet das „Eskalationsspiel“, bei dem Entscheidungen mehrere Genehmigungsstufen durchlaufen müssen, bevor Maßnahmen ergriffen werden können.

Schauen wir uns das genauer an. Zum ersten Mal besagt der State of DevOps-Bericht, dass Teams mit einer starken Nutzerorientierung eine um 40 % höhere organisatorische Performance aufweisen. Vierzig Prozent sind eine riesige Zahl. Funktionsübergreifende Initiativen sind ein Weg, dies zu erreichen. Sie ermöglichen es Organisationen mit starren Strukturen oder Abteilungen, Menschen aus verschiedenen Teams zusammenzubringen, ihnen eine Aufgabe zu geben und ihnen die Infrastruktur zur Verfügung zu stellen, die sie benötigen, um die Arbeit zu erledigen.

Bei Platform.sh haben wir das Konzept eines „Produkt-Trios“ eingeführt. Das bedeutet, dass ein Produktmanager, ein Produktdesigner und ein leitender Ingenieur zusammenarbeiten, um eine neue Funktion zum Leben zu erwecken. Wer möchte mehr darüber erfahren? Bleibt nach dieser Session noch da, dann gehen wir näher ins Detail. Die Idee ist, alle zusammenzubringen, die man braucht, um die Aufgabe zu erledigen.

In diesem Produkt-Trio sorgt der Produktmanager dafür, dass das Team den Nutzer im Blick behält. Der Produktdesigner stellt sicher, dass das, was ihr entwickelt, sowohl funktional als auch ästhetisch ansprechend ist. Der leitende Ingenieur sorgt dafür, dass die Lösung in die gesamte technische Architektur passt.

Ich habe eine Beschreibung bereitgestellt, werde aber nicht allzu sehr auf diese Folien eingehen – ihr bekommt am Ende dieser Sitzung einen Link zu den Folien. Das Ziel ist es, Entscheidungen am richtigen Ort zu treffen und das organisatorische „Stille-Post-Spiel“ zu vermeiden, bei dem Nachrichten von einer Person zur nächsten weitergereicht werden und dabei an Klarheit verlieren.

Wie macht man das? Man stellt sicher, dass das Team alles hat, was es braucht, um Ergebnisse zu liefern. Dazu gehören dedizierte Entwicklungsumgebungen, die Möglichkeit, Änderungen an der Infrastruktur zu testen, und die Möglichkeit, sicherzustellen, dass alles funktioniert, bevor es in die Staging-Umgebung und schließlich in die Produktivumgebung übernommen wird.

Das gibt den Mitarbeitern Zeit, sich um wichtige Dinge wie die Dokumentation zu kümmern. Dokumentation ist das Fundament einer erfolgreichen Organisation. Es gibt verschiedene Tools, die du nutzen kannst – unter anderem Confluence, GitBook, Read the Docs, Sphinx und Guru –, um die Dokumentation in deinen Teams zu verwalten. Eine ordentliche Dokumentation trägt dazu bei, Code-Reviews effizienter zu gestalten und eine Kultur des Feedbacks zu fördern.

Kommen wir nun zur letzten Säule: der generativen Kultur. Kultur ist der entscheidende Faktor für das Wohlbefinden der Mitarbeiter, und ich habe einige wichtige Aspekte aufgelistet, auf die du dich konzentrieren musst, wenn du eine gute Kultur entwirfst oder förderst. Du musst auf psychologische Sicherheit achten und sicherstellen, dass sich die Leute sicher fühlen, ihre Ideen und Bedenken zu äußern. Du musst offene und qualitativ hochwertige Kommunikation fördern und dafür sorgen, dass deine Kollegen die Möglichkeit haben, zu lernen und Informationen auszutauschen.

All das hängt mit der generativen Kultur zusammen, einem Konzept, das sehr wichtig ist, dessen Erörterung aber eine ganze Sitzung für sich beanspruchen könnte. Kurz gesagt unterteilt Westrum Unternehmenskulturen in drei Typen:

1. Pathologisch – getrieben von Angst und Bedrohung, wobei die Menschen mehr um ihr persönliches Überleben besorgt sind als um die Ziele der Organisation.
2. Bürokratisch – hier liegt der Fokus auf der Einhaltung von Regeln und dem Schutz individueller Reviere (mein Team, meine Abteilung).
3. Generativ – auf die Mission der Organisation ausgerichtet, in der alle zusammenarbeiten, um Mehrwert zu schaffen.

In einer generativen Kultur ist der wichtigste Maßstab die Performance der Organisation, nicht die individuelle Performance. Das ist ein entscheidender Unterschied, der Zusammenarbeit und gemeinsame Verantwortung fördert.

In der Praxis reduziert eine generative Kultur Burnout, was eine der Hauptursachen für verminderte Teamperformance ist. Laut dem aktuellen „State of DevOps“-Bericht sinkt Burnout in Organisationen mit hoher Arbeitsplatzsicherheit und psychologischer Sicherheit um 61 %. Um deine Kollegen weiterhin dabei zu unterstützen, ihr Bestes zu geben, musst du sicherstellen, dass die Mission der Organisation im Mittelpunkt bleibt.

Es ist viel einfacher, alle auf die Mission auszurichten, wenn das Management auf Vertrauen statt auf Kontrolle setzt. Dies geschieht auch dadurch, dass man andere innerhalb der Organisation fördert, anstatt sich selbst zu profilieren. Denk daran: Hochleistungsteams bestehen nicht aus einzelnen, herausragenden Stars. Sie bestehen aus Konstellationen – Teams von Menschen, die nahtlos zusammenarbeiten.

Vielen Dank.