SRE (Site Reliability Engineering) - ein Ansatz zur Sicherstellung der Verfügbarkeit von Webprojekten. Es wird als Framework für DevOps angesehen und beschreibt, wie DevOps-Praktiken erfolgreich angewendet werden können. Dieser Artikel ist eine Übersetzung von Kapitel 4 der Service Level Objectives von Site Reliability Engineering von Google. Ich habe diese Übersetzung selbst angefertigt und mich auf meine eigenen Erfahrungen im Verständnis der Überwachungsprozesse verlassen. Im Telegrammkanal monitorim_it und im letzten Beitrag zu Habré habe ich auch eine Übersetzung von Kapitel 6 desselben Buches zur Überwachung verteilter Systeme veröffentlicht.

Übersetzung von Katze. Viel Spaß beim Lesen!

Es ist unmöglich, einen Service zu managen, wenn man nicht versteht, welche Indikatoren wirklich wichtig sind und wie sie gemessen und bewertet werden. Zu diesem Zweck definieren und bieten wir unseren Benutzern ein bestimmtes Serviceniveau, unabhängig davon, ob sie eine unserer internen APIs oder ein öffentliches Produkt verwenden.

Wir setzen unsere Intuition und Erfahrung ein und erkennen den Wunsch der Benutzer nach einer Vorstellung von Service Level Indicators (SLI), Service Level Objectives (SLO) und Service Level Agreements (SLA). Diese Messungen beschreiben die wichtigsten Metriken, die wir steuern möchten und auf die wir reagieren werden, wenn wir die erwartete Servicequalität nicht bereitstellen können. Letztendlich hilft die Auswahl der richtigen Indikatoren dabei, die richtigen Maßnahmen zu ergreifen, wenn etwas schief geht, und gibt dem SRE-Team auch Vertrauen in den Zustand des Dienstes.

In diesem Kapitel wird der Ansatz beschrieben, mit dem wir uns mit den Problemen der Metrikmodellierung, der Metrikauswahl und der Metrikanalyse befassen. Die meisten Erklärungen werden ohne Beispiele sein, daher werden wir den Shakespeare-Dienst verwenden, der im Beispiel seiner Implementierung (Suche nach Shakespeares Werken) beschrieben ist, um die Hauptpunkte zu veranschaulichen.

Service Level Terminologie

Viele Leser sind wahrscheinlich mit dem Konzept der SLA vertraut, aber die Begriffe SLI und SLO verdienen eine sorgfältige Definition, da der Begriff SLA im Allgemeinen überladen ist und je nach Kontext eine Reihe von Bedeutungen hat. Aus Gründen der Übersichtlichkeit möchten wir diese Werte trennen.

Indikatoren

Der SLI ist ein Indikator für das Serviceniveau - ein sorgfältig quantifiziertes Maß für einen Aspekt des bereitgestellten Serviceniveaus.

Bei den meisten Diensten wird die Verzögerung in der Anforderung als Schlüssel-SLI betrachtet - wie viel Zeit ist erforderlich, um eine Antwort auf die Anforderung zurückzugeben. Andere häufige SLIs umfassen die Fehlerrate, die häufig als Bruchteil aller empfangenen Anforderungen ausgedrückt wird, und den Systemdurchsatz, der normalerweise in Anforderungen pro Sekunde gemessen wird. Messungen werden häufig aggregiert: Rohdaten werden zuerst gesammelt und dann in Änderungsrate, Durchschnitt oder Perzentil umgewandelt.

Im Idealfall misst der SLI das interessierende Serviceniveau direkt, aber manchmal steht nur die zugehörige Metrik zur Messung zur Verfügung, da das Original schwer zu erhalten oder zu interpretieren ist. Beispielsweise ist die clientseitige Latenz oft eine angemessenere Messgröße, aber es kommt vor, dass die Messung der Latenz nur auf dem Server möglich ist.

Ein weiterer für SRE wichtiger SLI-Typ ist die Verfügbarkeit oder ein Teil der Zeit, in der der Service genutzt werden kann. Es wird häufig als Prozentsatz erfolgreicher Anforderungen definiert, manchmal auch als Generierung bezeichnet. (Lebenserwartung - Die Wahrscheinlichkeit, dass Daten über einen längeren Zeitraum gespeichert werden, ist auch für Datenspeichersysteme wichtig.) Obwohl die Zugänglichkeit zu 100% unmöglich ist, ist eine Zugänglichkeit von nahezu 100% häufig erreichbar. Die Zugänglichkeitswerte werden als Zahl „neun“ ausgedrückt. »Prozentuale Verfügbarkeit. Beispielsweise kann die Verfügbarkeit von 99% und 99,999% als "2 Neunen" und "5 Neunen" bezeichnet werden. Das derzeit angegebene Ziel für die Barrierefreiheit der Google Compute Engine ist "dreieinhalb Neunen" oder 99,95%.

