SRE werden

Kapitel 1. Das Wichtigste zuerst

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

Willkommen im Buch! Lass uns erst einmal klären, was Site Reliability Engineering (SRE) ist und woher es kommt.

Was ist SRE?

gibt es eine Reihe von Definitionen für die Zuverlässigkeit von Standorten. Hier ist die beste, die ich im Laufe der Jahre finden konnte:

Site Reliability Engineering ist eine Ingenieursdisziplin, die Organisationen dabei hilft, dauerhaft ein angemessenes Maß an Zuverlässigkeit für ihre Systeme, Dienstleistungen und Produkte zu erreichen.

Wenn ich diese Definition einem Publikum vorstelle, sage ich normalerweise, dass es mindestens drei Wörter in dieser Definition gibt, deren Vorhandensein, wenn man sie richtig versteht, zu einem guten Verständnis von SRE führt. Wenn ich die Gelegenheit dazu habe, frage ich die Zuhörer: "Welche drei Wörter sind eurer Meinung nach die wichtigsten in dieser Definition?" Lies dir die obige Definition noch einmal durch und beantworte diese Frage für dich selbst, bevor du weiterliest.

Ich stelle diese Frage nicht nur, weil ich die Interaktion mit dem Publikum mag, sondern auch, weil sie einen diagnostischen Einblick in die Crowd selbst bietet. In Kapitel 4 werde ich näher darauf eingehen, was du aus dieser Diagnose lernen kannst. Aber in der Zwischenzeit wollen wir uns die drei Wörter ansehen, die ich als erstes wählen würde, wenn ich diese Frage gestellt bekäme.

Verlässlichkeit

Die erste Vermutung ist ziemlich einfach, oder? Zuverlässigkeit ist bei allem, was wir bei SRE tun, von zentraler Bedeutung (ja, sie steckt sogar im Namen). Eine Möglichkeit, die Bedeutung der Zuverlässigkeit zu betonen, ist die Feststellung, dass ein Unternehmen Millionen in lokaler Währung ausgeben kann, um die beste Software mit den raffiniertesten Funktionen zu entwickeln, ein großartiges Vertriebsteam einzustellen, um sie zu verkaufen, ein hervorragendes Team von Supportmitarbeitern zu beschäftigen, um sie zu unterstützen usw., aber wenn die Software nicht funktioniert, wenn ein Kunde versucht, sie zu nutzen, landet all das Geld und der Aufwand im Müll (oder in der Toilette, je nachdem, welche Metapher dir besser gefällt).

Wenn du Probleme mit der Zuverlässigkeit hast, kann dein Unternehmen einen Verlust erleiden:

Einnahmen

Das gilt vor allem dann, wenn das ausgefallene System für das Geldverdienen entscheidend ist.

Zeit

Die Beschäftigten haben es mit einem Ausfall zu tun statt mit geplanter Arbeit.

Reputation

Die Leute wollen keinen Dienst nutzen, den sie für unzuverlässig halten, und werden gerne zu einem Konkurrenten wechseln.

Gesundheit

Wenn es in deiner Umgebung ständig brennt, wenn Bereitschaftsdienstleistende regelmäßig geweckt werden, wenn deine Mitarbeiter/innen ihre Zeit immer mit der Arbeit statt mit ihren Freunden oder ihrer Familie verbringen müssen, kann das ernsthafte Auswirkungen auf die Gesundheit haben.

Einstellen

Die Menschen in dieser Branche reden miteinander. Wenn sich herumspricht, dass dein Arbeitsplatz ein einziges "Reifenfeuer" ist, wird es sehr schwierig sein, neue Leute einzustellen.

Angemessen

Ich glaube, ein zentraler Gedanke, den SRE entweder eingeführt oder in der Betriebsdiskussion hervorgehoben hat, ist der Gedanke, dass 100%ige Zuverlässigkeit nur in den seltensten Fällen ein wünschenswertes oder gar mögliches Ziel ist. In vielen Fällen ist das nicht möglich, weil in dieser vernetzten Welt die Wahrscheinlichkeit sehr hoch ist, dass deine Abhängigkeiten nicht 100%ig zuverlässig sind. Manchmal kann man durch geschickte Planung und Programmierung erreichen, dass man zuverlässiger ist als seine Abhängigkeiten, aber nicht immer.

