Das Arbeitsbuch zur Standortzuverlässigkeit

Kapitel 1. Wie SRE mit DevOps zusammenhängt

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Klasse SRE implementiert Schnittstelle DevOps

Von Niall Richard Murphy,
Liz Fong-Jones, und Betsy Beyer,
mit Todd Underwood, Laura Nolan,
und Dave Rensin

Der Betrieb als Disziplin ist schwierig.¹ Es gibt nicht nur die allgemein ungelöste Frage, wie man Systeme gut führt, sondern auch die bewährten Methoden, die sich bewährt haben, sind stark kontextabhängig und werden bei weitem nicht überall angenommen. Auch die Frage, wie man Betriebsteams gut führt, ist weitgehend ungelöst. Es wird allgemein angenommen, dass die detaillierte Analyse dieser Themen ihren Ursprung in der operativen Forschung hat, die sich mit der Verbesserung von Prozessen und der Leistung des alliierten Militärs während des Zweiten Weltkriegs befasst, aber in Wirklichkeit denken wir schon seit Jahrtausenden darüber nach, wie wir Dinge besser betreiben können.

Doch trotz all dieser Bemühungen und Überlegungen ist ein zuverlässiger Produktionsbetrieb nach wie vor schwer zu erreichen - vor allem in den Bereichen Informationstechnologie und Software-Betrieb. In der Unternehmenswelt wird der Betrieb oft als Kostenstelle behandelt,² was sinnvolle Ergebnisverbesserungen schwierig, wenn nicht gar unmöglich macht. Die enorme Kurzsichtigkeit dieses Ansatzes ist noch nicht allgemein bekannt, aber die Unzufriedenheit mit diesem Ansatz hat zu einer Revolution in der Organisation unserer IT-Arbeit geführt.

Diese Revolution entstand aus dem Versuch, eine Reihe von gemeinsamen Problemen zu lösen. Die neuesten Lösungen für diese Probleme werden unter zwei verschiedenen Namen geführt - DevOps und Site Reliability Engineering (SRE). Obwohl wir über sie einzeln sprechen, als ob sie völlig unterschiedliche Reaktionen auf die gerade beschriebene Unternehmensmentalität wären,³ hoffen wir, dich davon überzeugen zu können, dass sie sich in Wirklichkeit viel ähnlicher sind und die Praktiker beider Ansätze viel mehr gemeinsam haben, als du vielleicht annimmst.

Doch zunächst ein paar Hintergrundinformationen zu den Grundprinzipien der beiden.

Hintergrund zu DevOps

DevOps ist ein loser Verbund von Praktiken, Richtlinien und einer Kultur, die darauf abzielt, Silos in der IT-Entwicklung, dem Betrieb, dem Netzwerk und der Sicherheit aufzubrechen. Die von John Willis, Damon Edwards und Jez Humble entwickelte Abkürzung CA(L)MSsteht für Culture (Kultur), Automation (Automatisierung), Lean (schlankes Management; siehe auch Continuous Delivery), Measurement (Messung) und Sharing (gemeinsame Nutzung) und ist ein nützliches Akronym, um sich an die wichtigsten Punkte der DevOps-Philosophie zu erinnern. Gemeinsame Nutzung und Zusammenarbeit stehen bei dieser Bewegung im Vordergrund. Bei einem DevOps-Ansatz verbesserst du etwas (oft durch Automatisierung), misst die Ergebnisse und teilst sie mit deinen Kollegen, damit sich das gesamte Unternehmen verbessern kann. Alle CALMS-Prinzipien werden durch eine unterstützende Kultur gefördert.

DevOps, Agile und eine Vielzahl anderer Techniken zur Umgestaltung von Unternehmen und Software sind allesamt Beispiele für eine allgemeine Weltanschauung darüber, wie man in der modernen Welt am besten wirtschaftet. Keines der Elemente der DevOps-Philosophie lässt sich leicht voneinander trennen, und das ist im Wesentlichen so gewollt. Es gibt jedoch ein paar Schlüsselideen, die relativ isoliert diskutiert werden können.

Keine Silos mehr

Die erste Schlüsselidee lautet: Keine Silos mehr. Dies ist eine Reaktion auf ein paar Ideen:

• Die historisch beliebte, aber zunehmend altmodische Anordnung von getrennten Betriebs- und Entwicklungsteams

• Die Tatsache, dass extreme Siloisierung von Wissen, Anreize für rein lokale Optimierung und mangelnde Zusammenarbeit in vielen Fällen aktiv schlecht für das Geschäft waren⁴

Unfälle sind normal

Der zweite Grundgedanke ist, dass Unfälle nicht nur auf die isolierten Handlungen eines Einzelnen zurückzuführen sind, sondern vielmehr auf fehlende Sicherheitsvorkehrungen für den Fall, dass etwas schief geht.⁵ Eine schlechte Schnittstelle zum Beispiel ermutigt unter Druck ungewollt zu falschen Handlungen; ein Systemfehler macht ein Versagen unausweichlich, wenn die (unausgesprochenen) falschen Umstände eintreten; eine fehlerhafte Überwachung macht es unmöglich zu wissen, ob etwas falsch ist, geschweige denn was falsch ist. Einige traditionellere Unternehmen haben den kulturellen Instinkt, den Fehlerverursacher ausfindig zu machen und ihn zu bestrafen. Aber das hat seine eigenen Konsequenzen: Es schafft Anreize, Probleme zu verwirren, die Wahrheit zu verbergen und anderen die Schuld zu geben - allesamt unrentable Ablenkungen. Deshalb ist es profitabler, sich darauf zu konzentrieren, die Genesung zu beschleunigen, als Unfälle zu verhindern.

