Techniken für hochleistungsfähige DevOps-Teams

Video-Transkript

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

Hallo zusammen. Danke, dass Sie gekommen sind. Ich bin Branislav. Ich bin ein technischer Leiter bei Platform.sh. Ich bin auch Ingenieur, Vater, Ehemann und ein Streber in Sachen Abfallvermeidung, was sich in dieser Präsentation als nützlich erweisen wird. Heute werde ich über Leistungsoptimierung sprechen und darüber, welche Strategien Unternehmen anwenden können, um ihre Prozesse zu optimieren.

Bevor wir beginnen: Wie viele von Ihnen sind Manager? Wie viele von Ihnen sind Ingenieure, die dazu neigen, Manager zu werden? Und wie viele von Ihnen sind DevOps? Sehr gut! Dann sind Sie hier richtig.

Nun, wie viele von Ihnen wissen, wer das ist? Das ist Bruce McLaren, geboren 1937 und verstorben 1970. Er war ein Pionier des Rennsports und schuf einige der erstaunlichsten und fortschrittlichsten Autos der Geschichte. Auch nach seinem Tod hat McLaren weiter gewonnen: acht Konstrukteursmeisterschaften und 12 Fahrermeisterschaften in der Formel 1. Das Unternehmen weiß ein oder zwei Dinge über die Herstellung hochleistungsfähiger Maschinen.

Allerdings gibt es ein Problem: Diese Maschinen sind absolute Schneeflocken. Was bedeutet das? Stellen Sie sich vor, Sie starten ein Formel-1-Auto. Man dreht nicht einfach den Schlüssel um. Stattdessen schließen Sie das Auto an eine externe Maschine an, die das Öl erhitzt. Sobald das Öl die richtige Temperatur erreicht hat, wird es in das Auto gepumpt und der Motor langsam geschmiert und aufgeheizt. Dieser Prozess wird von zahlreichen Technikern mit leistungsstarken Computern gesteuert, die alle von einem Motorstarter beaufsichtigt werden - eine echte Berufsbezeichnung! Erst dann können sie den Motor starten. Wie gesagt, es ist eine hochspezialisierte Maschine, eine Schneeflocke.

Welches ist das meistverkaufte Auto der Welt? Es ist kein McLaren, sondern der Toyota Corolla. Seit seinen Anfängen in den 1960er Jahren wurden mehr als 50 Millionen Exemplare verkauft. Toyota als Hersteller schneidet viel besser ab als McLaren. Wenn man darüber nachdenkt, schneiden Ford, Volkswagen und so ziemlich jeder Autohersteller besser ab als McLaren. Und warum?

Lernen Sie diesen Mann kennen, Eiji Toyoda. Er wurde 1913 geboren und lebte 100 Jahre lang. Er war ein japanischer Industrieller und der Vorsitzende von Toyota. Seine Geschichte ist faszinierend. Nach dem Zweiten Weltkrieg wurde er von den Amerikanern eingeladen, die Produktionsstätten von Ford zu besuchen, um die Massenproduktion und die Fabrikorganisation zu verstehen. Er kehrte zu dem angeschlagenen Unternehmen Toyota zurück, das manchmal mehr als 1.000 Autos pro Monat produzierte, und versuchte, bessere Verfahren einzuführen. Er erfand das, was man den "Toyota Way" nennt.

Als Teil des Toyota-Weges führte er zwei Techniken ein. Die eine ist Kanban. Wer hier benutzt nicht Kanban? Einer, zwei, drei Leute. Er hat dieses Verfahren mitentwickelt. Die zweite ist Kaizen, und ich werde heute über Kaizen sprechen. "Kai" bedeutet Veränderung, und "Zen" bedeutet gut. Es ist eine gute Veränderung oder eine Verbesserung. Diese Methode konzentriert sich auf die kontinuierliche Verbesserung in kleinen Schritten, ohne große Innovationen oder Revolutionen und ohne drastische Veränderungen.

