Kapitel 4. Service Level Zielsetzungen

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Geschrieben von Chris Jones, John Wilkes und Niall Murphy mit Cody Smith

Herausgegeben von Betsy Beyer

Es ist unmöglich, einen Dienst richtig, geschweige denn gut zu verwalten, ohne zu verstehen, welche Verhaltensweisen für diesen Dienst wirklich wichtig sind und wie man diese Verhaltensweisen messen und bewerten kann. Zu diesem Zweck möchten wir ein bestimmtes Serviceniveau definieren und unseren Nutzern zur Verfügung stellen, egal ob sie eine interne API oder ein öffentliches Produkt nutzen.

Wir nutzen Intuition, Erfahrung und ein Verständnis für die Wünsche der Nutzer, um Service Level Indikatoren (SLIs), Ziele (SLOs) undVereinbarungen (SLAs) zu definieren. Diese Messungen beschreiben die grundlegenden Eigenschaften der Kennzahlen, die wichtig sind, welche Werte diese Kennzahlen haben sollen und wie wir reagieren, wenn wir die erwartete Leistung nicht erbringen können. Letztlich hilft die Auswahl geeigneter Messgrößen dabei, die richtigen Maßnahmen zu ergreifen, wenn etwas schief läuft, und gibt dem SRE-Team die Gewissheit, dass ein Dienst in Ordnung ist.

In diesem Kapitel wird der Rahmen beschrieben, den wir verwenden, um uns mit den Problemen der metrischen Modellierung, der Auswahl von Metriken und der metrischen Analyse auseinanderzusetzen. Viele dieser Erklärungen wären ohne ein Beispiel ziemlich abstrakt, daher verwenden wir den Shakespeare-Dienst, der in"Shakespeare: Ein Beispieldienst" beschriebenen Shakespeare-Dienst, um die wichtigsten Punkte zu veranschaulichen.

Service Level Terminologie

Viele Leserinnen und Leser sind wahrscheinlich mit dem Konzept der SLA vertraut, aber auch die Begriffe SLI und SLO sollten sorgfältig definiert werden, denn im allgemeinen Sprachgebrauch ist der Begriff SLA überladen und hat je nach Kontext eine Reihe von Bedeutungen angenommen. Wir ziehen es vor, diese Bedeutungen der Klarheit halber zu trennen.

Indikatoren

Ein SLI ist ein Service-Level-Indikator - einsorgfältig definiertes quantitatives Maß für einen bestimmten Aspekt des erbrachten Servicelevels.

Bei den meisten Diensten ist die Latenzzeit, d.h. wielange es dauert, bis eine Antwort auf eine Anfrage zurückkommt, eine der wichtigsten SLIs. Weitere gängige SLIs sind dieFehlerrate, die oft als Bruchteil aller eingegangenen Anfragen ausgedrückt wird, und der Systemdurchsatz, der in der Regel in Anfragen pro Sekunde gemessen wird. Die Messungen werden oft aggregiert, d.h. die Rohdaten werden über ein Messfenster gesammelt und dann in eine Rate, einen Durchschnitt oder einen Prozentsatz umgerechnet.

Im Idealfall misst der SLI die gewünschte Serviceebene direkt, aber manchmal ist nur ein Proxy verfügbar, weil die gewünschte Messung schwer zu erhalten oder zu interpretieren ist. Zum Beispiel ist die Latenzzeit auf der Client-Seite oft die für den Nutzer relevantere Kennzahl, aber es kann sein, dass die Latenz nur auf dem Server gemessen werden kann.

Eine andere Art von SLI, die für SREs wichtig ist, ist die Verfügbarkeit, also der Anteil der Zeit, in der ein Dienst nutzbar ist. Sie wird oft durch den Anteil der erfolgreichen, wohlgeformten Anfragen definiert, auch Yield genannt.(Die Dauerhaftigkeit - dieWahrscheinlichkeit, dass Daten über einen langen Zeitraum hinweg erhalten bleiben - ist für Datenspeichersysteme ebenso wichtig). Eine Verfügbarkeit von 100 % ist zwar unmöglich, aber eine Verfügbarkeit von nahezu 100 % ist oft leicht zu erreichen, und die Branche drückt Hochverfügbarkeitswerte üblicherweise durch die Anzahl der "Neunen" in der Verfügbarkeitsangabe aus. Verfügbarkeiten von 99% und 99,999% werden zum Beispiel als "2 Neunen" bzw. "5 Neunen" bezeichnet, und das derzeit veröffentlichte Ziel für die Verfügbarkeit der Google Compute Engine ist "dreieinhalb Neunen" - 99,95% Verfügbarkeit.

