Was sind Service Level Objectives und Service Level Indicators (SLOs/SLIs)? 

Was ist der Unterschied zwischen Service Level Objectives (SLOs) und Service Level Indicators (SLIs)?

Service Level Objectives (SLOs) definieren Ziele für bestimmte Metriken, während Service Level Indicators (SLIs) die laufenden Messwerte dieser Metriken widerspiegeln. Aufgrund des engen Zusammenhangs zwischen diesen beiden Begriffen werden sie oft verwechselt. Am einfachsten ist es, sich einen SLO als Ziel- oder Idealwert vorzustellen, den ein Service erreichen soll: ein Perzentil, wie etwa 99,999 % Uptime oder 0,0001 % Ausfallzeit. In einem Dashboard mit einer Skala von 0 bis 100 % würde in diesem Fall eine Markierung bei 99,999 % den SLO anzeigen. Der SLI wäre in diesem Bespiel die Nadel der Skala, deren Position sich über einen bestimmten Zeitraum hinweg verändert. Wenn die Nadel unter die 99,999 %-Marke fällt, wurde eine Leistungsschwelle unterschritten. Dies löst eine Benachrichtigung aus und bewirkt, dass der Site Reliability Engineer Maßnahmen ergreift. Als Teil eines umfassenderen Ökosystems für das Service Level-Management kann es keine SLOs ohne SLIs geben und umgekehrt.

Wie wird ein SLI berechnet?

SLIs werden als Prozentsatz der Gesamtzahl an Events berechnet, der als akzeptabel angesehen wird. Wenn Sie die Gesamtzahl der erfolgreich abgeschlossenen HTTP-Anfragen messen, würde die Formel für den entsprechenden SLI wie folgt lauten:

(Erfolgreiche Anfragen : Anfragen gesamt) x 100

Sie könnten auch einen SLI verwenden, mit dem gemessen wird, ob ein Server zu langsam wird. Das Unternehmen würde dazu einen Mindestwert für die Latenzzeit festlegen – sagen wir 400 Millisekunden – und den SLI wie folgt berechnen:

(In weniger als 400 Millisekunden abgeschlossene Anfragen : Anfragen gesamt) x 100

Ein SLI muss über einen bestimmten Zeitraum berechnet werden, z. B. eine Minute, eine Stunde oder einen ganzen Monat. SLOs werden in der Regel für ziemlich lange Zeiträume angegeben. Für Amazon Compute-Services wird beispielsweise eine monatliche Uptime von mindestens 95 % versprochen. Erreicht der Service diesen Wert nicht, bekommen die Kunden den Rechnungsbetrag zu 100 % gutgeschrieben. Die Beurteilung eines SLI über einen kürzeren Zeitraum kann bei der Fehlersuche nützlich sein, aber um die Einhaltung von SLAs zu gewährleisten, sollten Unternehmen auch einen SLI mit einem größeren Zeitrahmen definieren.

Was macht gute SLOs aus?

Die Eigenschaften eines guten Service Level Objective wurden ursprünglich von Rick Sturm, Wayne Morris und Mary Jander in ihrem im Jahr 2000 erschienenen Buch „Foundations of Service Level Management“ beschrieben. Nach Aussagen der Autoren sind folgende Eigenschaften wichtig für gute SLOs:

• Erreichbarkeit: Ein SLO von 100 % ist praktisch nicht erreichbar, stellt damit ein theoretisches Ziel dar und ist kein sinnvolles SLO. SLOs sollten ein Minimum an akzeptablem Leistungsniveau darstellen und nicht als „unmöglich“ gelten.
• Aussagekraft: Viele Unternehmen legen SLOs für Metriken fest, die gar nicht aussagekräftig für sie sind. Als Beispiel für ein wenig aussagekräftiges SLO wird oftmals die CPU-Auslastung genannt, da sie für die meisten Unternehmen und Benutzer irrelevant ist.
• Messbarkeit: Wenn sich eine Metrik nicht genau messen lässt, ist sie als SLO nicht sinnvoll.
• Kontrollierbarkeit: Ein SLO, das eine Höchstgrenze für die Anzahl der Blitzeinschläge in ein Rechenzentrum festlegt, wäre beispielsweise nicht sinnvoll.
• Verständlichkeit: Manche Metriken sind für das IT-Management nicht unmittelbar relevant. So ist zum Beispiel die Zahl der Paketkollisionen ein häufig verwendetes Kriterium für die Systemleistung, das Benutzer jedoch nicht wirklich einordnen können und daher nicht als SLO verwendet werden sollte.
• Bezahlbarkeit: Braucht ein Unternehmen wirklich 99,9999 % Uptime, wenn 99,99 % akzeptabel sind? Wenn ein Unternehmen in mehrere redundante Rechenzentren, Failover-Protokolle und zusätzliches Personal investieren muss, um die Erfüllung des SLOs sicherzustellen, überwiegen die dafür nötigen Investitionskosten wahrscheinlich bei weitem den Nutzen, den das Unternehmen aus den zusätzlichen 52 Minuten Uptime zieht.
• Gegenseitige Akzeptanz: Allen beteiligten Parteien – in der Regel Serviceanbieter und Kunde – müssen sich auf die SLOs einigen.