Und warum? Das liegt auf der Hand. Ein großes Unternehmen, das eine massive Veränderung einführt, hält die Produktionslinie an, stoppt den Prozess und erschwert die Dinge für alle. Dann muss man langsam alles wieder von vorne beginnen. Bei dieser Methodik stehen auch die Prozesse im Vordergrund, d. h. die Vertrautheit. Wenn man über eine gute Dokumentation und eine vertraute Umgebung verfügt, kann sich die Kreativität entfalten. Und schließlich fördert Kaizen die Automatisierung, die der Schlüssel zur Leistung 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 verändern. Perfektionismus hat hier keinen Platz; der Schwerpunkt liegt darauf, das Ziel Schritt für Schritt zu erreichen. Dieser Ansatz fördert das analytische Denken und zapft das kollektive Wissen aller Mitarbeiter im Unternehmen an. Er stellt die Ökonomie des Wandels in den Vordergrund, d. h. man sucht nach der kleinsten, einfachsten Hebelwirkung, um das bestmögliche Ergebnis zu erzielen. Und das zehnte Prinzip lautet: "Niemals aufhören zu implementieren", was bedeutet, dass der Prozess immerwährend und zyklisch ist - er endet nie. Jeder Zyklus sollte der Organisation ein wenig mehr Verbesserung bringen.

In der Praxis sieht das folgendermaßen aus: Zuerst planen Sie - Sie definieren das Problem, schlagen Lösungen vor und legen Maßnahmen zur Erfolgskontrolle fest. Dann setzen Sie den Plan um und testen kleine Änderungen, um sicherzustellen, dass Sie auf dem richtigen Weg sind. Danach überprüfen und bewerten Sie alle Daten, um sicherzustellen, dass die Abweichungen zwischen den Erwartungen und den Ergebnissen minimal sind. Schließlich standardisieren Sie die Änderungen im gesamten Unternehmen.

Ziel ist es, die Leistung zu steigern, indem die Verschwendung reduziert wird. Was ist Verschwendung? Denken Sie an verschwendete Zeit - Sitzungen, bei denen Sie nicht gebraucht wurden oder andere Prioritäten hatten. Denken Sie an Arbeiten, die wegen Doppelarbeit oder Irrelevanz gestrichen werden mussten. Diejenigen, die in der Produktion tätig sind - auch wenn das hier niemand zu sein scheint - denken an verschwendete Materialien. Für den Rest von uns ist es die Verschwendung von Strom, CPU, RAM, Speicherplatz, Bandbreite - alles, was das Hosting teurer macht.

Wir versuchen also, die Leistung zu steigern, aber woher wissen wir, ob wir uns tatsächlich verbessert haben? Wie können wir messen, ob wir uns in einer guten Position befinden? Laut dem State of DevOps-Bericht - wie viele von Ihnen haben ihn übrigens gelesen? Hände hoch. Na gut, Sie wissen, wovon ich spreche. Laut dem State of DevOps-Bericht, der jedes Jahr veröffentlicht wird, ist die Bereitstellungshäufigkeit einer der wichtigsten Indikatoren, auf den man achten sollte. In den letzten sieben oder acht Jahren wurde jedes Jahr dasselbe gesagt: Die Bereitstellungshäufigkeit und die Vorlaufzeit bis zur Wiederherstellung sind die beiden wichtigsten Kennzahlen.

Was bedeutet das? Sie sollten nicht jeden Monat oder sogar jede Woche einsatzbereit sein. Sie sollten immer dann bereitstellen, wenn es nötig ist - bei Bedarf. Die Vermeidung von Fehlern ist nicht das Ziel, denn die beste Art, Fehler zu vermeiden, ist, nichts zu tun. Stattdessen müssen Sie dafür sorgen, dass Sie sich schnell wieder erholen können, wenn ein Fehler auftritt. Leistungsstarke Teams sind diejenigen, die sich in weniger als einer Stunde erholen können.

Im neuesten State of DevOps-Bericht wird auch das Konzept der "ausgewogenen Teams" vorgestellt. Dabei handelt es sich um Teams mit hoher Leistung, hoher organisatorischer Effektivität, hoher Arbeitszufriedenheit und geringem Burnout - eine Neuerung im diesjährigen Bericht. Ausgewogene Teams setzen Technologie nachhaltig ein und erbringen dadurch eine bessere Leistung.