Ziele

Ein SLO ist ein Service-Level-Ziel: ein Zielwert oder ein Wertebereich für einen Service-Level, der durch einen SLI gemessen wird. Eine natürliche Struktur für SLOs ist also SLI ≤ Ziel, oder untere Grenze ≤ SLI ≤ obere Grenze. Wir könnten z. B. beschließen, dass wir die Suchergebnisse von Shakespeare "schnell" zurückgeben und eine SLO festlegen, die besagt, dass die durchschnittliche Latenzzeit unserer Suchanfragen weniger als 100 Millisekunden betragen soll.

Die Auswahl eines geeigneten SLO ist komplex. Zunächst einmal kannst du den Wert nicht immer selbst bestimmen! Bei den HTTP-Anfragen, die von außen an deinen Dienst gestellt werden, wird der Wert für die Abfragen pro Sekunde (QPS) im Wesentlichen durch die Wünsche deiner Nutzer/innen bestimmt.

Andererseits kannst du sagen, dass die durchschnittliche Latenzzeit pro Anfrage unter 100 Millisekunden liegen soll. Ein solches Ziel könnte dich wiederum dazu motivieren, dein Frontend mit verschiedenen Arten von latenzarmen Verhaltensweisen zu schreiben oder bestimmte Arten von latenzarmen Geräten zu kaufen. (100 Millisekunden ist natürlich ein willkürlicher Wert, aber im Allgemeinen sind niedrigere Latenzwerte gut. Es gibt gute Gründe für die Annahme, dass schnell besser ist als langsam und dass Latenzzeiten, die über bestimmten Werten liegen, die Nutzer/innen abschrecken - siehe "Speed Matters" [Bru09] für weitere Details).

Auch dies ist subtiler, als es auf den ersten Blick erscheinen mag, da diese beiden SLIs - QPS und Latenz - hinter den Kulissen miteinander verbunden sein können: Höhere QPS führt oft zu größeren Latenzen, und es ist üblich, dass Dienste ab einer bestimmten Lastschwelle eine Leistungsklippe haben.

Durch die Auswahl und Veröffentlichung von SLOs für die Nutzer/innen werden Erwartungen an die Leistung eines Dienstes geweckt. Diese Strategie kann unbegründete Beschwerden an die Dienstverantwortlichen reduzieren, zum Beispiel darüber, dass der Dienst langsam ist. Ohne eine explizite SLO entwickeln die Nutzer/innen oft ihre eigenen Vorstellungen von der gewünschten Leistung, die möglicherweise nicht mit den Vorstellungen derjenigen übereinstimmen, die den Dienst entwickeln und betreiben. Diese Dynamik kann dazu führen, dass man sich zu sehr auf den Dienst verlässt, wenn die Nutzer/innen fälschlicherweise glauben, dass ein Dienst besser verfügbar ist, als er es tatsächlich ist (wie im Fall von Chubby: siehe "The Global Chubby Planned Outage"), oder dass man sich zu wenig darauf verlässt, wenn potenzielle Nutzer/innen glauben, dass ein System schwankender und weniger zuverlässig ist, als es tatsächlich ist.

Vereinbarungen

Schließlich sind SLAs Service Level Agreements: ein expliziter oder impliziter Vertrag mit deinen Nutzern, der Konsequenzen für die Erfüllung (oder Nichterfüllung) der darin enthaltenen SLOs vorsieht. Die Konsequenzen sind am leichtesten zu erkennen, wenn sie finanzieller Art sind - ein Rabatt oder eine Strafe -, aber sie können auch andere Formen annehmen. Der Unterschied zwischen einem SLO und einem SLA lässt sich leicht feststellen, wenn du dich fragst: "Was passiert, wenn die SLOs nicht erfüllt werden?1

