SRE (Site Reliability Engineering) ist ein Ansatz zur Sicherstellung der Verfügbarkeit von Webprojekten. Es gilt als Rahmenwerk für DevOps und befasst sich mit der erfolgreichen Anwendung von DevOps-Praktiken. Übersetzung in diesem Artikel Bücher von Google. Ich habe diese Übersetzung selbst erstellt und mich auf meine eigene Erfahrung im Verständnis von Überwachungsprozessen verlassen. Im Telegrammkanal и Ich habe auch eine Übersetzung von Kapitel 6 desselben Buches über Service-Level-Ziele veröffentlicht.
Übersetzung nach Kat. Viel Spaß beim Lesen!
Es ist unmöglich, einen Dienst zu verwalten, wenn man nicht weiß, welche Indikatoren tatsächlich wichtig sind und wie man sie misst und bewertet. Zu diesem Zweck definieren wir ein bestimmtes Serviceniveau und stellen es unseren Benutzern zur Verfügung, unabhängig davon, ob sie eine unserer internen APIs oder ein öffentliches Produkt verwenden.
Wir nutzen unsere Intuition, Erfahrung und unser Verständnis für den Wunsch der Benutzer, Service Level Indicators (SLIs), Service Level Objectives (SLOs) und Service Level Agreements (SLAs) zu verstehen. Diese Dimensionen beschreiben die wichtigsten Kennzahlen, die wir überwachen wollen und auf die wir reagieren, wenn wir nicht die erwartete Servicequalität bieten können. Letztendlich hilft die Auswahl der richtigen Metriken dabei, die richtigen Maßnahmen zu ergreifen, wenn etwas schief geht, und gibt dem SRE-Team außerdem Vertrauen in den Zustand des Dienstes.
In diesem Kapitel wird der Ansatz beschrieben, mit dem wir die Probleme der Metrikmodellierung, Metrikauswahl und Metrikanalyse bekämpfen. Die meisten Erklärungen erfolgen ohne Beispiele, daher verwenden wir den in seinem Implementierungsbeispiel (Suche nach Shakespeares Werken) beschriebenen Shakespeare-Dienst, um die Hauptpunkte zu veranschaulichen.
Service-Level-Terminologie
Viele Leser sind wahrscheinlich mit dem Konzept von 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.
Indicators
Der SLI ist ein Service-Level-Indikator – ein sorgfältig definiertes quantitatives Maß für einen Aspekt des bereitgestellten Service-Levels.
Bei den meisten Diensten gilt die Anforderungslatenz als entscheidender SLI – die Zeit, die es dauert, bis eine Antwort auf eine Anforderung zurückgegeben wird. Weitere gängige SLIs sind die Fehlerrate, die oft als Bruchteil aller empfangenen Anfragen ausgedrückt wird, und der Systemdurchsatz, der üblicherweise in Anfragen pro Sekunde gemessen wird. Messungen werden häufig aggregiert: Rohdaten werden zunächst erfasst und dann in eine Änderungsrate, einen Mittelwert oder ein Perzentil umgewandelt.
Im Idealfall misst SLI direkt das interessierende Serviceniveau, manchmal steht jedoch nur eine zugehörige Metrik zur Messung zur Verfügung, da die ursprüngliche Metrik schwer zu erhalten oder zu interpretieren ist. Beispielsweise ist die clientseitige Latenz oft eine geeignetere Metrik, aber es gibt Zeiten, in denen die Latenz nur auf dem Server gemessen werden kann.
Eine weitere Art von SLI, die für SREs wichtig ist, ist die Verfügbarkeit oder der Zeitabschnitt, in dem ein Dienst genutzt werden kann. Wird oft als die Rate erfolgreicher Anfragen definiert, manchmal auch Yield genannt. (Lebensdauer – die Wahrscheinlichkeit, dass Daten über einen längeren Zeitraum aufbewahrt werden – ist auch für Datenspeichersysteme wichtig.) Obwohl eine 100-prozentige Verfügbarkeit nicht möglich ist, ist eine Verfügbarkeit von nahezu 100 % oft erreichbar; Verfügbarkeitswerte werden ausgedrückt als die Anzahl der „Neunen“ » Prozentsatz der Verfügbarkeit. Beispielsweise könnten 99 % und 99,999 % Verfügbarkeit als „2 Neunen“ und „5 Neunen“ gekennzeichnet werden. Das aktuell von Google Compute Engine angegebene Verfügbarkeitsziel liegt bei „dreieinhalb Neunen“ oder 99,95 %.
Tore
Ein SLO ist ein Service-Level-Ziel: ein Zielwert oder Wertebereich für einen Service-Level, der durch den SLI gemessen wird. Ein normaler Wert für SLO ist „SLI ≤ Ziel“ oder „Untergrenze ≤ SLI ≤ Obergrenze“. Beispielsweise könnten wir entscheiden, dass wir Shakespeare-Suchergebnisse „schnell“ zurückgeben, indem wir das SLO auf eine durchschnittliche Suchabfragelatenz von weniger als 100 Millisekunden festlegen.
Die Auswahl des richtigen SLO ist ein komplexer Prozess. Erstens können Sie nicht immer einen bestimmten Wert auswählen. Für externe eingehende HTTP-Anfragen an Ihren Dienst wird die Kennzahl „Abfrage pro Sekunde“ (Query Per Second, QPS) in erster Linie durch den Wunsch Ihrer Benutzer bestimmt, Ihren Dienst zu besuchen, und Sie können dafür kein SLO festlegen.
Andererseits können Sie sagen, dass die durchschnittliche Latenz für jede Anfrage weniger als 100 Millisekunden betragen soll. Wenn Sie sich ein solches Ziel setzen, sind Sie möglicherweise gezwungen, Ihr Frontend mit geringer Latenz zu schreiben oder Geräte zu kaufen, die eine solche Latenz bieten. (100 Millisekunden sind offensichtlich eine willkürliche Zahl, aber es ist besser, noch niedrigere Latenzzahlen zu haben. Es gibt Hinweise darauf, dass schnelle Geschwindigkeiten besser sind als langsame Geschwindigkeiten, und dass Latenz bei der Verarbeitung von Benutzeranfragen über bestimmten Werten Menschen tatsächlich dazu zwingt, sich fernzuhalten von Ihrem Dienst.)
Auch dies ist mehrdeutiger, als es auf den ersten Blick erscheinen mag: Sie sollten QPS nicht vollständig aus der Berechnung ausschließen. Fakt ist, dass QPS und Latenz eng miteinander verknüpft sind: Höhere QPS führen oft zu höheren Latenzen und bei Diensten kommt es in der Regel zu einem starken Leistungsabfall, wenn sie eine bestimmte Auslastungsschwelle erreichen.
Durch die Auswahl und Veröffentlichung eines SLO werden die Erwartungen der Benutzer an die Funktionsweise des Dienstes festgelegt. Diese Strategie kann unbegründete Beschwerden gegen den Serviceeigentümer, wie z. B. langsame Leistung, reduzieren. Ohne ein explizites SLO entwickeln Benutzer häufig ihre eigenen Erwartungen an die gewünschte Leistung, die möglicherweise nichts mit den Meinungen der Personen zu tun haben, die den Dienst entwerfen und verwalten. Diese Situation kann zu überhöhten Erwartungen an den Dienst führen, wenn Benutzer fälschlicherweise glauben, dass der Dienst zugänglicher 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
Eine Service-Level-Vereinbarung ist ein expliziter oder impliziter Vertrag mit Ihren Benutzern, der die Konsequenzen der Einhaltung (oder Nichterfüllung) der darin enthaltenen SLOs regelt. Die Konsequenzen sind am einfachsten erkennbar, wenn sie finanzieller Natur sind – ein Rabatt oder eine Geldstrafe –, sie können aber auch andere Formen annehmen. Eine einfache Möglichkeit, über den Unterschied zwischen SLOs und SLAs zu sprechen, ist die Frage: „Was passiert, wenn die SLOs nicht eingehalten werden?“ Wenn es keine klaren Konsequenzen gibt, haben Sie es mit ziemlicher Sicherheit mit einem SLO zu tun.
Der SRE ist in der Regel nicht an der Erstellung von SLAs beteiligt, da SLAs eng mit Geschäfts- und Produktentscheidungen verknüpft sind. Der SRE trägt jedoch dazu bei, die Folgen gescheiterter SLOs abzumildern. Sie können auch dabei helfen, den SLI zu bestimmen: Offensichtlich muss es eine objektive Möglichkeit geben, den SLO in der Vereinbarung zu messen, sonst kommt es zu Meinungsverschiedenheiten.
Die Google-Suche ist ein Beispiel für einen wichtigen Dienst, für den es kein öffentliches SLA gibt: Wir möchten, dass jeder die Suche so effizient wie möglich nutzt, aber wir haben keinen Vertrag mit der Welt unterzeichnet. Wenn die Suche jedoch nicht verfügbar ist, hat dies dennoch Konsequenzen: Die Nichtverfügbarkeit führt zu einem Verlust unseres Rufs und geringeren Werbeeinnahmen. Viele andere Google-Dienste, wie zum Beispiel Google for Work, haben explizite Service-Level-Agreements mit Nutzern. Unabhängig davon, ob ein bestimmter Dienst über ein SLA verfügt, ist es wichtig, SLI und SLO zu definieren und diese zur Verwaltung des Dienstes zu verwenden.
So viel Theorie – nun zum Erleben.
Indikatoren in der Praxis
Nachdem wir zu dem Schluss gekommen sind, dass es wichtig ist, geeignete Metriken zur Messung des Servicelevels auszuwählen, woher wissen Sie nun, welche Metriken für einen Service oder ein System wichtig sind?
Was ist Ihnen und Ihren Nutzern wichtig?
Sie müssen nicht jede Metrik als SLI verwenden, die Sie in einem Überwachungssystem verfolgen können. Wenn Sie verstehen, was Benutzer von einem System erwarten, können Sie mehrere Metriken auswählen. Wenn Sie zu viele Indikatoren auswählen, ist es schwierig, sich auf wichtige Indikatoren zu konzentrieren, während die Auswahl einer kleinen Anzahl dazu führen kann, dass große Teile Ihres Systems unbeaufsichtigt bleiben. Normalerweise verwenden wir mehrere Schlüsselindikatoren, um den Zustand eines Systems zu bewerten und zu verstehen.
Generell lassen sich Dienste im Hinblick auf den SLI in mehrere für sie relevante Teile gliedern:
- Benutzerdefinierte Frontend-Systeme, wie z. B. die Suchoberflächen für den Shakespeare-Dienst aus unserem Beispiel. Sie müssen verfügbar sein, keine Verzögerungen aufweisen und über ausreichend Bandbreite verfügen. Dementsprechend können Fragen gestellt werden: Können wir auf die Anfrage reagieren? Wie lange hat die Beantwortung der Anfrage gedauert? Wie viele Anfragen können bearbeitet werden?
- Speichersysteme. Sie legen Wert auf niedrige Antwortlatenz, Verfügbarkeit und Haltbarkeit. Verwandte Fragen: Wie lange dauert das Lesen oder Schreiben von Daten? Können wir auf Anfrage auf die Daten zugreifen? Stehen die Daten dann zur Verfügung, wenn wir sie benötigen? Eine ausführliche Diskussion dieser Probleme finden Sie in Kapitel 26 „Datenintegrität: Was Sie lesen, ist das, was Sie schreiben“.
- Big-Data-Systeme wie Datenverarbeitungspipelines sind auf Durchsatz und Latenz bei der Abfrageverarbeitung angewiesen. Verwandte Fragen: Wie viele Daten werden verarbeitet? Wie lange dauert es, bis Daten vom Eingang einer Anfrage bis zur Ausgabe einer Antwort übertragen werden? (In einigen Teilen des Systems kann es in bestimmten Phasen auch zu Verzögerungen kommen.)
Sammlung von Indikatoren
Viele Service-Level-Indikatoren werden am natürlichsten auf der Serverseite mithilfe eines Überwachungssystems wie Borgmon erfasst (siehe unten). ) oder Prometheus, oder einfach die Protokolle regelmäßig analysieren und HTTP-Antworten mit dem Status 500 identifizieren. Einige Systeme sollten jedoch mit einer clientseitigen Metrikerfassung ausgestattet sein, da das Fehlen einer clientseitigen Überwachung dazu führen kann, dass eine Reihe von Problemen, die sich auswirken, übersehen werden Benutzer, haben jedoch keinen Einfluss auf serverseitige Metriken. Wenn Sie sich beispielsweise auf die Back-End-Antwortlatenz unserer Shakespeare-Suchtestanwendung konzentrieren, kann dies aufgrund von JavaScript-Problemen zu Latenz auf der Benutzerseite führen. In diesem Fall ist es eine bessere Messgröße, zu messen, wie lange der Browser benötigt, um die Seite zu verarbeiten.
Anhäufung
Aus Gründen der Einfachheit und Benutzerfreundlichkeit aggregieren wir häufig Rohmessungen. Dies muss sorgfältig erfolgen.
Einige Metriken scheinen einfach zu sein, wie z. B. Anfragen pro Sekunde, aber selbst diese scheinbar einfache Messung aggregiert implizit Daten über die Zeit. Wird die Messung konkret einmal pro Sekunde empfangen oder wird die Messung über die Anzahl der Anfragen pro Minute gemittelt? Die letztere Option kann eine viel höhere momentane Anzahl von Anfragen verbergen, die nur wenige Sekunden dauern. Stellen Sie sich ein System vor, das 200 Anfragen pro Sekunde mit geraden Zahlen und in der restlichen Zeit mit 0 bearbeitet. Eine Konstante in Form eines Durchschnittswerts von 100 Anfragen pro Sekunde und die doppelte Momentanlast sind nicht dasselbe. Ebenso mag die Mittelung der Abfragelatenzen attraktiv erscheinen, aber sie verbirgt ein wichtiges Detail: Es ist möglich, dass die meisten Abfragen schnell sind, aber es wird viele Abfragen geben, die langsam sind.
Die meisten Indikatoren sollten besser als Verteilungen denn als Durchschnittswerte betrachtet werden. Was beispielsweise die SLI-Latenz betrifft, werden einige Anfragen schnell verarbeitet, während andere immer länger, manchmal sogar viel länger dauern. Ein einfacher Durchschnitt kann diese langen Verzögerungen verbergen. Die Abbildung zeigt ein Beispiel: Obwohl die Bearbeitung einer typischen Anfrage etwa 50 ms dauert, sind 5 % der Anfragen 20-mal langsamer! Überwachung und Alarmierung, die nur auf der durchschnittlichen Latenz basieren, zeigen keine Verhaltensänderungen im Laufe des Tages, obwohl es tatsächlich spürbare Änderungen in der Verarbeitungszeit einiger Anfragen gibt (oberste Zeile).
50, 85, 95 und 99 Perzentil Systemlatenz. Die Y-Achse ist im logarithmischen Format.
Durch die Verwendung von Perzentilen als Indikatoren können Sie die Form der Verteilung und ihre Merkmale erkennen: Ein hohes Perzentilniveau wie 99 oder 99,9 zeigt den schlechtesten Wert an, während das 50. Perzentil (auch als Median bezeichnet) den häufigsten Zustand anzeigt die Metrik. Je größer die Streuung der Antwortzeit ist, desto mehr wirken sich lang andauernde Anfragen auf das Benutzererlebnis aus. Der Effekt verstärkt sich bei hoher Auslastung und bei Vorhandensein von Warteschlangen. Untersuchungen zur Benutzererfahrung haben gezeigt, dass Menschen im Allgemeinen ein langsameres System mit hoher Antwortzeitvarianz bevorzugen. Daher konzentrieren sich einige SRE-Teams nur auf hohe Perzentilwerte, da sie davon ausgehen, dass die meisten Benutzer keine Probleme haben werden, wenn das Verhalten einer Metrik beim 99,9-Perzentil gut ist .
Hinweis zu statistischen Fehlern
Im Allgemeinen arbeiten wir lieber mit Perzentilen als mit dem Mittelwert (arithmetisches Mittel) einer Reihe von Werten. Dadurch können wir stärker gestreute Werte berücksichtigen, die häufig deutlich andere (und interessantere) Eigenschaften als der Durchschnitt aufweisen. Aufgrund der künstlichen Natur von Computersystemen sind Metrikwerte oft verzerrt, zum Beispiel kann keine Anfrage eine Antwort in weniger als 0 ms erhalten, und ein Timeout von 1000 ms bedeutet, dass es keine erfolgreichen Antworten mit größeren Werten geben kann als die Auszeit. Daher können wir nicht akzeptieren, dass Mittelwert und Median gleich oder nahe beieinander sein können!
Ohne vorherige Tests und sofern nicht bestimmte Standardannahmen und Näherungen gelten, achten wir darauf, nicht zu dem Schluss zu kommen, dass unsere Daten normalverteilt sind. Wenn die Verteilung nicht wie erwartet ist, führt der Automatisierungsprozess, der das Problem behebt (wenn er beispielsweise Ausreißer erkennt, einen Neustart des Servers mit hohen Latenzen bei der Anforderungsverarbeitung durch), dies möglicherweise zu oft oder nicht oft genug aus (beides ist nicht der Fall). sehr gut).
Indikatoren standardisieren
Wir empfehlen, die allgemeinen Eigenschaften für SLI zu standardisieren, damit Sie nicht jedes Mal darüber spekulieren müssen. Jedes Merkmal, das Standardmustern entspricht, kann von der Spezifikation eines einzelnen SLI ausgeschlossen werden, zum Beispiel:
- Aggregationsintervalle: „gemittelt über 1 Minute“
- Aggregationsbereiche: „Alle Aufgaben im Cluster“
- Wie oft werden Messungen durchgeführt: „Alle 10 Sekunden“
- Welche Anfragen sind enthalten: „HTTP GET von Black-Box-Überwachungsjobs“
- Wie die Daten gewonnen werden: „Dank unserer auf dem Server gemessenen Überwachung“
- Datenzugriffslatenz: „Zeit bis zum letzten Byte“
Um Aufwand zu sparen, erstellen Sie für jede gemeinsame Metrik einen Satz wiederverwendbarer SLI-Vorlagen. Sie machen es auch für jeden einfacher zu verstehen, was ein bestimmter SLI bedeutet.
Ziele in der Praxis
Denken Sie zunächst darüber nach (oder finden Sie heraus!), was Ihren Benutzern wichtig ist, und nicht, was Sie messen können. Oftmals lässt sich das, was Ihren Benutzern am Herzen liegt, nur schwer oder gar nicht messen, sodass Sie am Ende ihren Bedürfnissen näher kommen. Wenn Sie jedoch einfach mit dem beginnen, was sich leicht messen lässt, erhalten Sie am Ende weniger nützliche SLOs. Daher haben wir manchmal festgestellt, dass es besser funktioniert, zunächst die gewünschten Ziele zu identifizieren und dann mit bestimmten Indikatoren zu arbeiten, als Indikatoren auszuwählen und dann die Ziele zu erreichen.
Definieren Sie Ihre Ziele
Für größtmögliche Klarheit sollte definiert werden, wie SLOs gemessen werden und unter welchen Bedingungen sie gültig sind. Wir könnten zum Beispiel Folgendes sagen (die zweite Zeile ist dieselbe wie die erste, verwendet jedoch die SLI-Standardeinstellungen):
- 99 % (gemittelt über 1 Minute) der Get RPC-Aufrufe werden in weniger als 100 ms abgeschlossen (gemessen auf allen Backend-Servern).
- 99 % der Get RPC-Aufrufe werden in weniger als 100 ms abgeschlossen.
Wenn die Form der Leistungskurven wichtig ist, können Sie mehrere SLOs angeben:
- 90 % der Get-RPC-Aufrufe wurden in weniger als 1 ms abgeschlossen.
- 99 % der Get-RPC-Aufrufe wurden in weniger als 10 ms abgeschlossen.
- 99.9 % der Get-RPC-Aufrufe wurden in weniger als 100 ms abgeschlossen.
Wenn Ihre Benutzer heterogene Arbeitslasten erzeugen: Massenverarbeitung (für die der Durchsatz wichtig ist) und interaktive Verarbeitung (für die die Latenz wichtig ist), kann es sich lohnen, für jede Lastklasse separate Ziele zu definieren:
- 95 % der Kundenanfragen erfordern Durchsatz. Legen Sie die Anzahl der ausgeführten RPC-Aufrufe auf <1 s fest.
- 99 % der Kunden kümmern sich um die Latenz. Legen Sie die Anzahl der RPC-Aufrufe mit einem Datenverkehr von <1 KB und einer Ausführungszeit von <10 ms fest.
Es ist unrealistisch und unerwünscht, darauf zu bestehen, dass SLOs zu 100 % eingehalten werden: Dies kann die Geschwindigkeit der Einführung neuer Funktionen und der Bereitstellung verringern und erfordert teure Lösungen. Stattdessen ist es besser, ein Fehlerbudget – den Prozentsatz der zulässigen Systemausfallzeit – einzuplanen und diesen Wert täglich oder wöchentlich zu überwachen. Die Geschäftsleitung möchte möglicherweise monatliche oder vierteljährliche Auswertungen. (Das Fehlerbudget ist lediglich ein SLO zum Vergleich mit einem anderen SLO.)
Der Prozentsatz der SLO-Verstöße kann mit dem Fehlerbudget verglichen werden (siehe Kapitel 3 und Abschnitt ), wobei der Differenzwert als Eingabe für den Prozess verwendet wird, der entscheidet, wann neue Versionen bereitgestellt werden.
Zielwerte auswählen
Die Auswahl von Planungswerten (SLOs) ist aufgrund der Produkt- und Geschäftsinteressen, die sich in den ausgewählten SLIs, SLOs (und möglicherweise SLAs) widerspiegeln müssen, keine rein technische Aktivität. Ebenso müssen möglicherweise Informationen zu Fragen im Zusammenhang mit Personal, Markteinführungszeit, Geräteverfügbarkeit und Finanzierung ausgetauscht werden. SRE sollte Teil dieses Gesprächs sein und dabei helfen, die Risiken und die Machbarkeit verschiedener Optionen zu verstehen. Wir haben ein paar Fragen zusammengestellt, die zu einer produktiveren Diskussion beitragen könnten:
Wählen Sie kein Ziel basierend auf der aktuellen Leistung.
Obwohl es wichtig ist, die Stärken und Grenzen eines Systems zu verstehen, kann die unbegründete Anpassung von Kennzahlen Sie daran hindern, das System aufrechtzuerhalten: Es erfordert heldenhafte Anstrengungen, um Ziele zu erreichen, die ohne eine umfassende Neugestaltung nicht erreicht werden können.
Halte es einfach
Komplexe SLI-Berechnungen können Änderungen in der Systemleistung verbergen und es schwieriger machen, die Ursache des Problems zu finden.
Vermeiden Sie Absolutheiten
Obwohl es verlockend ist, ein System zu haben, das eine unbegrenzt wachsende Last ohne Erhöhung der Latenz bewältigen kann, ist diese Anforderung unrealistisch. Ein System, das solchen Idealen nahekommt, wird wahrscheinlich viel Zeit für die Entwicklung und den Bau benötigen, teuer im Betrieb und zu gut für die Erwartungen von Benutzern sein, die mit weniger auskommen würden.
Verwenden Sie so wenige SLOs wie möglich
Wählen Sie eine ausreichende Anzahl von SLOs aus, um eine gute Abdeckung der Systemattribute sicherzustellen. Schützen Sie die von Ihnen gewählten SLOs: Wenn Sie einen Streit über Prioritäten durch die Angabe eines bestimmten SLO nie gewinnen können, lohnt es sich wahrscheinlich nicht, dieses SLO in Betracht zu ziehen. Allerdings sind nicht alle Systemattribute für SLOs zugänglich: Es ist schwierig, den Grad der Benutzerzufriedenheit mit SLOs zu berechnen.
Streben Sie nicht nach Perfektion
Sie können die Definitionen und Ziele von SLOs im Laufe der Zeit jederzeit verfeinern, indem Sie mehr über das Verhalten des Systems unter Last erfahren. Es ist besser, mit einem schwebenden Ziel zu beginnen, das Sie im Laufe der Zeit verfeinern, als ein zu strenges Ziel zu wählen, das gelockert werden muss, wenn Sie feststellen, dass es unerreichbar ist.
SLOs können und sollten ein wichtiger Treiber bei der Priorisierung der Arbeit für SREs und Produktentwickler sein, da sie ein Anliegen der Benutzer widerspiegeln. Ein gutes SLO ist ein nützliches Durchsetzungsinstrument für ein Entwicklungsteam. Aber ein schlecht gestaltetes SLO kann zu verschwenderischer Arbeit führen, wenn das Team heldenhafte Anstrengungen unternimmt, um ein zu aggressives SLO zu erreichen, oder zu einem schlechten Produkt, wenn das SLO zu niedrig ist. SLO ist ein mächtiger Hebel, setzen Sie ihn mit Bedacht ein.
Kontrollieren Sie Ihre Messungen
SLI und SLO sind Schlüsselelemente zur Verwaltung von Systemen:
- Überwachen und messen Sie SLI-Systeme.
- Vergleichen Sie SLI mit SLO und entscheiden Sie, ob Maßnahmen erforderlich sind.
- Wenn Handlungsbedarf besteht, überlegen Sie, was passieren muss, um das Ziel zu erreichen.
- Schließen Sie diese Aktion ab.
Wenn Schritt 2 beispielsweise zeigt, dass die Anforderung eine Zeitüberschreitung aufweist und das SLO in ein paar Stunden unterbrochen wird, wenn nichts unternommen wird, kann Schritt 3 das Testen der Hypothese beinhalten, dass die Server CPU-gebunden sind und das Hinzufügen weiterer Server die Last verteilt. Ohne einen SLO wüssten Sie nicht, ob (oder wann) Sie Maßnahmen ergreifen sollten.
SLO festlegen – dann werden die Benutzererwartungen festgelegt
Durch die Veröffentlichung eines SLO werden Benutzererwartungen an das Systemverhalten festgelegt. Benutzer (und potenzielle Benutzer) möchten häufig wissen, was sie von einem Dienst erwarten können, um zu verstehen, ob er für die Verwendung geeignet ist. Beispielsweise möchten Personen, die eine Foto-Sharing-Website nutzen möchten, möglicherweise die Nutzung eines Dienstes vermeiden, der Langlebigkeit und niedrige Kosten im Gegenzug für eine etwas geringere Verfügbarkeit verspricht, obwohl derselbe Dienst möglicherweise ideal für ein Archivverwaltungssystem ist.
Um Ihren Benutzern realistische Erwartungen zu vermitteln, verwenden Sie eine oder beide der folgenden Taktiken:
- Halten Sie einen Sicherheitsspielraum ein. Verwenden Sie ein strengeres internes SLO als das, was den Benutzern angekündigt wird. Dies gibt Ihnen die Möglichkeit, auf Probleme zu reagieren, bevor diese äußerlich sichtbar werden. Der SLO-Puffer ermöglicht Ihnen außerdem einen Sicherheitsspielraum bei der Installation von Releases, die sich auf die Systemleistung auswirken, und stellt sicher, dass das System einfach zu warten ist, ohne dass Benutzer durch Ausfallzeiten frustriert werden müssen.
- Übertreffen Sie nicht die Erwartungen der Benutzer. Benutzer basieren auf dem, was Sie anbieten, nicht auf dem, was Sie sagen. Wenn die tatsächliche Leistung Ihres Dienstes viel besser ist als das angegebene SLO, verlassen sich Benutzer auf die aktuelle Leistung. Sie können eine übermäßige Abhängigkeit vermeiden, indem Sie das System absichtlich herunterfahren oder die Leistung bei geringer Last einschränken.
Wenn Sie verstehen, wie gut ein System die Erwartungen erfüllt, können Sie entscheiden, ob Sie in die Beschleunigung des Systems und seine Zugänglichkeit und Widerstandsfähigkeit investieren sollten. Wenn ein Dienst jedoch zu gut funktioniert, sollte ein Teil der Zeit des Personals für andere Prioritäten aufgewendet werden, beispielsweise für die Tilgung technischer Schulden, das Hinzufügen neuer Funktionen oder die Einführung neuer Produkte.
Vereinbarungen in der Praxis
Bei der Erstellung eines SLA müssen Geschäfts- und Rechtsteams die Konsequenzen und Strafen für einen Verstoß festlegen. Die Aufgabe des SRE besteht darin, ihnen dabei zu helfen, die wahrscheinlichen Herausforderungen bei der Erfüllung der im SLA enthaltenen SLOs zu verstehen. Die meisten Empfehlungen zur Erstellung von SLOs gelten auch für SLAs. Es ist ratsam, bei dem, was Sie den Benutzern versprechen, konservativ zu sein, denn je mehr Sie haben, desto schwieriger ist es, SLAs zu ändern oder zu entfernen, die unangemessen oder schwer einzuhalten erscheinen.
Vielen Dank, dass Sie die Übersetzung bis zum Ende gelesen haben. Abonnieren Sie meinen Telegram-Kanal zum Thema Überwachung и .
Source: habr.com