Service Level Objectives (SLOs) auswählen

Last reviewed 2024-03-29 UTC

In diesem Dokument im Google Cloud-Architektur-Framework wird definiert, wie die Nutzerfreundlichkeit die Zuverlässigkeit definiert und wie die geeigneten Service Level Objectives ausgewählt werden, um dieses Zuverlässigkeitsniveau zu erreichen. Dieses Dokument basiert auf den Konzepten, die unter Komponenten von SLOs definiert sind.

Die Kultur des Site Reliability Engineering (SRE) schätzt zuverlässige Dienste und Kundenzufriedenheit (oder Kundenzufriedenheit). Ohne ein definiertes Service-Level und eine Methode zum Erfassen von Messwerten ist es schwierig (wenn nicht unmöglich), zu bestimmen, wo und wie viel in Verbesserungen investiert werden soll.

Der überschreibende Messwert, mit dem Sie das Service Level messen, ist das Service Level Objective (SLO). Ein SLO besteht aus den folgenden Werten:

  • Service Level Indicator (SLI): Ein Messwert für einen bestimmten Aspekt Ihres Dienstes, wie unter SLIs auswählen beschrieben.
  • Dauer: Das Zeitfenster, in dem der SLI gemessen wird. Dies kann kalenderbasiert oder ein rollierendes Zeitfenster sein.
  • Ziel: Der Wert (oder Wertebereich), den der SLI innerhalb des angegebenen Zeitraums in einem fehlerfreien Dienst erreichen soll. Beispiel: Der Prozentsatz der fehlerfreien Ereignisse an den Gesamtereignissen, die Ihr Dienst erfüllen sollte, z. B. 99,9%.

Die Auswahl der richtigen SLOs für Ihren Dienst ist ein Prozess. Zuerst definieren Sie die Kaufprozesse, die die Zuverlässigkeit und letztendlich Ihre SLOs definieren. Die ausgewählten SLOs müssen das gesamte System messen und gleichzeitig die Anforderungen der Featureentwicklung mit der Betriebsstabilität in Einklang bringen. Nachdem Sie Ihre SLOs ausgewählt haben, müssen Sie sie sowohl iterativ verbessern als auch mithilfe von Fehlerbudgets verwalten.

Kaufprozesse definieren

Ihre SLIs und SLOs basieren ideal auf kritischem Nutzerverhalten (CUJs). CUJs berücksichtigen Nutzerziele und wie Ihr Dienst Nutzern hilft, diese Ziele zu erreichen. Sie definieren einen CUJ, ohne Dienstgrenzen zu berücksichtigen. Wenn ein CUJ erfüllt ist, ist der Kunde zufrieden. Dies ist ein Hinweis auf einen erfolgreichen Dienst.

Die Zufriedenheit oder Unzufriedenheit der Kunden in dieser Frage bestimmt die Zuverlässigkeit und ist das wichtigste Merkmal eines Dienstes.

Legen Sie das SLO daher nur so hoch fest, dass die meisten Nutzer mit Ihrem Dienst zufrieden sind, und nicht höher. So wie 100% Verfügbarkeit nicht das richtige Ziel ist, wird das Hinzufügen weiterer "Neunen" zu Ihren SLOs schnell teuer und ist möglicherweise für den Kunden gar nicht wichtig.

Versuchen Sie bei der Verfügbarkeit und anderen wichtigen Messwerten ein Ziel von weniger als 100 %, aber nahe daran zu erreichen. Beurteilen Sie das erforderliche Mindestniveau an Dienstleistung und -verfügbarkeit. Legen Sie keine Ziele auf der Grundlage von externen vertraglichen Ebenen fest.

CUJs zum Entwickeln von SLOs verwenden

Wählen Sie die wichtigsten CUJs Ihres Unternehmens aus und führen Sie die folgenden Schritte aus, um SLOs zu entwickeln:

  1. Wählen Sie eine SLI-Spezifikation aus (z. B. Verfügbarkeit oder Aktualität).
  2. Entscheiden Sie, wie die SLI-Spezifikation implementiert werden soll.
  3. Achten Sie darauf, dass Ihr Plan alle CUJs abdeckt.
  4. Legen Sie SLOs basierend auf früherer Leistung oder geschäftlichen Anforderungen fest.