Ziele

SLO ist das Ziel eines Service Levels: Ein Zielwert oder Wertebereich für das Service Level, der von SLI gemessen wird. Der Normalwert für SLO ist "SLI ≤ Zielwert" oder "Untergrenze ≤ SLI ≤ Obergrenze". Beispielsweise können wir festlegen, dass die Suchergebnisse für Shakespeares Werke "schnell" zurückgegeben werden. In Form eines SLO beträgt die durchschnittliche Verzögerung für Suchanfragen weniger als 100 Millisekunden.

Die Auswahl des richtigen SLO ist ein komplexer Prozess. Erstens können Sie nicht immer einen bestimmten Wert auswählen. Bei externen eingehenden HTTP-Anforderungen an Ihren Service wird die Metrik der Anzahl der Anforderungen pro Sekunde (QPS) hauptsächlich durch den Wunsch Ihrer Benutzer bestimmt, Ihren Service zu besuchen. Sie können SLO hierfür nicht installieren.

Andererseits können Sie sagen, dass die durchschnittliche Verzögerung für jede Anforderung weniger als 100 Millisekunden betragen soll. Wenn Sie sich ein solches Ziel setzen, können Sie Ihr Front-End mit einer geringen Verzögerung erstellen oder Geräte kaufen, die eine solche Verzögerung bieten. (100 Millisekunden sind offensichtlich ein willkürlicher Wert, aber es ist besser, noch niedrigere Latenzzeiten zu haben. Es gibt Grund zu der Annahme, dass hohe Geschwindigkeit besser als langsam ist und dass das Verzögern von Benutzeranforderungen über bestimmte Werte hinaus dazu führt, dass sich die Leute von Ihrem Dienst fernhalten.)

Auch dies ist mehrdeutig, als es auf den ersten Blick erscheinen mag: Es lohnt sich nicht, QPS aus der Berechnung zu streichen. Tatsache ist, dass das QPS-Bündel und die Verzögerung in engem Zusammenhang stehen: Ein höherer QPS-Wert führt häufig zu längeren Verzögerungen, und bei Diensten kommt es in der Regel zu einem starken Leistungsabfall, wenn eine bestimmte Lastschwelle erreicht wird.

Durch die Auswahl und Veröffentlichung von SLO werden die Benutzererwartungen hinsichtlich der Funktionsweise des Dienstes festgelegt. Diese Strategie kann unangemessene Beschwerden über den Service-Eigentümer, beispielsweise über seine langsame Arbeit, reduzieren. Ohne eine explizite SLO stellen Benutzer häufig ihre eigenen Erwartungen an die gewünschte Leistung, die in keiner Weise mit den Meinungen der Personen zusammenhängen, die den Service entwerfen und verwalten. Diese Ausrichtung kann zu hohen Erwartungen an den Dienst führen, wenn Benutzer fälschlicherweise glauben, dass der Dienst besser zugänglich ist als er tatsächlich ist, und Misstrauen hervorrufen, wenn Benutzer glauben, dass das System weniger zuverlässig ist als es tatsächlich ist.

Vereinbarung

Ein Service Level Agreement ist ein expliziter oder impliziter Vertrag mit Ihren Benutzern, der die Konsequenzen des Einbruchs (oder der Abwesenheit) der darin enthaltenen SLOs enthält. Die Konsequenzen sind am einfachsten zu erkennen, wenn es sich um finanzielle Konsequenzen handelt - einen Rabatt oder eine Strafe -, sie können jedoch auch andere Formen annehmen. Eine einfache Möglichkeit, über den Unterschied zwischen SLOs und SLAs zu sprechen, ist die Frage: "Was passiert, wenn SLOs nicht erfüllt werden?" Wenn es keine offensichtlichen Konsequenzen gibt, werden Sie sich mit ziemlicher Sicherheit mit SLO befassen.

SREs sind normalerweise nicht an der Erstellung von SLAs beteiligt, da SLAs in engem Zusammenhang mit Geschäfts- und Produktlösungen stehen. SRE ist jedoch bemüht, die Folgen fehlgeschlagener SLOs zu verhindern. Sie können auch bei der Bestimmung von SLIs helfen: Offensichtlich muss es eine objektive Methode zur Messung von SLOs in einer Vereinbarung geben, sonst kommt es zu Meinungsverschiedenheiten.