SRE konzentriert sich stattdessen auf Praktiken wie Service Level Indicators/Service Level Objectives (SLIs/SLOs),¹ die dir helfen, ein angemessenes Maß an Zuverlässigkeit in deinen Systemen zu bestimmen, zu kommunizieren und darauf hinzuarbeiten.

Nachhaltig

Dieses Wort kam erst später in die Definition, als klar wurde, dass eine betriebliche Praxis nur dann erfolgreich sein kann, wenn sie nachhaltig ist. Nachhaltigkeit erinnert an das Problem des "Gesundheitsverlustes" bei der Zuverlässigkeit. Zuverlässige Systeme werden von Menschen gebaut. Wenn die Menschen in deinem Unternehmen ausgebrannt und erschöpft sind, keine Kontakte zu Menschen in ihrem Leben außerhalb der Arbeit haben und sich nicht um sich selbst kümmern können, sind sie nicht in der Lage, verlässliche Systeme aufzubauen. Viele Menschen lernen das auf die harte Tour; bitte sei nicht einer von ihnen, wenn du es vermeiden kannst.

(Andere Worte)

Es gibt noch ein paar andere Wörter aus dieser Definition, die ich hier nur erwähnen möchte, um einen Vorgeschmack auf unsere Diskussion in Kapitel 4 zu geben: Technik, Disziplin, Hilfe und Organisation. Wir sehen uns bald in diesem Kapitel!

Entstehungsgeschichte

