SLI, SLO, SLA: Ein Weg durch das Begriffs-Dickicht

SLI, SLO, SLA: Ein Weg durch das Begriffs-Dickicht

Um die Qualität eines an Benutzer:innen ausgelieferten Service über einen bestimmten Zeitraum zu quantifizieren, braucht es eine klare Bemessungsgrundlage. Genau diese Funktion erfüllen Service-Levels bzw. die drei Kategorien, in die sie sich unterteilen: Als Maßgabe dafür, welche Verfügbarkeit ein System aufweisen muss, werden Service-Level Objectives (SLOs) bzw. Service-Level-Ziele definiert. Um diese Maßgabe messbar darstellen zu können, werden hierfür relevante Metrics bestimmt. Dies sind die Service-Level-Indikatoren (SLIs). Damit klar ist, was im Falle der Nichterfüllung der SLO-Ziele geschieht, wird mit Service-Level Agreements (SLAs) schließlich ein vertraglicher Rahmen festgelegt.

So könnte ein SLO für eine Web-Anwendung etwa lauten, dass der Abspielvorgang von Videos über einen Zeitraum von einer Woche zu 99 % der Zeit in unter 2 Sekunden zu starten begonnen haben muss. Über den SLI wird dabei der Anteil an Videos gemessen, bei denen der Abspielvorgang tatsächlich in unter 2 Sekunden gestartet wurde. Im SLA sind dieser SLO sowie diverse weitere Zielvorgaben festgehalten, die zwischen Kund:in und Anbieter des Service vereinbart werden. Ebenfalls darin erfasst ist der Umfang der Services, die abgedeckt werden, sowie die zur Performance-Messung verwendeten Metrics in Form von SLIs.

In diesem Kontext hat Site Reliability Engineering (SRE) zum Ziel, Best Practices zu etablieren, die zur Gewährleistung von Uptime und Verlässlichkeit verteilter Systeme beitragen. Im Fokus steht dabei die Quantifizierung der Performance und Verlässlichkeit, die ein Service aufweist. Eines der Referenz-Frameworks hierfür stammt von Google, das im März 2016 mit Site Reliability Engineering: How Google Runs Production Systems ein umfassendes Handbuch dazu veröffentlichte. Den ersten Punkt bilden darin die Modellierung, Auswahl und Analyse der Metrics rund um Service-Level-Ziele.

Wie aber stehen SLOs, SLIs und SLAs miteinander in Zusammenhang, wenn es darum geht, das von Benutzer:innen erwartete Service-Level zu gewährleisten? Eine Antwort darauf liefert ein separater Blick auf die drei.

An SLA is typically created by the business and legal teams, working with the customer (for specific contracts). Providers also present general SLAs for their services, such as cloud service providers for their different instance types. SLAs can include multiple SLOs, the scope of services that will be covered, and the SLIs used to measure performance.

SLOs, SLIs, and SLAs help ensure a quality of service from a set of technologies. All influencers of SLOs, SLIs, and SLAs should be consulted to help be sure goals are attainable and customers are satisfied.

Was sind SLOs?

SLOs sind die Ziele, die ein System in punkto Verfügbarkeit zu erfüllen hat. Gemessen wird dies als Prozentwert über einen bestimmten Zeitraum. 

Service-Level-Ziele bilden eine für alle Teams nachvollziehbare Maßgabe dafür, welche Verfügbarkeit und Uptime ein Service aufweisen muss. SLOs bilden also den Standard, nach dem Verlässlichkeit und Verfügbarkeit in Zahlen ausgedrückt werden. In unserem eingangs erwähnten Beispiel etwa betraf dies den Abspielvorgang von Videos innerhalb einer Web-Anwendung: Zu 99 % des Zeitraums von einer Woche musste dieser innerhalb von weniger als 2 Sekunden gestartet worden sein.

Was sind SLIs?

SLIs fungieren als quantitative Messgröße dazu, wie die Verfügbarkeit eines Systems von seinen Benutzer:innen wahrgenommen wird. Angegeben als Prozentwert, drücken sie den Anteil aus, zu dem die Systemausgaben im Rahmen eines Service-Levels erfolgreich waren. 

Dargestellt werden Service-Level-Indikatoren zwar im Verhältnis zu SLOs und somit zu Zielen, doch repräsentieren sie die Systemverfügbarkeit zum gegenwärtigen Zeitpunkt. So wird mit ihnen etwa der Anteil an Anfragen gemessen, die schneller als ein definierter Threshold-Wert oder als der Anteil an Anfragen ausgeführt wurden, die für das Erreichen des definierten Ziels erfüllt werden müssen. Um hierzu noch einmal unser Beispiel von zuvor aufzugreifen: Dort haben wir als SLI den Anteil an Videos gemessen, bei denen der Abspielvorgang in unter 2 Sekunden gestartet wurde. Wir erhalten über ihn also Aufschluss darüber, wie weit wir von unserem als SLO definierten Zielwert entfernt sind.