Die Google-Suche ist ein Beispiel für einen wichtigen Dienst, für den es keine SLA für die Öffentlichkeit gibt: Wir möchten, dass jeder die Suche so effizient wie möglich nutzt, haben jedoch keinen Vertrag mit der ganzen Welt geschlossen. Wenn die Suche nicht verfügbar ist, hat dies jedoch immer noch Konsequenzen: Unzugänglichkeiten führen zu einem Rückgang unserer Reputation und zu einem Rückgang der Werbeeinnahmen. Viele andere Google-Dienste, z. B. Google for Work, haben explizite Vereinbarungen zum Servicelevel mit Nutzern. Unabhängig davon, ob ein bestimmter Dienst eine SLA hat, ist es wichtig, SLI und SLO zu bestimmen und sie zur Verwaltung des Dienstes zu verwenden.

So viel Theorie - jetzt zum Erleben.

Indikatoren in der Praxis

Angenommen, wir sind zu dem Schluss gekommen, dass es wichtig ist, die geeigneten Indikatoren zur Messung des Servicelevels auszuwählen. Woher wissen Sie nun, welche Indikatoren für den Service oder das System relevant sind?

Was Sie und Ihre Benutzer interessiert

Sie müssen nicht jeden Indikator als SLI verwenden, den Sie im Überwachungssystem verfolgen können. Wenn Sie wissen, was Benutzer vom System erwarten, können Sie einige Kennzahlen auswählen. Wenn Sie zu viele Indikatoren auswählen, ist es schwierig, wichtigen Indikatoren Aufmerksamkeit zu schenken. Wenn Sie jedoch zu wenige Indikatoren auswählen, können erhebliche Teile Ihres Systems unbeaufsichtigt bleiben. Normalerweise verwenden wir mehrere Schlüsselindikatoren, um den Zustand des Systems zu bewerten und zu verstehen.

Dienstleistungen lassen sich in der Regel nach SLI in mehrere Teile aufteilen, die für sie relevant sind:

• Benutzerdefinierte Frontend-Systeme wie die Shakespeare-Service-Suchschnittstellen aus unserem Beispiel. Sie sollten zugänglich und nicht verzögert sein und eine ausreichende Bandbreite haben. Dementsprechend können Sie Fragen stellen: Können wir die Anfrage beantworten? Wie lange hat es gedauert, die Anfrage zu beantworten? Wie viele Anfragen können bearbeitet werden?
• Speichersysteme. Niedrige Latenz, Verfügbarkeit und Haltbarkeit sind ihnen wichtig. Verwandte Fragen: Wie lange dauert das Lesen oder Schreiben von Daten? Können wir bei Bedarf auf Daten zugreifen? Sind Daten verfügbar, wenn wir sie brauchen? Weitere Informationen zu diesen Themen finden Sie in Kapitel 26, Datenintegrität.
• Big-Data-Systeme wie Datenverarbeitungs-Pipelines hängen vom Durchsatz und der Latenz der Anforderungsverarbeitung ab. Relevante Fragen: Wie viele Daten werden verarbeitet? Wie lange dauert es, bis die Daten vom Empfang einer Anfrage zur Ausgabe einer Antwort übergehen? (Einige Teile des Systems können in bestimmten Phasen auch Verzögerungen aufweisen.)

Indikatorensammlung

Es ist am einfachsten, viele Service-Level-Indikatoren auf der Serverseite mithilfe eines Überwachungssystems wie Borgmon (siehe Kapitel 10, Übung zu Zeitreihen-Warnungen ) oder Prometheus zu erfassen oder einfach die Protokolle in regelmäßigen Abständen zu analysieren und HTTP-Antworten mit dem Status 500 anzuzeigen. Einige Systeme sollten mit einer clientseitigen Messwerterfassung ausgestattet sein, da die mangelnde Überwachung auf der Clientseite dazu führen kann, dass einige Probleme fehlen, die die Benutzer betreffen, die serverseitigen Messwerte jedoch nicht betreffen. Wenn Sie sich beispielsweise auf die verzögerte Antwort des Backends unserer Testanwendung konzentrieren, um nach Shakespeares Werken zu suchen, kann dies zu Verzögerungen bei der Verarbeitung von Anforderungen auf der Benutzerseite aufgrund von JavaScript-Problemen führen. In diesem Fall ist die Messung der Verarbeitungsdauer der Seite im Browser der beste Indikator.

Aggregation

Zur Vereinfachung und einfacheren Verwendung aggregieren wir häufig Rohdimensionen. Dies muss sorgfältig durchgeführt werden.