Lassen Sie mich dies wiederholen: Hohe Leistung ist mit häufigerem Einsatz verbunden. Das ist die Kennzahl, auf die Sie achten müssen. Die Zeitspanne zwischen den Ausfällen ist nicht so wichtig. Entscheidend ist, wie schnell Sie sich von einem Ausfall erholen.

Wenn Sie alle für eine hohe Leistung erforderlichen Fähigkeiten kategorisieren wollen, können Sie sie in drei Gruppen einteilen: technische Fähigkeiten, Prozessoptimierung und eine Kultur der psychologischen Sicherheit. Ich werde auf jede dieser Gruppen ein wenig näher eingehen, aber beginnen wir mit den technischen Fähigkeiten.

Der erste Punkt ist die Trennung von der alten Technologie. Es scheint offensichtlich, aber wenn Sie mit nicht unterstützten Laufzeitversionen arbeiten, sind Sie bereits in Schwierigkeiten. Wer arbeitet hier mit PHP 8 oder weniger? Wenn ja, dann haben Sie ein Problem. Nicht unterstützte Anwendungsversionen, Abhängigkeiten oder redundante Technologien können Sie ebenfalls in Bedrängnis bringen. Oder stellen Sie sich vor, Sie haben ein Datenmodell, das nicht mehr Ihren Anforderungen entspricht - wie oft mussten Sie Ihren Geschäftspartnern schon sagen: "Das geht nicht, weil die Datenbank es nicht zulässt"? Das ist ein Problem. Die enge Kopplung ist ein weiteres Problem, da sie Ihre Flexibilität einschränkt.

All diese Dinge - nicht unterstützte Technologie, veraltete Systeme, enge Kopplung - führen zu technischen Schulden. Technische Schulden entstehen in der Regel aus vielen Gründen, aber ein Hauptgrund ist das Festhalten an veralteten Technologie-Stacks. Stattdessen sollten wir über eine moderne Architektur nachdenken.

Denken Sie darüber nach, Cloud-freundliche, Cloud-native Designs oder Muster einzuführen. Beginnen Sie 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 eine einzige große Aktualisierung durchzuführen, die kläglich scheitern könnte. Sie wollen kleinere Änderungen testen und das Risiko minimieren.

Natürlich sind kontinuierliche Integration, Lieferung und Bereitstellung von entscheidender Bedeutung, wenn Sie sie bewältigen können - das sollte Ihr Ziel sein. Ich möchte eine bestimmte Sache hervorheben: unveränderliche Container. Wer hostet hier auf unveränderlichen Containern? Eine Handvoll von Ihnen. Mögen Sie es? Einige von Ihnen wahrscheinlich nicht. Aber unveränderliche Container sind von entscheidender Bedeutung, weil sie die Integrität Ihrer Anwendung garantieren, sobald sie in Betrieb ist.

Denken Sie auch an APIs, die Anwendungen miteinander verbinden, und gestalten Sie sie so, dass sie nicht anfällig sind. Was bedeutet das? Es bedeutet, dass das System mit einzelnen Fehlern umgehen kann und trotzdem funktioniert. Selbst wenn etwas schief geht, können Sie es schnell wiederherstellen.

Der nächste Schritt ist die Reduzierung von Verschwendung durch Standardisierung. Was bedeutet das? Denken Sie an die Betriebssysteme, die Ihr Unternehmen einsetzt - denken Sie an die Lizenz- und Wartungskosten. Denken Sie auch an die Entwicklungsstandards. Wenn sich diese von einer Anwendung zur anderen unterscheiden, wird es Ihnen schwer fallen, Mitarbeiter zwischen Projekten zu wechseln, funktionsübergreifende Teams zu bilden oder neue Mitarbeiter einzuarbeiten. Langwierige Prozesse für die Einarbeitung, langsamere Codeüberprüfungen und die Anpassung an unterschiedliche Standards kosten Zeit.

Die Standardisierung sollte nur ein Ziel haben: Automatisierung. Sobald Sie standardisiert sind, können Sie automatisieren, und das ist das Wichtigste. Automatisieren Sie alles. Im Bereich Hosting und DevOps bedeutet dies, produktionsähnliche Umgebungen für Testzwecke zu haben.

