Übersicht

In diesem Abschnitt wird das Konzept der SLIs (Service Level Indicators) beschrieben. Es wird dargelegt, welche SLIs sinnvoll oder nützlich sind, und es werden Beispiele für SLI-Implementierungen ausgewählter Dienste präsentiert. Diese Seite richtet sich an Personen, die Beispiele zur Implementierung dienstspezifischer SLIs benötigen.

Einführung in SLIs

Die Zuverlässigkeit eines Dienstes ist eine abstrakte Idee. Was Zuverlässigkeit bedeutet, ist vom Dienst und den Anforderungen seiner Nutzer abhängig. Ein Service Level Indicator (SLI) ist ein Maß für diese Zuverlässigkeit und wird verwendet, um eine Beschreibung der Zuverlässigkeit des Dienstes zu ermöglichen und relevante Entscheidungen zu treffen.

SLIs werden über Zeitfenster gemessen. Die Größe des Fensters hängt normalerweise von der Entscheidung ab, welche Informationen berücksichtigt werden. Zum Beispiel können Sie einen einzelnen SLI auf folgende Weise messen:

  • Über die letzte Stunde (zum Erstellen von Benachrichtigungsrichtlinien).
  • Über Wochen (für taktische Entscheidungen).
  • Über Monate (für strategische Entscheidungen).

Wir empfehlen 28 Tage als Ausgangspunkt für die Messung Ihres SLI. Dieser Wert bietet ein gutes Gleichgewicht zwischen strategischen und taktischen Anwendungsfällen.

Weitere Informationen finden Sie in folgenden Kapiteln in der Site Reliability Engineering-Arbeitsmappe:

Eigenschaften guter SLIs

Als "gute" SLIs gelten solche, die folgende Kriterien erfüllen:

  • SLIs sind gute Proxy-Messungen für die Nutzerzufriedenheit.

    Gute SLIs stehen in engem Zusammenhang mit der Nutzerzufriedenheit. SLIs dienen als Grundlage für Service Level Objectives (SLO), für SLIs festgelegte Schwellenwerte. Sie legen SLOs so fest, dass die meisten Nutzer zufrieden sind, wenn der entsprechende SLI innerhalb eines definierten Bereichs liegt. Damit diese Beziehung belastbar ist, muss der SLI ein gutes Maß für die Nutzerzufriedenheit sein.

    Ist der SLI ein gutes Maß für die Nutzerzufriedenheit, so ändert sich der SLI im Falle eines Ereignisses, das sich auf die Zufriedenheit der Nutzer auswirkt. Gleichermaßen ändert sich der SLI nicht, wenn keine sich auf die Zufriedenheit der Nutzer auswirkenden Ereignisse vorliegen.

  • SLIs skalieren monoton und annähernd linear mit der Nutzerzufriedenheit.

    Ein guter SLI skaliert monoton und ungefähr linear zur Nutzerzufriedenheit. Verbessert sich der SLI, so verbessert sich auch die Zufriedenheit der Nutzer und umgekehrt. Die Verbesserung des Werts eines guten SLI entspricht der Verbesserung der Nutzerzufriedenheit.

  • SLIs ergeben Werte zwischen 0 % und 100 %.

    Ein guter SLI liefert einen Leistungsmesswert zwischen 0 % und 100 %: Dieser Bereich ist intuitiv und leicht zu verwenden. Beispiel: Eine SLI-Leistung von 100 % bedeutet, dass alles gut läuft. Eine SLI-Leistung von 0 % bedeutet, dass nichts gut läuft.

    Mit einem SLI zwischen 0 % und 100 % wird zum Festlegen eines SLO für den SLI einfach ein Prozentsatzziel von beispielsweise 99,9 % bestimmt. Die SLI-Leistung des Dienstes muss diesem Wert entsprechen oder ihn übertreffen, um das SLO zu erfüllen.

Versprechen

Wenn Sie einen SLI mit diesen Attributen implementieren möchten, können Sie sich den SLI als eine Art Nutzerversprechen vorstellen. Wenn Sie eingehaltene und gebrochene Versprechen über die Zeit erfassen, können Sie daraus einen Wert von 0 % bis 100 % ableiten. Solche SLIs lassen sich auch gut in Fehlerbudgets umwandeln: Für ein bestimmtes SLO ist Ihr Fehlerbudget die Anzahl der Versprechen, die Sie über ein Zeitfenster hinaus brechen können, ohne dass das SLO verletzt wird.

Beispiele für Versprechen:

  • Einer Kundenanfrage eine Antwort mit dem HTTP-Statuscode 200 zurückgeben.
  • In weniger als 100 ms auf eine gRPC-Anfrage reagieren.
  • Den Workflow "Virtuelle Maschine erstellen" erfolgreich beenden.
  • Daten bereitstellen, die in den letzten zehn Minuten aktualisiert wurden.
  • Innerhalb einer Minute ab der Zielstartzeit mit der Ausführung eines geplanten Batchjobs beginnen.

Versprechen können niedrigstufig sein, wie bei den HTTP- und gRPC-Beispielen, oder abstrakter, wie das Workflow-Beispiel.

SLI-Spezifikationen und -Implementierungen