Einige Indikatoren scheinen einfach zu sein, zum Beispiel die Anzahl der Abfragen pro Sekunde, aber selbst diese offensichtliche direkte Messung aggregiert implizit Daten über die Zeit. Wird der Messwert speziell einmal pro Sekunde ermittelt oder wird dieser Messwert über die Anzahl der Abfragen pro Minute gemittelt? Die letztere Option kann eine viel höhere augenblickliche Anzahl von Anforderungen verbergen, die nur für einige Sekunden gespeichert werden. Stellen Sie sich ein System vor, das 200 Anfragen pro Sekunde mit geraden Zahlen und den Rest der Zeit mit 0 bedient. Eine Konstante in Form eines Durchschnittswerts von 100 Anforderungen pro Sekunde und einer doppelt so hohen Sofortbelastung ist nicht dasselbe. Ebenso mag die Durchschnittsberechnung von Anforderungslatenzen attraktiv erscheinen, verbirgt jedoch ein wichtiges Detail: Es ist möglich, dass die meisten Anforderungen schnell sind, aber es wird viele Anforderungen geben, die langsam sind.

Die meisten Indikatoren werden eher als Verteilungen als als Durchschnittswerte angesehen. Beispielsweise werden bei SLI-Verzögerungen einige Anforderungen schnell verarbeitet, während einige immer länger dauern, manchmal sogar viel länger. Ein einfacher Durchschnitt kann diese langen Verzögerungen verbergen. Die Abbildung zeigt ein Beispiel: Obwohl eine typische Anfrage ca. 50 ms lang bearbeitet wird, sind 5% der Anfragen 20-mal langsamer! Überwachung und Warnungen, die nur auf der durchschnittlichen Latenz basieren, zeigen keine Verhaltensänderungen während des Tages, obwohl bei einigen Anforderungen (in der obersten Zeile) spürbare Änderungen in der Verarbeitungszeit zu verzeichnen sind.


50, 85, 95 und 99 Prozent der Systemverzögerung. Die Y-Achse hat ein logarithmisches Format.

Mithilfe von Perzentilen für Indikatoren können Sie die Form der Verteilung und ihre Merkmale anzeigen: Ein hohes Niveau eines Perzentils wie 99 oder 99,9 zeigt den schlechtesten Wert, und bei 50 Perzentilen (auch als Median bezeichnet) können Sie den häufigsten Status der Metrik anzeigen. Je größer die Abweichung in der Antwortzeit ist, desto stärker wirken sich langfristige Abfragen auf die Benutzerfreundlichkeit aus. Der Effekt wird bei hoher Last in Anwesenheit von Warteschlangen verstärkt. Studien zur Benutzererfahrung haben gezeigt, dass Benutzer in der Regel ein langsameres System mit einer hohen Streuung der Antwortzeiten bevorzugen. Daher konzentrieren sich einige SRE-Teams nur auf hohe Perzentilwerte. Dabei wird davon ausgegangen, dass die meisten Benutzer kein gutes metrisches Verhalten für das 99,9-Perzentil haben Probleme.

Hinweis zu statistischen Fehlern

Normalerweise arbeiten wir lieber mit Perzentilen als mit einem durchschnittlichen (arithmetischen Mittelwert) Wertesatz. Dies ermöglicht es uns, mehr Streuwerte zu berücksichtigen, die häufig erheblich andere (und interessantere) Eigenschaften als der Durchschnitt aufweisen. Aufgrund der künstlichen Natur von Computersystemen werden Metrikwerte häufig verzerrt. Beispielsweise kann keine Anforderung eine Antwort in weniger als 0 ms erhalten, und eine Zeitüberschreitung von 1000 ms bedeutet, dass keine erfolgreichen Antworten mit Werten vorliegen, die die Zeitüberschreitung überschreiten. Infolgedessen können wir nicht akzeptieren, dass der Mittelwert und der Median gleich oder nahe beieinander liegen können!

Ohne vorläufige Überprüfung und wenn einige Standardannahmen und -annäherungen nicht erfüllt sind, versuchen wir, keine Schlussfolgerungen zu ziehen, dass unsere Daten normal verteilt sind. Wenn die Verteilung nicht wie erwartet ist, kann dies ein Automatisierungsprozess, der das Problem behebt (z. B. wenn Ausreißer über die Grenzwerte hinausgehen, der Server mit hohen Latenzen für die Verarbeitung der Anforderung neu gestartet wird), zu oft oder nicht oft genug tun (beide Optionen sind nicht sehr gut).

Indikatoren standardisieren