Um dies zu erreichen, haben wir "Infrastruktur als Code" eingeführt, ein bereits relativ bekanntes Konzept. Die Idee besteht darin, das Rezept für die Bereitstellung der Infrastruktur in einer Datei, in einem Code, zu speichern. Dieser Code kann versionskontrolliert werden, so dass Sie Änderungen nachverfolgen und Ihre Infrastruktur je nach Bedarf feinabstimmen können. Denken Sie an Ereignisse wie den Schwarzen Freitag, an dem Sie Ihre Infrastruktur möglicherweise schnell anpassen müssen.

Jetzt kommt ein entscheidender Punkt: Ihre erste Bereitstellung für die Produktion sollte nicht die tatsächliche erste Bereitstellung für die Produktion sein. Wer weiß schon, was das bedeutet? Eine Person? Nun gut. Das bedeutet, dass Sie vor der Bereitstellung für die Produktion alles in einer Umgebung testen müssen, die die Produktionsumgebung genau widerspiegelt. Sie brauchen eine eins-zu-eins, Byte-für-Byte-Kopie der Produktionsumgebung, in der Sie alles sicher testen können - Code, Infrastruktur, Datenbanken, Caches, usw. Das Testen in einer solchen Umgebung ist unerlässlich, um Überraschungen zu vermeiden, wenn Sie live gehen.

Es ist schön und gut, eine solche Testumgebung zu haben, aber es kann schwierig sein, sie zu pflegen. Einige von Ihnen denken vielleicht schon an Kubernetes oder ähnliche Tools. Das Endziel ist hier die Kommodifizierung. Was bedeutet das? Es bedeutet, dass Sie die Infrastruktur, die Sie benötigen, auf Abruf und im Selbstbedienungsmodus erhalten können.

Bei Platform.sh, dem Unternehmen, für das ich arbeite, stellen wir das für Sie bereit. Das ist Platform-as-a-Service, und unser neuestes Produkt, Upson, wurde entwickelt, um diese Anforderungen zu erfüllen. Damit sind wir bei der ersten Säule angelangt - den technischen Fähigkeiten. Lassen Sie uns nun zur zweiten Säule übergehen: schlanke Prozesse.

Was sind schlanke Prozesse? Sie brauchen Ihre Rituale und Prozesse, aber sie sollten so gestaltet sein, dass sie dem Kunden einen Mehrwert bieten. Das ist das Hauptziel. Alles, was nicht direkt zur Wertschöpfung beiträgt, ist Verschwendung.

Wie können wir uns also auf den Benutzer konzentrieren? Es gibt mehrere Techniken, aber was für uns gut funktioniert, sind funktionsübergreifende Initiativen. Diese ermöglichen es den Teams, bei Bedarf Entscheidungen zu treffen, ohne alles an höhere Managementebenen weiterleiten zu müssen. Mit diesem Ansatz wird das "Eskalationsspiel" vermieden, bei dem Entscheidungen mehrere Genehmigungsebenen durchlaufen müssen, bevor Maßnahmen ergriffen werden können.

Schauen wir uns das im Detail an. Im State of DevOps-Bericht heißt es zum ersten Mal, dass Teams mit einem starken Anwenderfokus eine um 40 % höhere Unternehmensleistung aufweisen. Vierzig Prozent sind eine gewaltige Zahl. Funktionsübergreifende Initiativen sind eine Möglichkeit, dies zu erreichen. Sie ermöglichen es Unternehmen mit starren Strukturen oder Abteilungen, Mitarbeiter aus verschiedenen Teams zusammenzubringen, ihnen eine Aufgabe zu geben und ihnen die nötige Infrastruktur zur Verfügung zu stellen, 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 ins Leben zu rufen. Wer möchte mehr darüber erfahren? Bleiben Sie nach dieser Sitzung, dann gehen wir noch mehr ins Detail. Der Grundgedanke ist, dass man alle Personen zusammenbringt, die man braucht, um die Arbeit zu erledigen.

In diesem Produkttrio sorgt der Produktmanager dafür, dass sich das Team auf den Benutzer konzentriert. Der Produktdesigner sorgt dafür, dass das Produkt, das Sie entwickeln, sowohl funktional als auch ästhetisch ansprechend ist. Der leitende Ingenieur sorgt dafür, dass sich die Lösung in die technische Gesamtarchitektur einfügt.