SRE ist normalerweise nicht an der Erstellung von SLAs beteiligt, da diese eng mit Geschäfts- und Produktentscheidungen verbunden sind. SRE hilft jedoch dabei, die Folgen von verpassten SLAs zu vermeiden. Sie können auch dabei helfen, die SLIs zu definieren: Es muss natürlich eine objektive Möglichkeit geben, die SLOs in der Vereinbarung zu messen, sonst kommt es zu Unstimmigkeiten.

Die Google-Suche ist ein Beispiel für einen wichtigen Dienst, für den es kein SLA gibt: Wir wollen, dass jeder die Suche so reibungslos und effizient wie möglich nutzen kann, aber wir haben keinen Vertrag mit der ganzen Welt abgeschlossen. Trotzdem hat es Folgen, wenn die Suche nicht verfügbar ist - unser Ruf leidet darunter und die Werbeeinnahmen gehen zurück. Viele andere Google-Dienste, wie z. B. Google for Work, haben ausdrückliche SLAs mit ihren Nutzern. Unabhängig davon, ob ein bestimmter Dienst ein SLA hat oder nicht, ist es sinnvoll, SLIs und SLOs zu definieren und sie für die Verwaltung des Dienstes zu nutzen.

So viel zur Theorie - jetzt zu den Erfahrungen.

Indikatoren in der Praxis

Nachdem wir dargelegt haben, warum es wichtig ist, geeignete Kennzahlen zur Messung deiner Dienstleistung auszuwählen, stellt sich die Frage, wie du herausfindest, welche Kennzahlen für deine Dienstleistung oder dein System sinnvoll sind.

Was ist dir und deinen Nutzern wichtig?

Du solltest nicht jede Kennzahl, die du in deinem Überwachungssystem erfassen kannst, als SLI verwenden. Wenn du weißt, was deine Nutzer von deinem System erwarten, kannst du einige wenige Indikatoren mit Bedacht auswählen. Wenn du zu viele Indikatoren auswählst, ist es schwierig, den wichtigen Indikatoren die nötige Aufmerksamkeit zu schenken, und wenn du zu wenige auswählst, kann es passieren, dass du wichtige Verhaltensweisen deines Systems nicht untersuchst. In der Regel reicht eine Handvoll repräsentativer Indikatoren aus, um den Zustand eines Systems zu bewerten und Schlussfolgerungen zu ziehen.

Die Dienste lassen sich in Bezug auf die SLIs, die sie für relevant halten, in ein paar große Kategorien einteilen:

  • Nutzerseitige Serving-Systeme, wie die Shakespeare-Suchfrontends, achten in der Regel auf Verfügbarkeit, Latenz undDurchsatz. Mit anderen Worten: Konnten wir auf die Anfrage reagieren? Wie lange dauerte es, bis die Anfrage beantwortet wurde? Wie viele Anfragen konnten bearbeitet werden?

  • BeiSpeichersystemen stehen oft die Latenzzeit, die Verfügbarkeit und dieHaltbarkeit im Vordergrund. Mit anderen Worten: Wie lange dauert es, Daten zu lesen oder zu schreiben? Können wir bei Bedarf auf die Daten zugreifen? Sind die Daten noch da, wenn wir sie brauchen? In Kapitel 26 findest du eine ausführliche Diskussion dieser Fragen.

  • BeiBig-Data-Systemen, wie z. B. Datenverarbeitungspipelines, geht es in der Regel um den Durchsatz und die End-to-End-Latenzzeit. Mit anderen Worten: Wie viele Daten werden verarbeitet? Wie lange dauert es, bis die Daten vom Eingang bis zum Abschluss verarbeitet sind? (Manche Pipelines haben auch Zielvorgaben für die Latenzzeit einzelner Verarbeitungsschritte).

  • Alle Systeme sollten auf Korrektheit achten: Wurde die richtige Antwort zurückgegeben, die richtigen Daten abgerufen, die richtige Analyse durchgeführt? Korrektheit ist ein wichtiger Indikator für den Zustand des Systems, auch wenn sie oft eine Eigenschaft der Daten im System und nicht der Infrastruktur an sich ist und daher normalerweise nicht in den Verantwortungsbereich von SRE fällt.

Sammeln von Indikatoren