Veränderung sollte schrittweise erfolgen

Der dritte Grundgedanke ist, dass Veränderungen am besten sind, wenn sie klein und häufig sind. In Umgebungen, in denen Änderungsausschüsse monatlich zusammentreffen um sorgfältig dokumentierte Pläne für Änderungen an der Mainframe-Konfiguration zu besprechen, ist dies eine radikale Idee. Diese Idee ist jedoch nicht neu. Die Vorstellung, dass alle Änderungen von erfahrenen Menschen geprüft und für eine effiziente Prüfung gebündelt werden müssen, ist mehr oder weniger das Gegenteil der bewährten Methode. Veränderungen sind riskant, das stimmt, aber die richtige Reaktion ist es, die Änderungen möglichst in kleinere Teilkomponenten aufzuteilen. Dann baust du aus dem regelmäßigen Output von Produkt-, Design- und Infrastrukturänderungen eine stetige Pipeline mit risikoarmen Änderungen auf.⁶ Diese Strategie, gepaart mit automatischen Tests kleinerer Änderungen und einem zuverlässigen Rollback schlechter Änderungen, führt zu Ansätzen des Änderungsmanagements wie Continuous Integration (CI) und Continuous Delivery oder Deployment (CD).

Werkzeuge und Kultur sind miteinander verbunden

Werkzeuge sind ein wichtiger Bestandteil von DevOps, vor allem, wenn man bedenkt, wie wichtig es ist, Veränderungen richtig zu managen - heutzutage ist das Veränderungsmanagement auf sehr spezifische Werkzeuge angewiesen. Insgesamt betonen die Befürworter von DevOps jedoch die Unternehmenskultur - und nicht die Werkzeuge - als Schlüssel zum Erfolg bei der Einführung einer neuen Arbeitsweise. Eine gute Kultur kann kaputte Werkzeuge umgehen, aber das Gegenteil ist selten der Fall. Wie das Sprichwort schon sagt, frisst die Kultur die Strategie zum Frühstück. Wie der Betrieb ist auch die Veränderung selbst schwierig.

Messung ist entscheidend

Und schließlich ist die Messung besonders wichtig, wenn es darum geht, Silos aufzubrechen und Vorfälle zu lösen. In jedem dieser Bereiche stellst du durch objektive Messungen die Realität fest, überprüfst, ob du die Situation so veränderst, wie du es erwartest, und schaffst eine objektive Grundlage für Gespräche, auf die sich verschiedene Funktionen einigen können. (Das gilt sowohl für geschäftliche als auch für andere Kontexte, wie z. B. den Bereitschaftsdienst).

Hintergrund zu SRE

Der Begriff Site Reliability Engineering (SRE) wurde von Ben Treynor Sloss, dem Vizepräsidenten für Technik bei Google, geprägt (und die damit verbundene Funktion).⁷ Wie wir im vorigen Abschnitt sehen können, ist DevOps ein breites Spektrum an Prinzipien für die Zusammenarbeit zwischen Betrieb und Produktentwicklung über den gesamten Lebenszyklus. SRE ist eine Jobrolle, eine Reihe von Praktiken (die im Folgenden beschrieben werden), die sich unserer Meinung nach bewährt haben, und einige Überzeugungen, die diese Praktiken beleben. Wenn du dir DevOps als eine Philosophie und Arbeitsweise vorstellst, kannst du argumentieren, dass SRE einen Teil der DevOps-Philosophie umsetzt und einer konkreten Definition eines Jobs oder einer Rolle etwas näher kommt als etwa "DevOps Engineer".⁸ In gewisser Weise implementiert die Klasse SRE also die Schnittstelle DevOps.

Im Gegensatz zur DevOps-Bewegung, die aus der Zusammenarbeit von Führungskräften und Praktikern in mehreren Unternehmen entstanden ist, hat SRE bei Google einen Großteil seiner Kultur vom umgebenden Unternehmen geerbt, bevor der Begriff SRE in der gesamten Branche populär wurde. Aufgrund dieser Entwicklung steht der Kulturwandel in der Disziplin als Ganzes derzeit nicht so sehr im Vordergrund wie bei DevOps. (Das sagt natürlich nichts darüber aus, ob ein kultureller Wandel notwendig ist, um SRE in einem beliebigen Unternehmen zu betreiben).

SRE wird durch die folgenden konkreten Prinzipien definiert.

Betrieb ist ein Software-Problem