Wir empfehlen, die allgemeinen Merkmale für SLIs zu standardisieren, damit Sie nicht jedes Mal darüber sprechen müssen. Jede Funktion, die Standardvorlagen erfüllt, kann von der Spezifikation eines einzelnen SLI ausgeschlossen werden, zum Beispiel:

• Aggregationsintervalle: "gemittelt über 1 Minute"
• Aggregationsbereiche: „Alle Aufgaben im Cluster“
• Wie oft wird gemessen: "Alle 10 Sekunden"
• Welche Anforderungen sind enthalten: "HTTP-GET von Black-Box-Überwachungsaufträgen"
• Wie die Daten empfangen wurden: „Dank unserer auf dem Server gemessenen Überwachung“,
• Datenzugriffsverzögerung: "Time to Last Byte"

Erstellen Sie einen Satz wiederverwendbarer SLI-Vorlagen für jede allgemeine Metrik, um Aufwand zu sparen. Sie erleichtern es auch jedem, zu verstehen, was ein bestimmter SLI bedeutet.

Übungsziele

Beginnen Sie damit, darüber nachzudenken (oder es herauszufinden!), Was Ihre Benutzer interessieren und nicht, was Sie messen können. Oft ist es schwierig oder unmöglich zu messen, was Ihre Benutzer stört, sodass Sie sich ihren Bedürfnissen nähern. Wenn Sie jedoch mit dem beginnen, was einfach zu messen ist, erhalten Sie weniger nützliche SLOs. Infolgedessen stellten wir manchmal fest, dass die anfängliche Definition gewünschter Ziele und die weitere Arbeit mit bestimmten Indikatoren besser funktioniert als die Auswahl von Indikatoren und die anschließende Erreichung von Zielen.

Ziele definieren

Für maximale Klarheit sollte festgelegt werden, wie SLOs gemessen werden und unter welchen Bedingungen sie gültig sind. Zum Beispiel können wir Folgendes sagen (die zweite Zeile ist dieselbe wie die erste, verwendet jedoch standardmäßig SLI-Werte):

• 99% (gemittelt über 1 Minute) der get-RPC-Aufrufe werden in weniger als 100 ms ausgeführt (gemessen auf allen Back-End-Servern).
• 99% der Get RPC-Aufrufe werden in weniger als 100 ms ausgeführt.

Wenn die Form der Leistungskurven wichtig ist, können Sie mehrere SLO-Ziele angeben:

• 90% der get-RPC-Aufrufe wurden in weniger als 1 ms ausgeführt.
• 99% der get-RPC-Aufrufe wurden in weniger als 10 ms abgeschlossen.
• 99,9% der get-RPC-Aufrufe wurden in weniger als 100 ms ausgeführt.

Wenn Ihre Benutzer heterogene Lasten erzeugen: Massenverarbeitung (für die Bandbreite wichtig ist) und interaktive Verarbeitung (für die die Verzögerung wichtig ist), kann es ratsam sein, für jede Lastklasse separate Ziele zu definieren:

• 95% der Kundenanfragen sind wichtige Bandbreite. Stellen Sie die Anzahl der laufenden RPC-Aufrufe auf <1 s ein.
• 99% der Kunden schätzen die Verspätung. Richten Sie die Anzahl der RPC-Anrufe mit einem Datenverkehr von <1 KB und einer Dauer von <10 ms ein.

Es ist unrealistisch und unerwünscht, darauf zu bestehen, dass SLOs in 100% der Fälle ausgeführt werden: Dies kann die Einführung neuer Funktionen und die Bereitstellung verlangsamen und teure Lösungen erfordern. Stattdessen ist es besser, ein Budget mit Fehlern einzuplanen - ein Bruchteil der Ausfallzeit des Systems - und dies täglich oder wöchentlich zu überwachen. Das Top-Management kann eine monatliche oder vierteljährliche Beurteilung wünschen. ( — SLO SLO).

SLO (. 3 « » ), , , .

(SLO) - , SLI, SLO (, , SLA). , , , , . SRE . , :

,
, : , .


SLI .


, — . , , , , , .

SLO
SLO, . SLO, : , SLO, , SLO. , SLO: SLO.


SLO , . , , , , , .

SLO SRE , . SLO — . SLO , SLO , SLO . SLO — , .

SLI SLO , :

• SLI .
• SLI SLO .
• , , , .
• .

, 2 , , SLO , , 3 , . SLO ( ) .

SLO —
SLO . ( ) , , , . , , - , , , .

, :

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

, , , . , , , , .

SLA , - . SRE , SLO, SLA. SLO SLA. , , , SLA, .

, . - monitorim_it .