Viele Indikatoren lassen sich am besten auf der Serverseite mit einem Überwachungssystem wie Borgmon (siehe Kapitel 10) oder Prometheus oder durch regelmäßige Log-Analysen erfassen, z. B. HTTP 500-Antworten als Anteil aller Anfragen. Einige Systeme sollten jedoch mit einer clientseitigen Erfassung ausgestattet werden, denn wenn das Verhalten auf dem Client nicht gemessen wird, können eine Reihe von Problemen übersehen werden, die zwar die Benutzer betreffen, aber keinen Einfluss auf die serverseitigen Metriken haben. Konzentriert man sich zum Beispiel auf die Antwortzeiten des Shakespeare-Such-Backends, kann es passieren, dass man die Latenzzeiten der Nutzer aufgrund von Problemen mit dem JavaScript der Seite übersieht: In diesem Fall ist die Messung der Zeit, die es dauert, bis eine Seite im Browser nutzbar ist, ein besserer Indikator dafür, was der Nutzer tatsächlich erlebt.

Aggregation

Der Einfachheit und Benutzerfreundlichkeit halber fassen wir die Rohdaten oft zusammen. Das muss sorgfältig gemacht werden.

Einige Kennzahlen sind scheinbar einfach, wie z.B. die Anzahl der Anfragen pro Sekunde, aber selbst diese scheinbar einfache Messung aggregiert implizit Daten über das Messfenster. Wird die Messung einmal pro Sekunde durchgeführt oder durch den Durchschnitt der Anfragen über eine Minute? Letzteres kann dazu führen, dass viel höhere momentane Anfrageraten in Bursts verborgen bleiben, die nur ein paar Sekunden dauern. Stell dir ein System vor, das in den geraden Sekunden 200 Anfragen pro Sekunde bedient und in den anderen Sekunden 0. Es hat die gleiche durchschnittliche Auslastung wie ein System, das konstant 100 Anfragen pro Sekunde bearbeitet, aber die momentane Auslastung ist doppelt so hoch wie die durchschnittliche. Ähnlich verhält es sich mit der Durchschnittsbildung für die Latenzzeiten von Anfragen: Es ist durchaus möglich, dass die meisten Anfragen schnell sind, aber ein langer Schwanz von Anfragen viel, viel langsamer.

Die meisten Messwerte sind eher als Verteilungen denn als Durchschnittswerte zu betrachten. Bei einer Latenz-SLI werden zum Beispiel einige Anfragen schnell bearbeitet, während andere unweigerlich länger brauchen - manchmal sogar viel länger. Ein einfacher Durchschnittswert kann diese hinteren Latenzen sowie deren Veränderungen verschleiern. Abbildung 4-1 zeigt ein Beispiel: Obwohl eine typische Anfrage in etwa 50 ms bearbeitet wird, sind 5 % der Anfragen 20-mal langsamer! Eine Überwachung und Alarmierung, die sich nur auf die durchschnittliche Latenzzeit stützt, würde keine Veränderung des Verhaltens im Laufe des Tages zeigen, obwohl es in Wirklichkeit erhebliche Veränderungen bei der hinteren Latenzzeit gibt (oberste Zeile).

50th, 85th, 95th, and 99th percentile latencies for a system. Note that the Y-axis has a logarithmic scale.
Abbildung 4-1. 50., 85., 95. und 99. Perzentil der Latenzzeiten für ein System. Beachte, dass die Y-Achse eine logarithmische Skala hat.

Die Verwendung von Perzentilen für Indikatoren ermöglicht es dir, die Form der Verteilung und ihre unterschiedlichen Eigenschaften zu berücksichtigen: Ein höheres Perzentil wie das 99. oder 99,9. zeigt dir einen plausiblen Worst-Case-Wert, während das 50. Je höher die Streuung der Antwortzeiten ist, desto mehr wird das typische Nutzererlebnis durch Long-Tail-Verhalten beeinträchtigt, ein Effekt, der bei hoher Last durch Warteschlangeneffekte noch verstärkt wird. Deshalb konzentrieren sich manche SRE-Teams nur auf hohe Perzentilwerte, denn wenn das 99,9-Perzentil-Verhalten gut ist, dann ist es auch das typische Verhalten.

Indikatoren standardisieren