Nachdem ein SLO gewählt wurde, muss der geeignete Wert für diesen SLO festgelegt werden. Dies ist Teil der Verhandlungen zwischen dem Serviceanbieter und dem Kunden (ob intern oder extern), obwohl SLOs in vielen Fällen eventuell als fixe, nicht verhandelbare Werte dargestellt werden.

Letztendlich ist es wichtig zu verstehen, dass ein SLO niemals als Ideal- oder Höchstwert für eine Metrik angesehen werden sollte, sondern eher als ein akzeptables Mindestmaß für das Unternehmen, mit dem es seine Geschäftsziele erreichen kann.

Was ist die Fehlerquote bei SLIs?

Die Fehlerquote eines SLI ist der Anteil der Aktivitäten, der unter dem Mindestwert des SLO liegt. Anders ausgedrückt: Die Fehlerquote ist der Kehrwert des SLI: 1 - SLI = Fehlerquote.

Die Fehlerquote (manchmal auch Fehlerbudget genannt) ist einfach eine andere Art, Leistungskennzahlen zu betrachten. Eine Uptime von 99 % pro Monat ist vielleicht verständlicher (und eindrücklicher), wenn sie als Fehlerquote von 1 % Ausfallzeit pro Monat ausgedrückt wird, vor allem, wenn das SLO bei 99,999 % Betriebszeit (bzw. einer Fehlerquote von 0,001 %) liegt. Man könnte dies auch quantitativ ausdrücken, z. B. als Fehlerquote von 7,2 Stunden pro Monat.

Das Konzept des Fehlerbudgets gibt dem IT-Management die nötigen Instrumente an die Hand, um strategischere Entscheidungen über Ausfall- und Latenzzeiten zu treffen. Wenn das Management beispielsweise weiß, dass ein Server unbedingt offline genommen werden muss, ohne dass Ersatz zur Verfügung steht, und dass das Unternehmen ein Fehlerbudget von 7,2 Stunden pro Monat an zulässiger Ausfallzeit hat, dann können diese Metriken während der Ausfallzeit angestrebt werden.

Wie definiert man Service Level Agreements (SLAs)?

Service Level Agreements (SLAs) sind formelle Vereinbarungen – entweder zwischen einem Unternehmen und einer zweiten Partei inner- oder außerhalb des Unternehmens – die Service Level Objectives (SLOs) für einen bereitgestellten Services festlegen. SLAs formalisieren SLOs und legen, wenn sie mit einem Serviceanbieter (meist einem Cloud-Serviceanbieter) vereinbart werden, in der Regel Sanktionen für das Nichterreichen eines SLOs fest.

Externe SLAs beinhalten auch andere Vertragsbedingungen, wie z. B. den notwendigen Mechanismus für die Beantragung von Gutschriften oder Rückerstattungen, Ausschlüsse bestimmter Ereignisse (z. B. Fehler des Kunden), eine formale Definition der Berechnung von SLIs und Prozesse für die Beendigung oder Änderung der SLAs.

Rechtsabteilungen, Incident Response- oder Engineering-Teams können interne SLAs nutzen, um die Effektivität interner Abläufe wie Service Desk Operations, interne Netzwerkleistung und -Uptime oder sogar den Anteil betrugsbedingter Rückerstattungen zu messen.

Welcher Zusammenhang besteht zwischen KPIs und SLAs?

KPIs (Key Performance Indicators) sind Kennzahlen, die die Leistung eines realen Geschäftsprozesses messen. Der Begriff kann im weitesten Sinne auf Prozesse, Systeme oder sogar einzelne Mitarbeiter angewandt werden. In der IT werden KPIs meist verwendet, um die Systemleistung in einem internen oder externen Netzwerk zu definieren, und sie haben idealerweise einen direkten Bezug zu Geschäftsergebnissen. So steht beispielsweise die Uptime einer E-Commerce-Website in direktem Zusammenhang mit dem Umsatz, der durch diese Website erzielt wird, und beide Werte können hier als KPI verwendet werden.

KPIs und SLIs stehen in enger Beziehung, und die Begriffe werden in SLA-Vereinbarungen oft gleichbedeutend verwendet. Es gibt allerdings auch die Auffassung, dass KPIs rein quantitativ verwendet werden sollten, während SLIs abstrakter gefasst sein und ein gewisses Maß an Rückschlüssen auf das Kundenerlebnis und eine strategischere Perspektive bieten sollten, anstatt nur die Leistung zu messen.

Wie definiert ein Site Reliability Engineer SLOs, SLIs und SLAs?

Ein Site Reliability Engineer (SRE) betrachtet SLOs, SLIs und SLAs aus einem speziellen Blickwinkel. Da SREs im Wesentlichen die Aufgabe haben, die Verfügbarkeit von Netzwerk und Services sicherzustellen, legen sie bei diesen Service Level-Metriken den Schwerpunkt auf Uptime und Zuverlässigkeit. Ein System, das nicht verfügbar ist, ist nicht zuverlässig, und daher werden SLAs darauf ausgelegt, die maximale Verfügbarkeit zu gewährleisten. SREs untersuchen SLIs in Echtzeit, um die Systembedingungen zu überwachen, und analysieren historische SLIs, um festzustellen, ob und wann ein System in der Zukunft wahrscheinlich ausfallen wird. Bei diesen Analysen können KI-Tools von großem Nutzen sein.

Wie bei jedem SLO steigen mit der erforderlichen Verfügbarkeit auch die Kosten. Jedem SRE ist klar, dass eine Verfügbarkeit von 100 % ein Ding der Unmöglichkeit ist. In vielen Fällen sind 100 % Uptime weder angemessen noch erwünscht. Bei vielen Services sind geplante Ausfallzeiten beabsichtigt. Sie verhindern, dass man sich zu sehr auf die Verfügbarkeit eines einzelnen Services verlässt oder überzogene Erwartungen entstehen, und können auch dazu beitragen, eine missbräuchliche Nutzung und Sicherheitsverstöße aufzudecken und zu verhindern.

Was sind verschiedene Einsatzmöglichkeiten für SLOs und SLIs?

SLOs und SLIs werden in vielen Business- und Technologie-Anwendungen eingesetzt, und zwar sowohl intern als auch extern. SLOs werden häufig genutzt, um die Leistung und Zuverlässigkeit verschiedener SaaS-Produkte zu messen, z. B. die Uptime bei Web-Hosting, die Verfügbarkeit von Cloud-Speicher und die Latenz oder Reaktionsgeschwindigkeit verschiedener Hosting-Services für Cloud-Anwendungen. Obwohl SLOs in der Regel in den Verträgen zwischen Anbietern und Cloud-Service-Unternehmen festgelegt werden, liegt es oft in der Verantwortung des Kunden, sie zu überwachen, um die Einhaltung der angegebenen SLOs sicherzustellen.

Typische Einsatzmöglichkeiten für SLIs sind:

• Server-Uptime: Wie oft ist ein Server oder Web-Service verfügbar und reaktionsfähig?
• Server-Latenz: Wie lange brauchte der Server oder Service, um auf eine Anfrage zu antworten?
• Fehlerquote: Wie oft führte eine Anfrage (z. B. an einen Webserver) zu einem Fehler?
• Durchsatz/Leistung: Wie schnell werden Daten über einen bestimmten Kanal übertragen?
• Nutzung: Wie oft wird ein bestimmter Service verwendet?
• Aktualität der Daten: Welcher Anteil der Daten, die Benutzern zur Verfügung gestellt werden, ist die aktuellste Version der Daten?

SLIs können auch verwendet werden, um die Leistung von Mitarbeitern zu messen. Zum Beispiel:

• Reaktionsgeschwindigkeit des Service Desk: Wie schnell werden Help Desk-Anrufe beantwortet (oder gelöst)?
• Eskalationsstufe: Wie oft werden Help Desk-Anrufe auf eine höhere Stufe eskaliert?

Damit diese SLIs wirklich nützlich sind, sollten sie über einen bestimmten Zeitraum gemessen und ihre Benchmarks mit entsprechenden SLOs verglichen werden, um einen Mindestschwellenwert für diese Metriken festzulegen.

Wofür braucht man SLOs?

SLOs sind wichtig, um sicherzustellen, dass ein Unternehmen die Services erhält, für die es bezahlt. SLOs messen die Leistung Ihrer internen Systeme und Mitarbeiter und können sogar die Erwartungen und die Zufriedenheit der Kunden quantifizieren. Ohne SLOs hat ein Unternehmen keine Möglichkeit, diese Leistungsmetriken zu überwachen und festzustellen, ob die Bedingungen gut oder schlecht sind bzw. sich verbessern oder verschlechtern.