CUJs sollten nicht auf einen einzelnen Dienst oder ein einzelnes Entwicklungsteam oder eine einzelne Organisation beschränkt sein. Ihr Dienst kann von Dutzenden oder mehr anderen Diensten abhängen. Man kann auch davon ausgehen, dass diese Dienste bei 99,5 % funktionieren. Wenn jedoch die End-to-End-Leistung (gesamtes System) nicht verfolgt wird, ist die Ausführung eines zuverlässigen Dienstes schwierig.

Ziel und Dauer definieren

Die Definition von Ziel und Dauer (siehe vorherige Definition eines SLO) kann schwierig sein. Eine Möglichkeit, den Prozess zu beginnen, besteht darin, SLIs zu identifizieren und sie im Zeitverlauf grafisch darzustellen. Denken Sie daran, dass ein SLO nicht von Anfang an perfekt sein muss. Wiederholen Sie Ihr SLO, damit es mit der Zufriedenheit der Kunden übereinstimmt und Ihren Geschäftsanforderungen entspricht.

Wenn Sie die SLO-Compliance bei Ereignissen wie Bereitstellungen, Ausfällen und täglichen Trafficmustern verfolgen, erhalten Sie Informationen zum Ziel. Anhand dieser Erkenntnisse wird klarer, was für Ihre Ziele und Dauer gut, schlecht oder tolerierbar ist.

Featureentwicklung, Codeverbesserungen, Hardware-Upgrades und andere Wartungsaufgaben können die Zuverlässigkeit Ihres Dienstes verbessern. Die Möglichkeit, diese häufigen, kleinen Änderungen vorzunehmen, hilft Ihnen, Features schneller und mit höherer Qualität bereitzustellen. Die Geschwindigkeit, mit der sich der Dienst ändert, wirkt sich jedoch auch auf die Zuverlässigkeit aus. Erreichbare Ziele für die Zuverlässigkeit definieren das Tempo und den Umfang der Änderung (Feature-Geschwindigkeit genannt), die Kunden tolerieren und profitieren können.

Wenn Sie die Kundenerfahrung nicht messen und keine Ziele definieren können, können Sie auf externe Quellen und Benchmark-Analysen zurückgreifen. Wenn keine vergleichbare Benchmark vorhanden ist, sollten Sie die Kundenerfahrung messen, auch wenn Sie noch keine Ziele definieren können. Mit der Zeit können Sie einen angemessenen Schwellenwert für die Zufriedenheit der Kunden erreichen. Dieser Schwellenwert ist Ihr SLO.

Das gesamte System verstehen

Ihr Dienst kann in einer langen Dienstreihe mit vor- und nachgelagerter Verarbeitung vorhanden sein. Die einzelne Leistungsmessung eines verteilten Systems (Dienst für Dienst) spiegelt die Erfahrung Ihrer Kunden nicht getreu wider und kann zu einer Interpretation führen, bei der zu viele Faktoren berücksichtigt wurden.

Stattdessen sollten Sie die Leistung anhand des SLO am Frontend des Prozesses messen, um nachzuvollziehen, welche Erfahrung die Nutzer machen. Der Nutzer ist nicht besorgt über einen Komponentenfehler, der dazu führt, dass eine Abfrage fehlschlägt, wenn die Abfrage automatisch und erfolgreich wiederholt wird.

Wenn freigegebene interne Dienste vorhanden sind, kann jeder Dienst die Leistung separat anhand des zugehörigen SLO messen, wobei für den Nutzer sichtbare Dienste als Kunden fungieren. Behandeln Sie diese SLOs separat.

Sie können einen hochverfügbaren Dienst (z. B. mit 99,99 % Verfügbarkeit) auf Basis eines weniger gut verfügbaren Dienstes erstellen (z. B. mit 99,9 % Verfügbarkeit), indem Sie Belastbarkeitsfaktoren wie die intelligente Wiederholungsfunktion, das Caching und das Stellen von Aufgaben in die Warteschlange verwenden. Jeder mit statistischen Kenntnissen sollte Ihr SLO lesen und verstehen können, ohne den zugrunde liegenden Dienst oder das Organisationslayout zu verstehen, wie im Gesetz von Conway beschrieben.

Die richtigen SLOs auswählen

Es gibt einen natürlichen Zusammenhang zwischen der Geschwindigkeit der Produktentwicklung und der operativen Stabilität. Je mehr Sie Ihr System ändern, desto größer ist die Wahrscheinlichkeit, dass es abstürzt. Monitoring- und Beobachtbarkeitstools sind für die Betriebsstabilität von entscheidender Bedeutung, wenn Sie die Feature-Geschwindigkeit erhöhen. Diese Tools werden als APM-Tools (Application Performance Management) bezeichnet und können auch zum Festlegen von SLOs verwendet werden.