Wir empfehlen dir, einheitliche Definitionen für SLIs zu verwenden, damit du nicht jedes Mal von Grund auf neu darüber nachdenken musst. Jedes Merkmal, das den Standard-Definitionsvorlagen entspricht, kann in der Spezifikation eines einzelnen SLIs weggelassen werden, z. B.:

  • Aggregationsintervalle: "Durchschnittlich über 1 Minute"

  • Aggregationsregionen: "Alle Aufgaben in einem Cluster"

  • Wie häufig wird gemessen: "Alle 10 Sekunden"

  • Welche Anfragen enthalten sind: "HTTP-GETs von Blackbox-Überwachungsaufträgen"

  • Wie die Daten erfasst werden: "Durch unsere Überwachung, gemessen am Server"

  • Latenzzeit beim Datenzugriff: "Zeit bis zum letzten Byte"

Um Aufwand zu sparen, solltest du eine Reihe von wiederverwendbaren SLI-Templates für jede gängige Kennzahl erstellen; dadurch wird es für alle einfacher zu verstehen, was ein bestimmter SLI bedeutet.

Zielsetzungen in der Praxis

Beginne damit, darüber nachzudenken (oder herauszufinden!), was deinen Nutzern wichtig ist, und nicht, was du messen kannst. Oft lässt sich das, was deinen Nutzern wichtig ist, nur schwer oder gar nicht messen, sodass du dich den Bedürfnissen der Nutzer irgendwie annähern musst. Wenn du jedoch einfach mit dem beginnst, was leicht zu messen ist, wirst du am Ende weniger nützliche SLOs haben. Deshalb haben wir festgestellt, dass es manchmal besser ist, von den gewünschten Zielen zu spezifischen Indikatoren zurückzugehen, als Indikatoren auszuwählen und dann Ziele zu formulieren.

Zielsetzungen definieren

Um maximale Klarheit zu schaffen, sollten die SLOs angeben, wie sie gemessen werden und unter welchen Bedingungen sie gültig sind. Wir könnten zum Beispiel Folgendes sagen (die zweite Zeile ist die gleiche wie die erste, greift aber auf die SLI-Vorgaben des vorherigen Abschnitts zurück, um Redundanz zu vermeiden):

  • 99% (im Durchschnitt über 1 Minute) der Get RPC-Aufrufe werden in weniger als 100 ms abgeschlossen (gemessen an allen Backend-Servern).

  • 99% der Get RPC-Aufrufe werden in weniger als 100 ms abgeschlossen.

Wenn die Form der Leistungskurven wichtig ist, kannst du mehrere SLO-Ziele angeben:

  • 90% der Get RPC-Aufrufe werden in weniger als 1 ms abgeschlossen.

  • 99% der Get RPC-Aufrufe werden in weniger als 10 ms abgeschlossen.

  • 99,9 % der Get RPC-Aufrufe werden in weniger als 100 ms abgeschlossen.

Wenn du Nutzer mit heterogenen Arbeitslasten hast, z. B. eine Massenverarbeitungspipeline, die auf den Durchsatz achtet, und einen interaktiven Client, der auf die Latenzzeit achtet, kann es sinnvoll sein, für jede Klasse von Arbeitslasten separate Ziele zu definieren:

  • 95 % der RPC-Aufrufe der Durchsatz-Clients Set werden in < 1 s abgeschlossen.

  • 99% der RPC-Aufrufe von Set mit einer Latenz von < 1 kB werden in < 10 ms abgeschlossen.

Es ist sowohl unrealistisch als auch unerwünscht, darauf zu bestehen, dass die SLOs zu 100 % erfüllt werden: Das kann die Innovations- und Umsetzungsrate verringern, teure, übermäßig konservative Lösungen erfordern oder beides. Stattdessen ist es besser, ein Fehlerbudget einzuräumen - also die Rate, mit der die SLOs verfehlt werden können - und dies täglich oder wöchentlich zu überprüfen. Das obere Management wird wahrscheinlich auch eine monatliche oder vierteljährliche Bewertung wünschen. (Ein Fehlerbudget ist nur ein SLO für die Erfüllung anderer SLOs!)

Die SLO-Verstoßrate kann mit dem Fehlerbudget verglichen werden (siehe "Motivation für Fehlerbudgets"), wobei die Lücke als Input für den Prozess verwendet wird, der entscheidet, wann neue Versionen eingeführt werden.