In Sachen Web-Services und -Anwendungen sind Endnutzer heute anspruchsvoller denn je. Kurze Ausfallzeiten und geringfügige Latenzprobleme scheinen vernachlässigbar zu sein, werden aber von erfahrenen Online-Benutzern sehr wohl registriert. Tatsächlich können Latenzzeiten von mehr als einer Sekunde dazu führen, dass sich Benutzer nicht mehr auf ihre aktuelle Aufgabe konzentrieren. Nach 10 Sekunden besteht die Wahrscheinlichkeit, dass die Benutzer so frustriert sind, dass sie die Aufgabe, die sie gerade durchführen, komplett aufgeben.

Es ist eine zunehmend wichtige Funktion in jedem Unternehmen, eine reaktionsschnelle, fehlerfreie Nutzungserfahrung sicherzustellen. Die effektivste Methode, mit der ein Unternehmen dringend notwendige, quantifizierbare Erkenntnisse zu seiner kundenseitigen Service-Umgebung erhält, ist das Monitoring von SLIs und deren Abgleich mit SLOs.

Was sind die ersten Schritte zum Implementieren von SLOs und SLIs?

SLOs und SLIs sind für nahezu alle Unternehmen wichtig. Um die Implementierung auf den Weg zu bringen, benötigen Sie ein tiefes Verständnis dafür, wie Ihre verschiedenen Systeme funktionieren und wie Mitarbeiter und Kunden damit interagieren. Es ist entscheidend, dass Sie Ihre Architektur und deren Rolle im Zusammenhang mit der Kundenerfahrung verstehen.

Ganz allgemein ist es ratsam, mit den Grundlagen zu beginnen. Einfache SLOs rund um die Verfügbarkeit und Latenz von Netzwerken und Services sind nicht ohne Grund die gängigsten SLOs: Sie sind einfach zu berechnen, leicht zu verstehen und haben eine spürbare und offensichtliche Auswirkung auf den Benutzer. Die Festlegung spezifischer SLO-Ziele kann etwas schwieriger sein, aber durch SLI-Monitoring und die Iteration über die Zeit können Analysten SLOs feinabstimmen, um den Wert zu bestimmen, der den maximalen Nutzen für das Unternehmen bietet.

Es ist auch wichtig zu wissen, dass SLOs und SLIs in vielen Unternehmen nicht intern festgelegt werden. Sie sind Teil der SLAs, die von den Anbietern formuliert werden. Für kleinere Unternehmen sind diese SLOs wahrscheinlich nicht verhandelbar, sie stellen aber trotzdem wichtige Metriken dar, die das Unternehmen im Auge behalten sollte.

Was sind einige wichtige Leitlinien bzw. Best Practices im Zusammenhang mit SLOs/SLIs?

Einige wichtige Best Practices für die Festlegung und Verwaltung von SLOs und SLIs lauten wie folgt:

• Konzentration auf relevante Kennzahlen: Stellen Sie sicher, dass die SLOs relevant sind und echte Auswirkungen für den Kunden haben.
• Verständlichkeit ist wichtig: SLOs sollten auch für Beteiligte außerhalb der IT-Abteilung leicht verständlich sein. Wählen Sie also SLOs, die auf die Geschäfts- und Kundenanforderungen abgestimmt sind.
• Überprüfbarkeit von SLIs sicherstellen: Sie sollten SLIs regelmäßig überprüfen, um sicherzustellen, dass sie richtig gemessen werden. Wenn Dashboards zeigen, dass ein Verfügbarkeits-SLO erfüllt wird, Benutzer sich jedoch darüber beschweren, dass Services offline sind, dann sollten Sie prüfen, wie Ihre Metriken generiert werden.
• Gesamtzahl der SLOs minimieren: Achten Sie darauf, Ihr Dashboard nicht mit SLOs zu überfrachten. Stellen Sie sicher, dass nur die relevantesten, sich nicht überschneidenden Metriken dargestellt werden, um die Anzeige übersichtlich zu gestalten und den Nutzen des Systems zu maximieren.
• Handeln, wenn SLOs nicht erfüllt werden: Handeln Sie sofort, um festzustellen, warum der SLI unter den erwarteten Wert gefallen ist, und erstellen Sie umgehend einen Plan mit Korrekturmaßnahmen.
• Alle SLOs regelmäßig überprüfen: Unternehmen und Technologien ändern sich, manchmal sogar dramatisch. Ein SLO, das im Vorjahr noch relevant war, kann heute veraltet oder irrelevant sein.

Kunden sind anspruchsvoller denn je, und eine der eindeutigsten Methoden, die Qualität der Kundenerfahrung zu messen, ist die Verwendung von SLOs und SLIs. Durch die sorgfältige Kontrolle von SLOs und der zugehörigen SLIs kann ein Unternehmen sicherstellen, dass die Systeme den Erwartungen entsprechen, die Kunden zufrieden sind und der Gewinn maximiert wird.