Der Grundgedanke von SRE ist, dass ein guter Betrieb ein Softwareproblem ist. SRE sollte daher Softwareentwicklungsansätze nutzen, um dieses Problem zu lösen. Das ist ein weites Feld, das alles umfasst, von Prozess- und Geschäftsänderungen bis hin zu ähnlich komplizierten, aber traditionelleren Softwareproblemen, wie z. B. das Umschreiben eines Stacks, um Single Points of Failure in der Geschäftslogik zu beseitigen.

Verwalten nach Service Level Objectives (SLOs)

SRE versucht nicht, alles zu 100% verfügbar zu machen. Wie in unserem ersten Buch, Site Reliability Engineering, beschrieben, ist dies das falsche Ziel für eine Reihe von Gründen. Stattdessen wählen das Produktteam und das SRE-Team ein angemessenes Verfügbarkeitsziel für den Dienst und seine Nutzerbasis aus, und der Dienst wird nach diesem SLO verwaltet.⁹ Die Entscheidung für ein solches Ziel erfordert eine enge Zusammenarbeit mit dem Unternehmen. SLOs haben auch kulturelle Auswirkungen: Da es sich um Entscheidungen handelt, die von allen Beteiligten gemeinsam getroffen werden, führen SLO-Verletzungen dazu, dass die Teams wieder an das Reißbrett zurückkehren, ohne dass sie etwas dafür können.

Arbeiten, um die Arbeit zu minimieren

Für SRE ist jede manuelle, strukturell vorgeschriebene betriebliche Aufgabe verabscheuungswürdig. (Das heißt nicht, dass wir keine solchen Aufgaben haben: Wir haben viele von ihnen. Wir mögen sie nur nicht.) Wir sind der Meinung, dass eine Maschine, die einen gewünschten Vorgang ausführen kann, dies auch oft tun sollte. Das ist ein Unterschied (und ein Wert), den man in anderen Unternehmen nicht so oft sieht, wo die Arbeit die Aufgabe ist, für die man einen Menschen bezahlt. Für SRE im Google-Kontext ist die Arbeit nicht der Job - das kann sie nicht sein. Jede Zeit, die für betriebliche Aufgaben aufgewendet wird, bedeutet Zeit, die nicht für die Projektarbeit verwendet wird - und die Projektarbeit ist es, mit der wir unsere Dienste zuverlässiger und skalierbarer machen.

Das Ausführen von betrieblichen Aufgaben liefert jedoch durch die "Weisheit der Produktion" einen wichtigen Beitrag zu Entscheidungen. Diese Arbeit hält uns auf dem Boden der Tatsachen, indem sie uns Echtzeit-Feedback von einem bestimmten System liefert. Belastungsquellen müssen identifizierbar sein, damit du sie minimieren oder beseitigen kannst. Wenn du dich jedoch in einer Situation befindest, in der du unterlastet bist, musst du vielleicht häufiger neue Funktionen und Änderungen einführen, damit die Ingenieure mit der Funktionsweise des Dienstes, den du unterstützt, vertraut bleiben.

Die Weisheit der Produktion

Eine Anmerkung zur "Weisheit der Produktion": Mit diesem Ausdruck meinen wir die Weisheit, die du aus dem Betrieb eines Systems erhältst - die schmutzigen Details, wie es sich tatsächlich verhält und wie Software tatsächlich gestaltet werden sollte, und nicht eine von den Fakten isolierte Ansicht eines Dienstes auf einer Tafel. Alle Seiten, die du erhältst, die Tickets, die das Team bekommt, und so weiter, sind eine direkte Verbindung zur Realität, die zu einem besseren Systemdesign und -verhalten führen sollte.

Automatisiere die Aufträge für dieses Jahr

Die eigentliche Arbeit in diesem Bereich besteht darin, zu bestimmen, was unter welchen Bedingungen automatisiert werden soll und wie es automatisiert werden kann.

Bei SRE, wie es bei Google praktiziert wird, gibt es eine harte Grenze, wie viel Zeit ein Teammitglied für die Arbeit aufwenden kann, im Gegensatz zur Entwicklung, die einen dauerhaften Wert schafft: 50%. Viele denken, dass diese Grenze eine Obergrenze ist. In Wirklichkeit ist es viel sinnvoller, es als Garantie zu betrachten - eineausdrückliche Erklärung und ein Mechanismus, der es ermöglicht, Probleme ingenieurbasiert anzugehen, anstatt sich immer wieder mit ihnen abzumühen.

Es gibt eine unintuitive und interessante Wechselwirkung zwischen diesem Benchmark und den Auswirkungen, die er hat, wenn wir über Automatisierung und Arbeit nachdenken. Im Laufe der Zeit automatisiert ein SRE-Team alles, was es für einen Service tun kann, und lässt Dinge zurück, die nicht automatisiert werden können(Murphy-Beyer-Effekt). Wenn alles andere gleich bleibt, wird dies die Arbeit eines SRE-Teams dominieren, wenn nicht andere Maßnahmen ergriffen werden. In der Google-Umgebung neigt man dazu, entweder mehr Dienste hinzuzufügen, bis zu einer Grenze, die immer noch 50 % der Entwicklungszeit unterstützt, oder man ist mit seiner Automatisierung so erfolgreich, dass man stattdessen etwas ganz anderes machen kann.