Ziele auswählen

Die Auswahl der Ziele (SLOs) ist keine rein technische Angelegenheit, denn sie hat auch Auswirkungen auf das Produkt und das Geschäft, was sich in den ausgewählten SLIs und SLOs (und eventuell SLAs) widerspiegeln sollte. Ebenso kann es notwendig sein, bestimmte Produkteigenschaften gegen andere abzuwägen, und zwar im Rahmen der personellen, zeitlichen und finanziellen Beschränkungen, die sich aus der Verfügbarkeit von Hardware ergeben. SRE sollte Teil dieser Diskussion sein und über die Risiken und die Realisierbarkeit verschiedener Optionen beraten. Wir haben einige Lektionen gelernt, die dazu beitragen können, diese Diskussion produktiver zu gestalten:

Wähle kein Ziel, das auf der aktuellen Leistung basiert

Auch wenn es wichtig ist, die Vorzüge und Grenzen eines Systems zu verstehen, kann die unreflektierte Übernahme von Werten dazu führen, dass du ein System unterstützt, das heroische Anstrengungen erfordert, um seine Ziele zu erreichen, und das nicht ohne erhebliche Umgestaltung verbessert werden kann.

Halte es einfach

Komplizierte Aggregationen in SLIs können Änderungen in der Systemleistung verschleiern und sind außerdem schwieriger zu verstehen.

Vermeide absolute Werte

Es ist zwar verlockend, ein System zu fordern, das seine Last "unendlich" skalieren kann, ohne dass die Latenzzeit steigt, und das "immer" verfügbar ist, aber diese Anforderung ist unrealistisch. Selbst ein System, das sich solchen Idealen annähert, wird wahrscheinlich viel Zeit in Anspruch nehmen und teuer im Betrieb sein - und wahrscheinlich unnötig besser sein als das, was die Nutzer/innen gerne hätten (oder sogar begeistert wären).

So wenige SLOs wie möglich haben

Wähle gerade so viele SLOs, dass sie die Eigenschaften deines Systems gut abdecken. Verteidige die von dir gewählten SLOs: Wenn du ein Gespräch über Prioritäten nicht mit dem Hinweis auf eine bestimmte SLO gewinnen kannst, ist es wahrscheinlich nicht wert, diese SLO zu haben.2 Allerdings lassen sich nicht alle Produktattribute mit SLOs abdecken: Es ist schwer, "Benutzerfreundlichkeit" mit einem SLO zu beschreiben.

Perfektion kann warten

Du kannst die SLO-Definitionen und -Ziele im Laufe der Zeit immer weiter verfeinern, wenn du mehr über das Verhalten eines Systems erfährst. Es ist besser, mit einem lockeren Ziel zu beginnen, das du dann festlegst, als ein zu strenges Ziel zu wählen, das du wieder aufweichen musst, wenn du feststellst, dass es unerreichbar ist.

SLOs können - und sollten - eine wichtige Triebfeder für die Priorisierung der Arbeit von SREs und Produktentwicklern sein, denn sie spiegeln wider, was für die Nutzer wichtig ist. Eine gute SLO ist eine hilfreiche, legitime Antriebsfunktion für ein Entwicklungsteam. Aber eine schlecht durchdachte SLO kann zu vergeudeter Arbeit führen, wenn ein Team heroische Anstrengungen unternimmt, um eine zu aggressive SLO zu erfüllen, oder zu einem schlechten Produkt, wenn die SLO zu lasch ist. SLOs sind ein wichtiger Hebel: Setze sie weise ein.

Kontrollmaßnahmen

SLIs und SLOs sind wichtige Elemente in den Regelkreisen, die zur Verwaltung der Systeme eingesetzt werden:

  1. Überwache und messe die SLIs des Systems.

  2. Vergleiche die SLIs mit den SLOs und entscheide, ob Handlungsbedarf besteht oder nicht.

  3. Wenn Handlungsbedarf besteht, überlege dir, was passieren muss, um das Ziel zu erreichen.

  4. Mach diese Aktion.