Was sind SLAs?

Mit einem Service-Level Agreement bzw. SLA wird das Niveau der Qualität festgelegt, das ein von Kund:innen genutzter Service aufweisen muss.

Es bildet einen Rahmenvertrag zwischen Service-Anbieter und Kund:in, in dem neben den Arten der Services, die ausgeliefert werden, auch die Standards festgehalten werden, die der Anbieter zu erfüllen hat. Analog dazu beinhaltet es auch die vom Anbieter zu leistenden Nachbesserungen oder ihm auferlegten Sanktionen für den Fall, dass diese SLO-Ziele verfehlt werden.

Im Kontext der Web-Anwendung aus unserem Beispiel würde das SLA dann Folgendes umfassen: sämtliche ihm zugehörige SLOs, den Umfang der von ihm abgedeckten Services sowie die als SLIs definierten Metrics, anhand derer die Performance im Verhältnis zu den SLO-Zielwerten gemessen wird. Vertraglich festgelegt sind neben dem Leistungsspektrum des Anbieters darüber hinaus auch Pflichten, die auf Kundenseite zu erfüllen sind.

Der nachfolgende Screenshot zeigt beispielhaft, wie SLIs zur CX in Echtzeit erfasst und SLO-Zielen gegenübergestellt werden:

Für wen sind SLOs, SLIs und SLAs relevant?

Bereits die Bestimmung, was die Verlässlichkeit von Services ausmacht, stellt SRE-Teams, Reliability Engineers und funktionsübergreifende Teams oft vor erhebliche Probleme. Gleiches gilt für ihre Ermittlung. Denn was es hierzu braucht, ist eine umfassend aggregierte Sicht, die sämtliche für Services oder Systeme relevanten Metrics transparent und so eine klare Quantifizierung der Uptime und Performance möglich macht.

Ein Instrument hierfür bilden Service-Levels: Mit ihnen spezifizieren SRE-Teams und Reliability Engineers all jene Komponenten, die im Anwendungs- und Infrastrukturkontext eine kritische Rolle spielen. Ein besonderer Fokus gilt dabei Punkten, an denen durch eine oder mehrere Komponenten Funktionalitäten für externe Kund:innen umgesetzt werden. An diesen Schnittpunkten, Systemgrenzen genannt, gilt es, die Metrics für Service-Level-Indikatoren und -Ziele zu definieren. Diese liefern dann ein aussagekräftiges und objektives Maß zur System-Performance und -zuverlässigkeit. 

Transparenz für diese Aspekte ist jedoch zentral, wenn es darum geht, die Grenzen von Service-Levels abzustecken und festzustellen, welche Metrics in SLIs aufzunehmen und wie die Maßgaben für die SLO-Erfüllung zu formulieren sind. Daher stellt sich bei der Thematik nicht selten Überforderung ein, sodass sie letztlich gar nicht mehr weiter verfolgt wird. Hier gilt es also, Reliability Engineers und SRE-Teams mit Möglichkeiten auszustatten, über die sie die System-Performance im historischen Verlauf auswerten und so SLIs und SLOs akkurat abstimmen können. Erst dies verschafft ihnen die Grundlage, um für alle Teams sowie über sämtliche Stack-Elemente hinweg auf so schnelle wie einfache Weise eine Baseline zu Verfügbarkeit und Uptime zu bestimmen.

Service-Levels gehören zwar nicht grundsätzlich zum Aufgabenspektrum von SRE-Teams und Reliability Engineers. Dennoch sind sie häufig mit ihnen betraut. Anhand der im Rahmen der SLIs erfassten Metrics lassen sich Ziele für die System-Performance in SLOs festhalten, dies etwa gemäß der im Handbuch von Google als goldene Signale definierten Aspekte Latenz, Traffic, Fehlerrate und Sättigung. Ein Beispiel wäre, die Anzahl der bei einem API-Aufruf erfolgreichen bzw. fehlgeschlagenen Anfragen (SLI) im Verhältnis zum Prozentwert der Anfragen zu erfassen, die für eine ansprechende CX mindestens erfolgreich sein müssen (als SLO, z. B. 95 %).

Um ein klareres Bild davon zu erhalten, wie anspruchsvoll sie die Zielvorgaben der mit Kund:innen vereinbarten SLAs anlegen können, setzen SRE-Teams die SLOs für kritische Anwendungs- und Service-Komponenten häufig besonders strikt an. Von diesen ausgehend können sie über Fehlerbudgets ermitteln, wie schnell Probleme behoben werden müssen, um weiterhin SLO-konform zu bleiben. Anhand von Service-Levels können die Teams ihre Metrics in einen aggregierten Kontext setzen, der Uptime, Performance und Verlässlichkeit für das gesamte Unternehmen transparent abbildet. Auf Leadership-Ebene wiederum kann über sie direkt die Compliance sämtlicher Teams, Anwendungen und Services eingesehen und so präzise nachvollzogen werden, wie es um den Health-Status der Systeme bestellt ist.