Bei korrekter Definition hilft ein SLO Teams dabei, datengestützte Betriebsentscheidungen zu treffen, die die Entwicklungsgeschwindigkeit erhöhen, ohne die Stabilität zu beeinträchtigen. Das SLO kann auch Entwicklungs- und Betriebsteams auf ein einziges vereinbartes Ziel ausrichten. Durch die gemeinsame Nutzung eines einzigen Ziels wird die zuvor erwähnte natürliche Spannung abgemildert: das Ziel des Entwicklungsteams, Produkte zu erstellen und zu iterieren, und das Ziel des operativen Teams, die Systemintegrität aufrechtzuerhalten.

Verwenden Sie dieses Dokument und andere Zuverlässigkeitsdokumente im Architektur-Framework, um SLOs zu verstehen und zu entwickeln. Sobald Sie diese Artikel gelesen und verstanden haben, finden Sie ausführlichere Informationen zu SLOs (und anderen SRE-Praktiken) im The SRE Book und The SRE Workbook

Strikte interne SLOs verwenden

Es empfiehlt sich, interne SLOs höher als externe SLAs festzulegen. Da SLA-Verstöße in der Regel dazu führen, dass Finanzgutschriften oder Kundenerstattungen veranlasst werden muss, sollten Sie eventuelle Probleme beheben, bevor sie finanzielle Auswirkungen haben.

Wir empfehlen, diese strengeren internen SLOs mit einem Aufarbeitungsprozess und einer Vorfallprüfung ohne Schuldzuweisung zu verwenden. Weitere Informationen finden Sie unter Kollaboratives Vorfallmanagement erstellen in der Kategorie „Zuverlässigkeit für das Architecture Framework“.

SLOs iterativ verbessern

SLOs sollten nicht in Stein gemeißelt sein. Überprüfen Sie die SLOs regelmäßig – vierteljährlich oder mindestens einmal pro Jahr – und bestätigen Sie, dass sie die Zufriedenheit der Nutzer genau widerspiegeln und mit Dienstausfällen korrelieren. Gewährleisten Sie, dass sie die aktuellen Geschäftsanforderungen und neues kritisches Nutzerverhalten abdecken. Überarbeiten Sie Ihre SLOs und erweitern Sie sie nach Bedarf nach diesen Prüfungen.

Nutzen Sie Fehlerbudgets, um die Entwicklungsgeschwindigkeit zu steuern.

Fehlerbudgets geben an, ob Ihr Dienst für ein bestimmtes Zeitfenster mehr oder weniger zuverlässig ist als erforderlich. Fehlerbudgets werden als 100 % – SLO über einen bestimmten Zeitraum, z. B. 30 Tage, berechnet.

Wenn in Ihrem Fehlerbudget noch Kapazitäten vorhanden sind, können Sie weiterhin schnell Verbesserungen oder neue Funktionen einführen. Wenn das Fehlerbudget fast null ist, können Sie Dienständerungen verlangsamen oder einfrieren und technische Ressourcen für die Verbesserung von Zuverlässigkeitsfeatures nutzen.

Google Cloud Observability bietet SLO-Monitoring, um den Aufwand für die Einrichtung von SLOs und Fehlerbudgets zu minimieren. Operations-Suite enthält eine grafische Benutzeroberfläche, mit der Sie SLOs manuell konfigurieren können, eine API für die programmatische Einrichtung von SLOs und integrierte Dashboards, um die Burn-Rate des Fehlerbudgets zu verfolgen. Weitere Informationen finden Sie unter SLO erstellen.

Zusammenfassung der SLO-Empfehlungen

  • Definieren und messen Sie kundenorientierte SLIs wie die Verfügbarkeit oder Latenz des Dienstes.
  • Definieren Sie ein kundenorientiertes Fehlerbudget, das strenger als Ihr externes SLA ist. Schließen Sie Konsequenzen für Verstöße wie Produktionsstopps ein.
  • Richten Sie Latenz-SLIs zum Erfassen von Ausreißerwerten ein, z. B. das 90. oder 99. Perzentil, um die langsamsten Antworten zu erkennen.
  • Prüfen Sie die SLOs mindestens einmal pro Jahr und vergewissern Sie sich, dass sie gut mit der Zufriedenheit der Nutzer und mit Dienstausfällen korrelieren.

Nächste Schritte