Schnelles Handeln durch Verringerung der Fehlschlagskosten

Einer der Hauptvorteile des SRE-Engagements ist nicht unbedingt eine höhere Zuverlässigkeit, obwohl das natürlich auch der Fall ist, sondern eine verbesserte Produkt entwicklung. Warum? Nun, eine geringere mittlere Reparaturzeit (MTTR) für häufige Fehler führt zu einer schnelleren Produktentwicklung, da die Ingenieure keine Zeit und Konzentration auf die Behebung dieser Probleme verschwenden müssen. Dies ergibt sich aus der bekannten Tatsache, dass die Behebung eines Problems umso teurer ist, je später im Produktlebenszyklus es entdeckt wird. SREs haben die Aufgabe, die unerwünscht späte Problemerkennung zu verbessern, was dem gesamten Unternehmen zugute kommt.

Eigentum mit Entwicklern teilen

Starre Grenzen zwischen "Anwendungsentwicklung" und "Produktion" (manchmal auch Programmierer und Operatoren genannt) sind kontraproduktiv. Das gilt vor allem dann, wenn die Trennung der Zuständigkeiten und die Einstufung des Betriebs als Kostenstelle zu einem Machtungleichgewicht oder zu Diskrepanzen bei der Wertschätzung oder Bezahlung führt.

SREs konzentrieren sich in der Regel eher auf Produktionsprobleme als auf Probleme der Geschäftslogik, aber da ihr Ansatz Softwareentwicklungstools zur Lösung des Problems einsetzt, teilen sie ihre Fähigkeiten mit den Produktentwicklungsteams. Im Allgemeinen verfügt ein SRE über besondere Fachkenntnisse in den Bereichen Verfügbarkeit, Latenz, Leistung, Effizienz, Änderungsmanagement, Überwachung, Notfallreaktion und Kapazitätsplanung des/der von ihm/ihr betreuten Services. Diese spezifischen (und in der Regel klar definierten) Kompetenzen sind das A und O der Arbeit von SRE für ein Produkt und für das dazugehörige Produktentwicklungsteam.¹⁰ Idealerweise sollten sowohl die Produktentwicklungs- als auch die SRE-Teams einen ganzheitlichen Blick auf den Stack haben - Frontend, Backend, Bibliotheken, Speicherung, Kernel und physische Maschine - und kein Team sollte eifersüchtig einzelne Komponenten besitzen. Es hat sich herausgestellt, dass man viel mehr erreichen kann, wenn man die "Grenzen verwischt"¹¹ und SREs JavaScript instrumentieren oder Produktentwickler den Kernel qualifizieren lassen: Das Wissen, wie man Änderungen vornimmt, und die Befugnis, dies zu tun, sind viel breiter gestreut, und es gibt keine Anreize mehr, eine bestimmte Funktion eifersüchtig zu bewachen.

In Site Reliability Engineering haben wir nicht ausreichend deutlich gemacht, dass die Produktentwicklungsteams bei Google standardmäßig Eigentümer ihrer Dienste sind. SRE ist für den Großteil der Services weder verfügbar noch gewährleistet, obwohl die SRE-Prinzipien immer noch die Verwaltung der Services bei Google bestimmen.¹² Das Eigentumsmodell, wenn ein SRE-Team mit einem Produktentwicklungsteam zusammenarbeitet, ist letztendlich auch ein gemeinsames Modell.

Unabhängig von der Funktion oder der Berufsbezeichnung dieselben Werkzeuge verwenden

Das Tooling ist ein unglaublich wichtiger Faktor für das Verhalten, und es wäre naiv anzunehmen, dass die Wirksamkeit von SRE im Kontext von Google nichts mit der weithin zugänglichen , einheitlichen Codebasis, der breiten Palette an Software- und Systemtools, dem hoch optimierten und proprietären Produktionsstack usw. zu tun hat. Dennoch teilen wir diese absolute Annahme mit DevOps: Teams, die einen Dienst betreuen¹³ sollten unabhängig von ihrer Rolle in der Organisation die gleichen Tools verwenden. Es gibt keinen guten Weg, einen Service zu verwalten, bei dem ein Tool für die SREs und ein anderes für die Produktentwickler verwendet wird, die sich in verschiedenen Situationen unterschiedlich (und möglicherweise katastrophal) verhalten. Je mehr Unterschiede es gibt, desto weniger profitiert dein Unternehmen von den Bemühungen, jedes einzelne Tool zu verbessern.

Vergleich und Gegenüberstellung

Wenn wir uns die vorangegangenen Grundsätze ansehen, erkennen wir sofort eine Menge Gemeinsamkeiten in den Punkten skizzierten:

• DevOps und SRE setzen beide voraus, dass man akzeptiert, dass Veränderungen notwendig sind, um sich zu verbessern. Ohne das gibt es nicht viel Spielraum.¹⁴

• Die Zusammenarbeit steht bei der DevOps-Arbeit im Vordergrund. Ein effektives Modell der gemeinsamen Verantwortung und Beziehungen zwischen Partnerteams sind notwendig, damit SRE funktioniert. Wie bei DevOps gibt es auch bei SRE starke Werte, die in der gesamten Organisation geteilt werden, was das Überwinden von teambasierten Silos etwas einfacher machen kann.