Wenn Schritt 2 beispielsweise zeigt, dass die Latenz der Anfragen zunimmt und der SLO in ein paar Stunden nicht mehr erreicht wird, wenn nicht etwas unternommen wird, könnte Schritt 3 die Prüfung der Hypothese beinhalten, dass die Server CPU-lastig sind, und die Entscheidung, weitere Server hinzuzufügen, um die Last zu verteilen. Ohne den SLO wüsstest du nicht, ob (oder wann) du etwas unternehmen musst.

SLOs setzen Erwartungen

Die Veröffentlichung von SLOs setzt Erwartungen an das Systemverhalten. Nutzer (und potenzielle Nutzer) wollen oft wissen, was sie von einem Dienst erwarten können, um zu verstehen, ob er für ihren Anwendungsfall geeignet ist. Ein Team, das eine Website zum Teilen von Fotos aufbauen möchte, möchte vielleicht keinen Dienst nutzen, der eine sehr hohe Haltbarkeit und niedrige Kosten im Austausch für eine etwas geringere Verfügbarkeit verspricht, obwohl derselbe Dienst vielleicht perfekt für ein Archivierungssystem geeignet ist.

Um realistische Erwartungen für deine Nutzer/innen zu schaffen, könntest du eine oder beide der folgenden Taktiken anwenden:

Behalte eine Sicherheitsmarge

Eine engere interne SLO als die SLO, die den Nutzern mitgeteilt wird, gibt dir die Möglichkeit, auf chronische Probleme zu reagieren, bevor sie nach außen hin sichtbar werden. Ein SLO-Puffer ermöglicht auch Neuimplementierungen, bei denen die Leistung gegen andere Eigenschaften wie Kosten oder Wartungsfreundlichkeit eingetauscht wird, ohne dass die Nutzer/innen enttäuscht werden müssen.

Übertreibe es nicht

Vor allem bei Infrastrukturdiensten verlassen sich die Nutzer/innen auf das, was du tatsächlich anbietest, und nicht auf das, was du zu liefern versprichst. Wenn die tatsächliche Leistung deines Dienstes viel besser ist als die angegebene SLO, werden sich die Nutzer/innen auf die aktuelle Leistung verlassen. Du kannst eine zu große Abhängigkeit vermeiden, indem du das System gelegentlich absichtlich offline nimmst (Googles Chubby-Dienst hat als Reaktion auf die zu hohe Verfügbarkeit geplante Ausfälle eingeführt),3 einige Anfragen drosseln oder das System so gestalten, dass es bei geringer Last nicht schneller ist.

Wenn man weiß, wie gut ein System die Erwartungen erfüllt, kann man entscheiden, ob man in ein schnelleres, verfügbareres und stabileres System investieren sollte. Wenn der Dienst gut läuft, sollten die Mitarbeiter/innen ihre Zeit vielleicht für andere Prioritäten verwenden, z. B. um technische Schulden zu tilgen, neue Funktionen hinzuzufügen oder andere Produkte einzuführen.

Vereinbarungen in der Praxis

Bei der Ausarbeitung eines SLA müssen die Geschäfts- und Rechtsteams angemessene Konsequenzen und Strafen für einen Verstoß festlegen. Die Aufgabe von SRE ist es, ihnen dabei zu helfen, die Wahrscheinlichkeit und Schwierigkeit der Erfüllung der in der SLA enthaltenen SLOs zu verstehen. Viele der Ratschläge zur Erstellung von SLOs sind auch auf SLAs anwendbar. Es ist ratsam, mit dem, was du den Nutzern mitteilst, vorsichtig zu sein, denn je breiter der Nutzerkreis ist, desto schwieriger ist es, SLAs zu ändern oder zu streichen, die sich als unklug oder schwierig erweisen, mit ihnen zu arbeiten.

1 Die meisten Menschen meinen wirklich SLO, wenn sie "SLA" sagen. Ein Hinweis: Wenn jemand von einer "SLA-Verletzung" spricht, meint er damit fast immer eine verpasste SLO. Ein echter SLA-Verstoß könnte ein Gerichtsverfahren wegen Vertragsbruchs nach sich ziehen.

2 Wenn du nie ein Gespräch über SLOs gewinnen kannst, lohnt es sich wahrscheinlich nicht, ein SRE-Team für das Produkt zu haben.

3 Failure Injection [Ben12] dient einem anderen Zweck, kann aber auch dazu beitragen, Erwartungen zu setzen.

Get Site Reliability Engineering now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial