Ü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, das sowohl für die Kommunikation über die Zuverlässigkeit des Dienstes als auch für die Verwaltung des Dienstes verwendet wird.

SLIs werden über ein Zeitfenster gemessen. Die Größe des Fensters hängt normalerweise von der Entscheidung ab, die die Informationen verwenden. Beispielsweise können Sie einen einzelnen SLI so 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 den folgenden Abschnitten der Arbeitsmappe der Site Reliability Engineering:

Eigenschaften guter SLIs

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

  • SLIs sind gute Proxy-Maßnahmen für die Zufriedenheit der Nutzer.

    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 linear mit der Nutzerzufriedenheit.

    Ein guter SLI wird monoton und linear mit der Zufriedenheit der Nutzer skaliert. Wenn sich der SLI verbessert, verbessert sich die Zufriedenheit der Nutzer. Wenn der SLI sinkt, nimmt die Zufriedenheit der Nutzer ebenfalls ab. Der Wert eines guten SLI entspricht dem Grad 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.
  • Zum Starten des geplanten Batchjobs innerhalb einer Minute nach Beginn.

SLI-Spezifikationen und -Implementierungen

Eine SLI-Spezifikation ist, was Sie messen möchten. Die Spezifikation enthält nicht die genauen technischen Details dazu, wie Sie sie messen werden. Das folgende Beispiel zeigt eine Spezifikation eines SLI für die Seitenladezeit.

  • Der Prozentsatz der Startseitenanfragen, die unter 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: Gibt an, welcher Anteil der Nutzerinteraktionen gemessen wird.
  • 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. Beispielsweise führt die Implementierung, die Code im Browser des Nutzers verwendet, zu einer genaueren Messung der Latenz als der vom Nutzer wahrgenommenen Latenz oder durch andere Messoptionen.

Der Kompromiss besteht darin, dass die browserbasierte Messung auch jede Latenz enthält, die durch die Verbindung des Nutzers zu Ihrem Dienst verursacht wird. Wenn ein Dienst beispielsweise über das öffentliche Internet verwendet wird, kann diese Latenz je nach geografischem Standort 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 zum Kombinieren mehrerer Messungen zum Ausgleich dieses Kompromisses finden Sie in diesem Post 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

Dienste, die mehrere Arten von Aufgaben für verschiedene Nutzerkategorien ausführen und in denen jede Art von Arbeit die Zufriedenheit der Nutzer beeinflusst, profitieren von mehreren SLIs.

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. In der Regel hat der SLI-Messwert ein Label, mit dem Sie Werte in einen von mehreren Buckets klassifizieren können.

Eine Aufgabe mit unterschiedlichen Ergebnissen

Dienste, die eine einzige Arbeit ausführen, aber wenn die Nutzererwartungen auf der Grundlage der Antwortvorteile mehrerer SLIs variieren.

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 der Latenz-SLI in der Lage sein, zwischen erfolgreichen und fehlgeschlagenen Anfragen zu unterscheiden.

Nächste Schritte

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

Informationen zur Implementierung von anwendungsspezifischen SLIs finden Sie hier:

Ein Beispiel zum Erstellen eines SLI für Dienste, die benutzerdefinierte Messwerte melden, finden Sie unter SLOs: Beobachtbarkeit mit benutzerdefinierten Messwerten festlegen.