• Änderungsmanagement wird am besten in Form von kleinen, kontinuierlichen Maßnahmen betrieben, von denen die meisten idealerweise sowohl automatisch getestet als auch angewendet werden. Die kritische Wechselwirkung zwischen Veränderung und Zuverlässigkeit macht dies für SRE besonders wichtig.

• Die richtigen Werkzeuge sind von entscheidender Bedeutung, und die Werkzeuge bestimmen bis zu einem gewissen Grad den Umfang deiner Handlungen. Dennoch dürfen wir uns nicht zu sehr darauf konzentrieren, ob etwas mit einem bestimmten Satz von Werkzeugen erreicht wird. Am Ende des Tages ist die API-Orientierung für die Systemverwaltung eine wichtigere Philosophie, die jede bestimmte Umsetzung überdauern wird.

• Die Messung ist der Schlüssel für die Arbeit von DevOps und SRE. Bei SRE sind SLOs entscheidend für die Maßnahmen, die zur Verbesserung des Dienstes ergriffen werden. Natürlich gibt es keine SLOs ohne Messungen (und ohne teamübergreifende Diskussionen - idealerweise zwischen Produkt, Infrastruktur/SRE und dem Unternehmen). Bei DevOps wird die Messung oft genutzt, um die Ergebnisse eines Prozesses, die Dauer von Feedbackschleifen usw. zu verstehen. Sowohl DevOps als auch SRE sind datenorientiert, egal ob es sich um Berufe oder Philosophien handelt.

• Die nüchterne Realität des Managements von Produktionsdiensten bedeutet, dass gelegentlich schlimme Dinge passieren, über deren Gründe man dann sprechen muss. Sowohl SRE als auch DevOps praktizieren eine tadellose Nachbetrachtung, um nicht hilfreiche, adrenalingeladene Reaktionen zu vermeiden.

• Letztlich ist die Implementierung von DevOps oder SRE ein ganzheitlicher Akt; beide hoffen, das gesamte Team (oder die Einheit oder die Organisation) durch eine ganz bestimmte Art der Zusammenarbeit zu verbessern. Sowohl bei DevOps als auch bei SRE sollte eine höhere Geschwindigkeit das Ergebnis sein.¹⁵

Wie du sehen kannst, gibt es viele Gemeinsamkeiten zwischen DevOps und SRE.

Doch es gibt auch erhebliche Unterschiede. DevOps ist in gewisser Weise eine umfassendere Philosophie und Kultur. Da DevOps umfassendere Veränderungen bewirkt als SRE, ist es kontextabhängiger. DevOps sagt relativ wenig darüber aus, wie der Betrieb auf einer detaillierten Ebene ablaufen soll. Es macht zum Beispiel keine Vorschriften über die genaue Verwaltung von Diensten. Stattdessen konzentriert sich DevOps darauf, Barrieren in der gesamten Organisation abzubauen. Das ist von großem Wert.

SRE hingegen hat relativ eng definierte Zuständigkeiten und ist in der Regel eher service- (und endnutzer-) als unternehmensweit ausgerichtet. Das hat zur Folge, dass SRE einen bestimmten intellektuellen Rahmen (einschließlich Konzepten wie Fehlerbudgets) für das Problem des effektiven Systembetriebs bietet. Obwohl sich SRE als Berufsgruppe der Anreize und ihrer Auswirkungen sehr bewusst ist, schweigt sie sich über Themen wie Siloisierung und Informationsbarrieren relativ aus. SRE würde CI und CD nicht unbedingt wegen des Business Case unterstützen, sondern wegen der damit verbundenen verbesserten betrieblichen Praktiken. Oder anders ausgedrückt: SRE glaubt an die gleichen Dinge wie DevOps, aber aus etwas anderen Gründen.

Organisatorischer Kontext und Förderung der erfolgreichen Einführung

DevOps und SRE haben eine sehr große konzeptionelle Überschneidung in ihrer Arbeitsweise. Wie zu erwarten, gibt es auch eine Reihe ähnlicher Bedingungen die im Unternehmen erfüllt sein müssen, damit sie a) überhaupt implementiert werden können und b) den maximalen Nutzen aus dieser Implementierung ziehen. Wie Tolstoi fast, aber nie ganz gesagt hat, sind alle effektiven Ansätze gleich, während alle kaputten Ansätze auf ihre eigene Weise kaputt sind. Anreize können zum Teil erklären, warum das so ist.

Wenn die Unternehmenskultur die Vorteile eines DevOps-Ansatzes zu schätzen weiß und bereit ist, diese Kosten zu tragen - die sich typischerweise in Schwierigkeiten bei der Einstellung, in der Energie, die für die Aufrechterhaltung der Fluktuation von Teams und Zuständigkeiten erforderlich ist, und in erhöhten finanziellen Ressourcen für die Kompensation einer zwangsläufig selteneren Qualifikation äußern -, dann muss das Unternehmen auch sicherstellen, dass die Anreize richtig gesetzt werden, um den vollen Nutzen dieses Ansatzes zu erzielen.

Im Einzelnen sollte das Folgende sowohl für DevOps als auch für SRE gelten.

Enge, starre Anreize schränken deinen Erfolg ein

Viele Unternehmen legen versehentlich formale Anreize fest, die die kollektive Leistung untergraben. Um diesen Fehler zu vermeiden, solltest du die Anreize nicht so gestalten, dass sie eng an Ergebnisse gebunden sind, die mit dem Start oder der Zuverlässigkeit zu tun haben. Wie dir jeder Wirtschaftswissenschaftler bestätigen kann, werden die Menschen einen Weg finden, um die Ergebnisse zu manipulieren - manchmal sogar auf eine gut gemeinte Art und Weise.¹⁶ Stattdessen solltest du deinen Mitarbeitern die Freiheit lassen, die richtigen Kompromisse zu finden. Wie bereits erwähnt, können DevOps oder SRE als Beschleuniger für dein Produktteam im Allgemeinen fungieren und es dem Rest der Software-Organisation ermöglichen, Funktionen kontinuierlich und zuverlässig an die Kunden zu liefern. Eine solche Dynamik behebt auch ein hartnäckiges Problem des traditionellen und divergierenden Ansatzes der System-/Softwaregruppe: das Fehlen einer Feedbackschleife zwischen Design und Produktion. Ein System, bei dem SRE schon früh (idealerweise zum Zeitpunkt der Entwicklung) einbezogen wird, funktioniert in der Regel nach der Bereitstellung besser in der Produktion, unabhängig davon, wer für die Verwaltung des Dienstes verantwortlich ist. (Nichts verlangsamt die Entwicklung von Funktionen so sehr wie der Verlust von Nutzerdaten.)

Es ist besser, es selbst zu reparieren; gib nicht jemand anderem die Schuld

Außerdem solltest du Anreize vermeiden, die Schuld für Produktionsvorfälle oder Systemausfälle auf andere Gruppen abzuwälzen. In vielerlei Hinsicht ist die Dynamik der Schuldabwälzung das Kernproblem des traditionellen Modells für den technischen Betrieb, da die Trennung von Betriebs- und Softwareteams unterschiedliche Anreize entstehen lässt. Überlege dir stattdessen, ob du die folgenden Praktiken anwenden willst, um die Schuldabwälzung auf Organisationsebene zu bekämpfen:

• Erlaube den Ingenieuren nicht nur, sondern ermutige sie aktiv, Code und Konfiguration zu ändern, wenn es für das Produkt erforderlich ist. Erlaube diesen Teams auch, innerhalb der Grenzen ihres Auftrags radikal zu sein, um so Anreize zu beseitigen, langsamer vorzugehen.

• Unterstütze tadellose Obduktionen.¹⁷ So gibt es keine Anreize, ein Problem herunterzuspielen oder zu vertuschen. Dieser Schritt ist entscheidend, um das Produkt vollständig zu verstehen und seine Leistung und Funktionalität tatsächlich zu optimieren, und beruht auf der bereits erwähnten Weisheit der Produktion.

Erlaube dem Support, sich von Produkten zu entfernen, die unrettbar schwierig zu bedienen sind. Die Drohung, den Support zurückzuziehen, motiviert die Produktentwicklung, Probleme zu beheben, sowohl im Vorfeld als auch nach der Unterstützung des Produkts, was allen Beteiligten Zeit spart. Was unter "unlösbar schwierig" zu verstehen ist, kann je nach Kontext unterschiedlich sein - die Dynamik sollte von gegenseitigem Verständnis der Verantwortlichkeiten geprägt sein. Die Rückmeldung an andere Unternehmen kann ein leiseres "Wir denken, dass die Zeit von Leuten mit diesen Fähigkeiten besser genutzt werden kann" sein, oder es kann auch heißen: "Diese Leute werden kündigen, wenn sie mit zu viel operativer Arbeit betraut werden und nicht die Möglichkeit haben, ihre technischen Fähigkeiten zu nutzen". Bei Google ist die Praxis, solchen Produkten die Unterstützung zu entziehen, inzwischen zur Institution geworden.

Betrachte die Zuverlässigkeitsarbeit als eine spezialisierte Rolle

Bei Google sind SRE und Produktentwicklung getrennte Organisationen. Jede Gruppe hat ihren eigenen Schwerpunkt, ihre eigenen Prioritäten und ihr eigenes Management und muss sich nicht nach den Vorgaben der anderen richten. Allerdings finanzieren die Produktentwicklungsteams das Wachstum von SRE mit Neueinstellungen, wenn ein Produkt erfolgreich ist. Auf diese Weise hat die Produktentwicklung einen Anteil am Erfolg der SRE-Teams, genauso wie die SREs einen Anteil am Erfolg der Produktentwicklungsteams haben. SRE hat außerdem das Glück, dass sie von der Unternehmensleitung auf höchster Ebene unterstützt wird, was dafür sorgt, dass die Einwände der Ingenieurteams gegen die Unterstützung von Services "auf SRE-Art" in der Regel kurzlebig sind. Man braucht kein Organigramm, um die Dinge anders zu machen - man braucht nur eine andere Community of Practice, um sich zu entwickeln.