Ich glaube zwar, dass es nützlich ist, den Ursprung von SRE zu kennen und zu wissen, wie es bei Google entstanden ist (ungefähr im Jahr 2003), aber das ist nicht die Geschichte, die ich erzählen möchte. Ben Treynor Sloss, der Begründer von SRE, liefert seine offizielle Version in Site Reliability Engineering (auch als SRE-Buch bezeichnet), herausgegeben von Betsy Beyer et al. (O'Reilly, 2016).

Stattdessen möchte ich dir erzählen, wie ich zum ersten Mal anfing, das Thema wirklich zu verstehen, weil es auch dir helfen könnte. Es hat mit der Google-Ursprungsgeschichte zu tun, denn es war der Zeitpunkt, an dem Treynor Sloss sein Verständnis von SRE auf der ersten öffentlichen Versammlung zu diesem Thema erläuterte. Ich glaube fest daran, dass die Geschichten, die wir uns selbst erzählen, entscheidend für das Verständnis unserer Identität sind, also war das ein ziemlich großer Moment.

Am 31. Mai 2014 sah ich in Santa Clara, Kalifornien, wie Treynor Sloss auf der allerersten SREcon die Keynote "Keys to SRE" hielt.² Ich empfehle dir, ihn dir auch anzusehen.

In diesem Vortrag zeigte er eine einzige Folie, die mein Verständnis von SRE auf den Kopf gestellt hat. Abbildung 1-1 zeigt einen Schnappschuss der Folie.

Abbildung 1-1. Eine Folie aus Ben Treynor Sloss' Grundsatzrede auf der SREcon14, verwendet mit Genehmigung

Abbildung 1-1 ist die Liste, mit der ich angefangen habe, und sie ist immer noch ein guter Startpunkt für alle.

Wenn ich jetzt, neun Jahre später, auf diese Folie zurückblicke, fällt mir auf, wie viele dieser Punkte sich im Laufe der Zeit bewährt haben und welche Dinge anscheinend von dem Google-Kontext abhängen, in dem sie entstanden sind. Seitdem dieser Vortrag gehalten wurde, hat sich einiges getan (man könnte sagen, mindestens drei Bücher; siehe die SRE-Ressourcen in Anhang C), was vielleicht ein guter Grund ist, warum du dieses Buch auch liest.

SRE und seine Beziehung zu DevOps

Wenn ich mit Leuten spreche, die sich mit Site Reliability Engineering auseinandersetzen wollen, kann ich fast garantieren, dass die Diskussion irgendwann auf Fragen wie diese hinausläuft: Wie lassen sich DevOps und SRE vergleichen? Wie ist die Beziehung zwischen ihnen? Und wäre es sinnvoll, beides im selben Unternehmen zu haben? Das sind keine trivialen Fragen, auf die ich seit Jahren versuche, zufriedenstellende Antworten zu finden. Deshalb habe ich mich entschlossen, Kapitel 12 von Seeking SRE zu diesem Thema per Crowdsourcing zu veröffentlichen. Zu diesem Zeitpunkt hatte ich keine gute Antwort und ich hoffte, dass jemand anderes sie finden würde.³

Mit Hilfe der Antworten aus diesem Kapitel und einiger Nachforschungen kam ich schließlich zu einer Antwort, die mir gefiel. Als ich erkannte, dass es mehr als einen Ansatz braucht, um diese Fragen wirklich zu beantworten, konnte ich eine mehrteilige Erklärung konstruieren, die für mich funktioniert. Ich hoffe, das gilt auch für dich. Erlaube mir, alle drei Teile mit einem kleinen Kommentar zu erläutern.

Teil 1: SRE implementiert Klasse DevOps

Dies stammt aus Kapitel 1 von The Site Reliability Workbook (O'Reilly, 2018) und einer nachfolgenden Nachricht von Google. Für die Nicht-Programmierer, die dies lesen, soll es heißen, dass SRE eine Umsetzung⁴ der allgemeinen DevOps-Philosophie ist. Das ist aus mehreren Gründen nicht mein Lieblingsvergleich:

• Nicht-Programmierer können die Formulierungen oder Nuancen darin nicht ganz verstehen.

• Ich glaube nicht, dass ich eine andere DevOps-Implementierung als die "Standard"-Implementierung kenne, die sich im Laufe der Zeit und in der Praxis in freier Wildbahn entwickelt hat.

• Das impliziert eine historische Verbindung zu den Ursprüngen von SRE (oder zumindest eine doppelte Entdeckung), für die ich noch keine Beweise gesehen habe.

• Ich bin mir immer noch nicht sicher, ob ich es kaufe.

Der Grund, warum ich diese Idee über SRE und DevOps immer wieder aufgreife (abgesehen davon, dass sie von Leuten stammt, die schlauer sind als ich), ist, dass sie die Ähnlichkeiten oder zumindest die Resonanzfrequenzen zwischen den beiden modernen Betriebsverfahren aufzeigt.

Teil 2: SRE ist für die Zuverlässigkeit das, was DevOps für die Lieferung ist

Ich weiß nicht, wie es dir geht, aber von Zeit zu Zeit habe ich eine Glaubenskrise in Bezug auf DevOps. Dieses Mal ist mir aufgefallen, dass ich keine Beschreibung von DevOps oder DevOps-Praktiken finden konnte, mit der ich es sofort von anderen betrieblichen Praktiken in der Welt unterscheiden konnte. Ich wollte Wörter, die es sofort von allem anderen unterscheiden, so dass ich es eindeutig aus einer Reihe herauspicken konnte ("#3, das ist DevOps! Ich erkenne es überall!"). Ich habe alle meine Quellen und meine handverlesene Sammlung von DevOps-Akronymen durchgesehen, aber ich hatte immer noch keinen Erfolg.

Für SRE könnte ich sagen: "Bei SRE geht es um Zuverlässigkeit". Wenn jemand fragen würde: "Welches ist die betriebliche Praxis, die sich auf die Zuverlässigkeit konzentriert? Das brachte mich dazu, die DevOps-Koryphäen zu fragen: "Wenn es bei SRE um Zuverlässigkeit geht, was ist dann das eine Wort für DevOps?"

Ich ging von Koryphäe zu Koryphäe (die alle sehr nett waren) und trug meine Laterne, bis ich schließlich eine Antwort von Donovan Brown erhielt, die sich gut anfühlte. Für ihn drehte sich bei DevOps alles um die Lieferung. Den Kunden einen Mehrwert zu liefern, Software auszuliefern, usw. Endlich hatte ich das Wort, nach dem ich gesucht hatte.

SRE ist für die Zuverlässigkeit, was DevOps für die Bereitstellung ist.

Damit kann ich leben.

Teil 3: Es kommt auf die Richtung der Aufmerksamkeit an

Dieses letzte Puzzleteil stammt von meinem Freund Tom Limoncelli, der so freundlich war, dies als Antwort auf meinen Aufruf zur Einreichung von Beiträgen für das bereits erwähnte Seeking SRE Crowdsourced Chapter einzureichen. Abbildung 1-2 ist ein Bild aus diesem Kapitel (auf seinen Wunsch hin vom Original abgeändert).

Abbildung 1-2. Das Limoncelli-Modell der SRE-, DevOps- und Agile-Strategien. Abgeändert vom Original in Seeking SRE (O'Reilly, 2018).

In gewisser Weise gefällt mir dieses Modell am besten, weil es eine Reihe von Überschneidungen in der Praxis zwischen DevOps und SRE erklärt, die sich in der Einstellung oder Absicht nicht zu überschneiden scheinen. Ich werde gleich Beispiele dafür geben, aber hier ist meine beste Zusammenfassung von Toms Theorie:

1. Die DevOps-Geschichte beginnt mit einem Entwickler, der Code in einen Laptop eintippt. DevOps kümmert sich (unter anderem) darum, wie dieser Code in die Produktion gebracht werden kann, damit die Kunden den größten Nutzen daraus ziehen können. Die Aufmerksamkeit richtet sich vom Laptop auf die Produktion.⁵ Man könnte vermuten, dass dies ein Grund dafür ist, warum Systeme für kontinuierliche Integration und kontinuierliche Lieferung (CI/CD) einen so großen Stellenwert in der DevOps-Werkzeugkiste, in den Fähigkeiten und in den Stellenanzeigen haben.

2. SRE beginnt an einem anderen Ort. Es beginnt (und der SRE-Gedankenraum befindet sich tatsächlich) in der Produktion. Was muss ein SRE tun, um eine zuverlässige Produktionsumgebung zu schaffen? Die Beantwortung dieser Frage erfordert einen Blick, der von der Produktion aus "rückwärts" schaut und diese Frage Schritt für Schritt stellt, bis der Laptop des Entwicklers erreicht ist.

3. Die Richtung der Aufmerksamkeit ist unterschiedlich. Vielleicht werden dieselben Tools verwendet (z. B. eine CI/CD-Pipeline), aber aus einem anderen Grund. DevOps und SRE werden sich beide intensiv mit der Entwicklung eines Überwachungssystems befassen, aber aus einem anderen Grund.⁶

Und das führt uns zu der Antwort auf die obige Frage: Können/sollten SRE und DevOps in derselben Organisation zusammenarbeiten? Für mich lautet die Antwort: Ja.⁷ Zwar gibt es einige Überschneidungen bei den Werkzeugen und manchmal auch bei den Fähigkeiten, aber sie konzentrieren sich auf unterschiedliche Dinge und bieten unterschiedliche Vorteile für ein Unternehmen.

Vorwärts zu den SRE-Grundlagen

Wenn dich jetzt jemand fragt: "Was ist SRE?", hast du die Bausteine, um es ihm zu erklären. Dazu werde ich in Kapitel 4 noch viel mehr sagen. Nachdem wir nun ein wenig über die SRE-Definitionen und die Geschichte von SRE gesprochen haben, kommen wir nun zu den eigentlichen SRE-Grundlagen, die für unser Verständnis des Themas und den Rest dieses Buches entscheidend sind.

¹ Ich empfehle dir, das Buch Implementing Service Level Objectives von Alex Hidalgo zu lesen : A Practical Guide to SLIs, SLOs, and Error Budgets (O'Reilly, 2020) zu diesem Thema.

² Ganz ehrlich: Ich bin einer der Mitbegründer der SREcon.

³ Eine meiner Lieblingsantworten kam von Michael Doherty, der sagte: "Site Reliability Engineering: Wir wissen nicht, was DevOps ist, aber wir wissen, dass wir etwas ganz anderes sind." Das ist zwar keine der offiziellen Antworten, aber ich kann ihr nicht widersprechen.

⁴ Vor allem ist es ein präskriptiver Ansatz, denn DevOps hat sich in vielerlei Hinsicht bemüht, keine bestimmten Methoden oder Tools vorzuschreiben. Ob das gelungen ist, könnte eine weitere interessante Diskussion sein.

⁵ Mit Zwischenstopps, um sie in einem Repository zu speichern, und Tests, um sicherzustellen, dass sie sicher eingesetzt werden kann, damit die Kunden davon profitieren können.

⁶ Ich habe das noch nie untersucht, aber mein Instinkt sagt mir, dass sie dadurch andere Dinge beobachten würden. Es würde Spaß machen, das zu untersuchen.

⁷ Nun, unter bestimmten Voraussetzungen wie der Größe des Unternehmens (ein neues Startup braucht vielleicht nicht beides), der Unternehmenskultur (ob SRE dazu passt; siehe weiter unten in diesem Buch) und dem Bedarf (stelle nur das ein, was du brauchst, nicht alles).