Ich habe eine Beschreibung gegeben, aber ich werde mich nicht zu sehr mit diesen Folien aufhalten - am Ende dieser Sitzung finden Sie einen Link zu den Folien. Ziel ist es, Entscheidungen an der richtigen Stelle zu treffen und das organisatorische "Telefonspiel" zu vermeiden, bei dem Nachrichten von einer Person zur anderen weitergereicht werden und auf diese Weise an Klarheit verlieren.

Wie machen Sie das? Man stellt sicher, dass das Team alles hat, was es braucht, um seine Aufgaben zu erfüllen. Dazu gehören dedizierte Entwicklungsumgebungen, die Möglichkeit, Infrastrukturänderungen zu testen und sicherzustellen, dass alles funktioniert, bevor es in den Staging- und schließlich in den Produktionsprozess überführt wird.

So haben die Mitarbeiter Zeit, sich um wichtige Dinge wie die Dokumentation zu kümmern. Die Dokumentation ist die Grundlage einer erfolgreichen Organisation. Es gibt mehrere Tools, die Sie zur Verwaltung der Dokumentation in Ihren Teams verwenden können, darunter Confluence, GitBook, Read the Docs, Sphinx und Guru. Eine ordnungsgemäße Dokumentation trägt dazu bei, dass Code-Reviews effizienter werden und eine Feedback-Kultur gefördert wird.

Lassen Sie uns nun über die letzte Säule sprechen: die generative Kultur. Die Kultur ist der wichtigste Faktor für das Wohlbefinden der Mitarbeiter, und ich habe einige wichtige Aspekte aufgelistet, auf die Sie bei der Gestaltung oder Förderung einer guten Kultur achten müssen. Sie müssen sich um die psychologische Sicherheit kümmern und sicherstellen, dass sich die Mitarbeiter sicher fühlen, um ihre Ideen und Bedenken zu äußern. Sie müssen eine offene und qualitativ hochwertige Kommunikation fördern und sicherstellen, dass Ihre Kollegen die Möglichkeit haben, zu lernen und Informationen auszutauschen.

All dies steht im Zusammenhang mit der generativen Kultur, einem Konzept, das sehr wichtig ist, dessen Behandlung aber eine ganze Sitzung in Anspruch nehmen könnte. Kurz gesagt, Westrum kategorisiert Organisationskulturen in drei Typen:

1. Pathologisch - angetrieben von Angst und Bedrohung, wobei die Menschen mehr um ihr persönliches Überleben als um die Ziele der Organisation besorgt sind.
2. Bürokratisch - hier liegt der Schwerpunkt auf der Befolgung von Regeln und dem Schutz des eigenen Reviers (mein Team, meine Abteilung).
3. Generativ - mit Schwerpunkt auf dem Auftrag der Organisation, wo alle zusammenarbeiten, um einen Mehrwert zu schaffen.

In einer generativen Kultur wird in erster Linie die Leistung der Organisation und nicht die Leistung des Einzelnen gemessen. Dies ist ein wesentlicher Unterschied, der die Zusammenarbeit und die gemeinsame Verantwortung fördert.

In der Tat verringert eine generative Kultur das Burnout, das eine der Hauptursachen für eine geringere Teamleistung ist. Laut dem jüngsten State of DevOps-Bericht wird Burnout in Organisationen mit einem hohen Maß an Arbeitsplatzsicherheit und psychologischer Sicherheit um 61 % reduziert. Um Ihre Kollegen weiterhin dabei zu unterstützen, ihre beste Arbeit zu leisten, müssen Sie sicherstellen, dass die Mission der Organisation im Mittelpunkt steht.

Es ist viel einfacher, alle an der Mission auszurichten, wenn das Management auf der Grundlage von Vertrauen und nicht von Kontrolle arbeitet. Dies geschieht auch dadurch, dass man andere innerhalb der Organisation fördert, anstatt sich selbst zu fördern. Bedenken Sie dies: Hochleistungsteams bestehen nicht aus einzelnen, erstaunlichen Sternen. Sie bestehen aus Konstellationen - Teams von Menschen, die nahtlos zusammenarbeiten.

Ich danke Ihnen vielmals.