Unabhängig davon, ob du dein Organigramm aufgabelst oder eher informelle Mechanismen verwendest, ist es wichtig zu erkennen, dass Spezialisierung Herausforderungen mit sich bringt. DevOps- und SRE-Praktiker profitieren von einer Gemeinschaft von Gleichgesinnten, die sie unterstützen und fördern, sowie von Aufträgen, die sie für ihre¹⁸ für die einzigartigen Fähigkeiten und Perspektiven, die sie mitbringen, belohnen.

Es ist wichtig zu wissen, dass die Organisationsstruktur von Google und einige der oben erwähnten Anreize von einer großen Organisation abhängen. Wenn dein 20-Personen-Startup zum Beispiel nur ein (vergleichsweise kleines) Produkt hat, macht es nicht viel Sinn, den Rückzug der operativen Unterstützung zuzulassen. Es ist immer noch möglich, einen DevOps-ähnlichen Ansatz zu verfolgen,¹⁹ aber die Möglichkeit, ein operativ schlechtes Produkt zu verbessern, wird untergraben, wenn du ihm buchstäblich nur noch beim Wachstum helfen kannst. In der Regel hat man jedoch mehr Möglichkeiten, als man denkt, wenn es darum geht, die Wachstumsbedürfnisse zu befriedigen und die Geschwindigkeit, mit der sich technische Schulden anhäufen, zu reduzieren.²⁰

Wann kann stellvertretend für Ob

Wenn deine Organisation oder dein Produkt jedoch eine bestimmte Größe überschreitet, kannst du mehr Spielraum bei der Auswahl der zu unterstützenden Produkte oder der Festlegung der Prioritäten für diese Unterstützung nutzen. Wenn klar ist, dass System X viel früher unterstützt werden soll als System Y, kann die implizite Konditionalität eine ähnliche Rolle spielen wie die Entscheidung, in der SRE-Welt keine Services zu unterstützen.

Bei Google hat sich die starke Partnerschaft von SRE mit der Produktentwicklung als äußerst wichtig erwiesen: Wenn eine solche Beziehung in deinem Unternehmen besteht, kann die Entscheidung, Unterstützung zu entziehen (oder bereitzustellen), auf objektiven Daten über vergleichbare betriebliche Merkmale beruhen, wodurch ansonsten unproduktive Gespräche vermieden werden können.

Eine produktive Beziehung zwischen SRE und der Produktentwicklung hilft auch dabei, das organisatorische Anti-Muster zu vermeiden, bei dem ein Produktentwicklungsteam ein Produkt oder eine Funktion ausliefern muss, bevor es ganz fertig ist. Stattdessen kann SRE mit dem Entwicklungsteam zusammenarbeiten, um das Produkt zu verbessern, bevor die Last der Wartung von denjenigen abgewälzt wird, die das meiste Fachwissen haben, um es zu reparieren.

Strebe nach Gleichheit der Wertschätzung: Karriere und Finanzen

Stelle schließlich sicher, dass die Karriereanreize das Richtige zu tun: Wir wollen, dass unsere DevOps/SRE-Organisation die gleiche Wertschätzung erfährt wie ihre Pendants in der Produktentwicklung. Deshalb sollten die Mitglieder beider Teams nach ungefähr den gleichen Methoden bewertet werden und die gleichen finanziellen Anreize haben.

Fazit

In vielerlei Hinsicht liegen DevOps und SRE sowohl in der Praxis als auch in der Philosophie in der Gesamtlandschaft des IT-Betriebs sehr nahe beieinander.

Sowohl DevOps als auch SRE erfordern Diskussionen, die Unterstützung des Managements und die Zustimmung derjenigen, die die Arbeit tatsächlich machen, um ernsthafte Fortschritte zu erzielen. Die Umsetzung von DevOps und SRE ist eine Reise und keine schnelle Lösung: Die Praxis der Umbenennung und Beschämung²¹ ist ein hohles Mittel, das wahrscheinlich keinen Nutzen bringt. Da es sich um eine eher meinungsbetonte Umsetzung von Betriebsabläufen handelt, bietet SRE konkretere Vorschläge, wie du deine Arbeitspraktiken bereits zu einem früheren Zeitpunkt auf dieser Reise ändern kannst, auch wenn dies eine spezifische Anpassung erfordert. Da DevOps einen breiteren Fokus hat, ist es etwas schwieriger, darüber nachzudenken und es in konkrete Schritte umzusetzen, aber gerade wegen dieses breiteren Fokus ist es wahrscheinlich, dass der anfängliche Widerstand geringer ist.

Aber alle nutzen die gleichen Werkzeuge, die gleichen Ansätze für das Veränderungsmanagement und die gleiche datenbasierte Entscheidungsfindung. Letztendlich stehen wir alle vor demselben Problem: Produktion und deren Verbesserung - egal, wie wir heißen.

Für diejenigen, die an weiterer Lektüre interessiert sind, sollten die folgenden Vorschläge helfen, ein breiteres Verständnis für die kulturellen, geschäftlichen und technischen Grundlagen der betrieblichen Revolution zu entwickeln, die gerade stattfindet:

• Site Reliability Engineering

• Effektive DevOps

• Das Phoenix-Projekt

• Die Praxis der Cloud-Systemadministration: DevOps und SRE-Praktiken für Web Services, Band 2

• Accelerate: Die Wissenschaft von schlanker Software und DevOps

¹ Da diese Diskussion in einem Buch über SRE erscheint, bezieht sich ein Teil der Ausführungen auf den Betrieb von Software-Services und nicht auf den IT-Betrieb.

² Mary Poppendieck hat dazu einen hervorragenden Artikel mit dem Titel "Die Kostenstellenfalle". Eine andere Möglichkeit, wie dieser Ansatz fehlschlägt, ist, wenn eine sehr große und unwahrscheinliche Katastrophe die Kosteneinsparungen, die du durch die Umstellung auf ein Low-Grade-Betriebsmodell erzielt hast, komplett zunichte macht (z. B. der Ausfall von British Airways im Mai 2017).

³ Natürlich gibt es eine Reihe anderer möglicher Reaktionen. ITIL® ist zum Beispiel ein weiterer Ansatz für das IT-Management, der sich für eine bessere Standardisierung einsetzt.

⁴ Da es sich um eine komplizierte Welt handelt, haben Partitionierung, Silos und Ähnliches auch positive Auswirkungen, aber die Nachteile scheinen im Bereich der Operationen besonders schädlich zu sein.

⁵ Siehe https://en.wikipedia.org/wiki/Normal_Accidents.

⁶ Änderungen mit höherem Risiko oder solche, die nicht automatisch validiert werden können, sollten natürlich trotzdem von Menschen überprüft werden, wenn sie nicht sogar von ihnen durchgeführt werden.

⁷ Die Geschichte von SRE bei Google ist, dass es aus einem Vorläuferteam hervorging, das eher operativ ausgerichtet war, und Ben gab den Anstoß, das Problem von einem technischen Standpunkt aus zu behandeln.

⁸ Diese Bezeichnung ist in vielerlei Hinsicht falsch. Die vielleicht grundlegendste ist, dass du nicht einfach ein paar Leute einstellen, sie "DevOps-Ingenieure" nennen und sofort Vorteile erwarten kannst. Um davon zu profitieren, musst du dich auf die ganze Philosophie einlassen und deine Arbeitsweise ändern. Wie Andrew Clay Shafer sagt: "DevOps wird verkauft, aber man kann es nicht kaufen". Und wie Seth Vargo in "The 10 Myths of DevOps" betont, kannst du keinen "DevOp anheuern, um dein Unternehmen zu reparieren".

⁹ Ein Service Level Objective ist ein Ziel für die Leistung einer bestimmten Kennzahl (z. B. 99,9 % der Zeit verfügbar).

¹⁰ Natürlich macht nicht jedes Team alles, aber das sind die häufigsten Bereiche, in denen SRE arbeitet.

¹¹ Führe eine Verletzung der Schichtung durch, wenn du dir das als geschichteten Stapel vorstellst.

¹² In der Tat gibt es einen Production Readiness Review für das Onboarding von allem; SRE wird nicht einfach Dienste aus dem Stand heraus onboarden.

¹³ Ein Dienst ist frei definiert als Software, die für die Erfüllung von Geschäftsanforderungen eingesetzt wird, in der Regel mit Verfügbarkeitsbeschränkungen.

¹⁴ Innerhalb von Google ist diese Frage weitgehend geklärt, und die Dienste ändern ständig ihren Zustand, ihre Konfiguration, ihre Eigentümerschaft, ihre Ausrichtung und so weiter. Bis zu einem gewissen Grad ist SRE bei Google der Nutznießer des Arguments "Veränderung ist notwendig", das in der Vergangenheit schon einige Male ausgefochten und gewonnen wurde. Aber nicht ganz gleichmäßig verteilt, wie William Gibson sagen würde.

¹⁵ Siehe die einschlägigen Untersuchungen unter https://devops-research.com/research.html.

¹⁶ Siehe http://en.wikipedia.org/wiki/Goodhart%27s_law und https://skybrary.aero/bookshelf/books/2336.pdf.

¹⁷ Siehe z. B. https://codeascraft.com/2012/05/22/blameless-postmortems/.

¹⁸ In Unternehmen, die eine gut entwickelte Kultur haben. Unternehmen, die sich noch in der Anfangsphase befinden, haben wahrscheinlich keine etablierten Möglichkeiten, diese Aufgaben zu belohnen.

¹⁹ In der Tat ist das wohl deine einzige Möglichkeit, es sei denn, du lagerst den Betrieb aus.

²⁰ Wie die SRE-Prinzipien in verschiedenen Kontexten angewendet werden können, wird in Kapitel 20 erläutert.

²¹ Mit anderen Worten: Eine Gruppe einfach in DevOps oder SRE umzubenennen, ohne dass sich ihre organisatorische Positionierung ändert, führt zwangsläufig dazu, dass das Team beschämt wird, wenn die versprochenen Verbesserungen nicht eintreten.