Was bedeutet Service-Level Management?

Im Kontext von Service-Levels ist unter Management zu verstehen, nicht nur sämtliche Prozesse rund um die Service-Auslieferung an Kund:innen dem vertraglich vereinbarten Maß an Qualität entsprechend angemessen zu gestalten, sondern auch das vereinbarte Maß selbst in einem angemessenen Rahmen zu halten. Dahinter steht einmal konsequentes Service-Level-Monitoring und -Reporting, mit dessen Hilfe SLOs bestimmt und angepasst sowie zugehörige SLIs definiert werden, um so die Erfüllung von SLAs bestmöglich zu gewährleisten. Wesentlich ist zugleich aber auch Abstimmung mit Kund:innen rund um diese im Rahmen von Review-Sessions.

Hierin liegt tatsächlich auch das zentrale Ziel: einem für sämtliche Teams klar verständlichen Maß dafür, wie Verfügbarkeit definiert ist – in ihren SLOs und folglich auch in den mit ihren Kunden vereinbarten SLAs. Sie zu erfüllen ist also mindestens vonnöten, sie zu übertreffen noch besser. Hierfür wiederum ist funktionsübergreifende Zusammenarbeit Ihrer Teams im Kontext intern festgelegter SLO-Ziele zentral. 

Im folgenden Nerd Bytes Video sehen Sie, Service-Level Management mit New Relic in Aktion.

Vorteile von Service-Level Management

Komplex gestaltet sich dabei jedoch die Frage, wie sich Best Practices für SLOs implementieren lassen. Denn damit sämtliche betroffenen Teams in dieser Hinsicht auf gleicher Linie sind, braucht es die richtigen Daten.

Was Reliability Engineers benötigen, ist eine Grundlage für effiziente Entscheidungen, um so rasch eine stack- und teamübergreifende Baseline für Verfügbarkeit und Uptime etablieren zu können. Dabei gilt es außerdem, durch SLOs und SLIs für Klarheit rund um Servicegrenzen zu sorgen. Dies gestützt auf eine komplett konsolidierte Sicht auf sämtliche für die Service-Verfügbarkeit relevanten Faktoren, aus der heraus zugleich SLAs für Kund:innen erleichtert wird. In diesem Kontext ebenso wichtig sind Reporting-Strukturen für Metrics zu Verlässlichkeit, SLO-Erfüllung und Fehlerbudgets, um an sämtlichen Punkten der Umgebung Optimierungspotenziale ausmachen zu können.

So sind einmal zielführende Methodiken rund um SLIs, SLOs und SLAs entscheidend sowie außerdem eine Plattform, die diese in ein adäquates Management von Service-Levels überführt. Aus diesem Verbund ergeben sich weitreichende Vorteile:

• Einfache Definition: Das Baselining für Performance und Verlässlichkeit lässt sich in einen automatisierten Workflow überführen, in dem angepasst an jeden beliebigen Service datengestützte Empfehlungen quasi mit einem Klick zum Ergebnis führen.
• Klare Team-Abstimmung: Mühselige Diskussionen auf dem Weg zu einem gemeinsamen Nenner in punkto Verlässlichkeit sind passé: Klarheit darüber, wo genau die Service-Grenzen liegen, liefern Empfehlungen rund um SLOs und SLIs gestützt auf automatisierte Benchmarks auf Grundlage historischer Performance-Metrics für jede beliebige Entität.
• Iterative Optimierung: Automatisierung und umfassende Kontext-Daten über den gesamten Stack hinweg werden möglich, indem etwa Open-Source-Tools für Infrastructure-as-Code wie Terraform implementiert werden. Hierüber können Teams den Einfluss von Nodes oder Services auf die Systemzuverlässigkeit klarer nachvollziehen, dadurch rascher an den richtigen Stellschrauben zur Optimierung der Performance drehen. Gestützt auf Custom-Ansichten für Service-Verantwortliche ebenso wie für die Leadership-Ebene werden zudem effiziente und zugleich auch effektivere Abläufe rund um Reporting, Alerting und Incident Management möglich.
• Verlässlichkeit nach Standard: Für die Teams aller Funktionsbereiche entsteht lückenlose Transparenz in punkto Service-Verfügbarkeit: Sämtliche hierfür relevanten Faktoren lassen sich in einer zentralen Ansicht abbilden und so direkt einsehen, ob im Kontext der mit Kunden vereinbarten SLAs alles konform bleibt. Möglich werden so auch effiziente Reporting-Strukturen, die anhand von Metrics zu SLO-Erfüllung und Fehlerbudgets Klarheit rund um die Verlässlichkeit liefern. Von Anwendungen bis hin zur Infrastruktur können Teams so konzertiert agieren, um zielführend Anpassungen vorzunehmen.

In unserem Blog rund um Best Practices zur Einrichtung von SLOs und SLIs für moderne, komplexe Systeme und in dieser Einführung in Service-Level Management haben wir weitere nützliche Praxistipps zusammengefasst.