Eine SLI-Spezifikation ist das, was Sie messen möchten. Die Spezifikation enthält keine genauen technischen Details dazu, wie diese Messung erfolgt. Im Folgenden sehen Sie zum Beispiel einen SLI für die Seitenladezeit:

  • Der Prozentsatz der Startseitenanfragen, die in weniger als 100 ms geladen werden.

Es gibt viele Möglichkeiten, einen SLI zu messen. Alle haben ihre Vor- und Nachteile. Die Methoden zur Messung des SLI sind die SLI-Implementierungen. Sie können beispielsweise die Seitenladespezifikation so implementieren:

  • Über das Latenzfeld des Anfragelogs des Anwendungsservers.
  • Über vom Anwendungsserver exportierte Messwerte.
  • Über von einem Load-Balancer vor den Anwendungsservern exportierte Messwerte.
  • Über einen Blackbox-Monitoring-Dienst, der künstliche Anfragen an das System sendet und misst, wie lange es dauert, bis gültige Antworten empfangen werden.
  • Über einen anwendungsspezifischen Code, der im Browser des Kunden ausgeführt wird, Timinginformationen erfasst und diese an einen Sammlungsdienst sendet.

Bei jeder dieser Optionen müssen Kompromisse zwischen folgenden Eigenschaften eingegangen werden:

  • Treue: Gibt an, wie genau das Nutzererlebnis erfasst wird.
  • Abdeckung: Anteil der Nutzerinteraktionen, die gemessen werden.
  • Kosten: Die Kosten (Zeit und Geld) für die Entwicklung und Wartung der Lösung.

Die Genauigkeit der Nutzerfreundlichkeit verbessert sich, wenn SLIs näher am Nutzer gemessen werden. Beispiel: Eine Implementierung, die Code im Browser des Nutzers verwendet, führt zu einer genaueren Messung der vom Nutzer wahrgenommen Latenz als die anderen Implementierungsoptionen.

Der Nachteil besteht darin, dass die browserbasierte Messung auch Latenzen enthält, die durch die Verbindung des Nutzers zu Ihrem Dienst entstehen. Bei einem Dienst, der über das öffentliche Internet genutzt wird, kann diese Latenz aufgrund von geografischen Gegebenheiten oder Netzwerkbedingungen erheblich variieren.

Dies hat zur Folge, dass das browserbasierte Signal ein gutes Maß für die Nutzerzufriedenheit darstellt, jedoch keine nützlichen Informationen dazu bereitstellt, wie Sie die Zuverlässigkeit Ihres Dienstes verbessern können.

Informationen dazu, wie Sie mehrere Messungen zum Ausgleich dieser Vor- und Nachteile kombinieren, finden Sie in diesem Beitrag von The Telegraph.

Bucketing

Möglicherweise benötigen Sie mehrere SLIs für einen Dienst, wenn Ihr Dienst verschiedene Aufgaben für unterschiedliche Nutzer ausführt oder eine Aufgabe mit verschiedenen möglichen Ergebnissen erledigt.

Verschiedene Aufgaben

Eine Art Dienst, die von dem mehreren SLIs profitieren, führt mehrere Aufgabentypen für unterschiedliche Nutzerkategorien durch, wobei die verschiedenen Tätigkeiten unterschiedliche Auswirkungen auf die Nutzerzufriedenheit haben können.

Verarbeitet Ihr Dienst beispielsweise Lese- und Schreibanfragen, so können Nutzer, die diese Aufgaben ausführen, unterschiedliche Anforderungen haben:

  • Leseanfragen müssen schnell verarbeitet werden.
  • Schreibanfragen müssen erfolgreich sein.

Um diese unterschiedlichen Anforderungen zu erfassen, muss Ihr SLI zwischen den beiden Fällen unterscheiden können. Das bedeutet in der Regel, dass der SLI-Messwert ein Label hat, mit dem Sie Werte in eines von mehreren Buckets klassifizieren können.

Eine Aufgabe mit unterschiedlichen Ergebnissen

Eine weitere Art Dienst, der von mehreren SLIs profitiert, ist ein einzelner Vorgang, bei dem die Nutzererwartungen von der Antwort abhängig sind.

Bietet Ihr Dienst beispielsweise nur Lesezugriff auf Daten, so können Nutzer unterschiedliche Toleranzwerte akzeptieren, je nach dem Ergebnis der Anfrage:

  • Nutzer sind möglicherweise tolerant für Fehler, die schnell zurückgegeben werden, da sie dann die Anfrage sofort wiederholen können.
  • Nutzer sind möglicherweise weniger tolerant gegenüber Anfragen, die sehr lange dauern.
  • Die Nutzer tolerieren den schlimmsten Fall am wenigsten: Anfragen, bei denen das Zurückgeben eines Fehlers lange dauert.

In diesem Fall muss Ihr Latenz-SLI zwischen erfolgreichen und nicht erfolgreichen Anfragen unterscheiden können.

Nächste Schritte

Informationen zur Implementierung von SLIs für Google Cloud-Dienste mit Google Cloud-Messwerten finden Sie hier:

Informationen zur Implementierung von anwendungsspezifischen SLIs finden Sie hier: