Was ist SLA-Management?

Was ist SLA-Management?

SLA-Management umfasst das Definieren, Messen und Berichten der Service Level, die Sie Kunden zugesagt haben. Ein Service Level Agreement (SLA) ist ein Vertrag, der an das Verfehlen vereinbarter Ziele wie Verfügbarkeit oder Antwortzeit Folgen knüpft, etwa Gutschriften. Dazu gehören messbare Ziele, Instrumentierung, Alarme vor einer Verletzung, Erfüllungsberichte und die Abwicklung von Gutschriften.

SLI, SLO und SLA: der Unterschied

Das Google-SRE-Buch definiert die drei Begriffe so, und die Unterscheidung klärt die Zuständigkeiten:

• SLI (Service Level Indicator): eine genau definierte Messgröße eines Dienstes, zum Beispiel der Anteil erfolgreicher Anfragen.
• SLO (Service Level Objective): ein Zielwert oder Zielbereich für einen SLI, zum Beispiel 99,9 % erfolgreiche Anfragen über 28 Tage.
• SLA (Service Level Agreement): ein Vertrag mit Nutzern, der die Folgen des Erreichens oder Verfehlens der enthaltenen SLOs regelt. Gibt es keine ausdrückliche Folge, handelt es sich fast sicher um ein SLO.

Laut SRE-Buch hängen SLAs eng mit Geschäfts- und Produktentscheidungen zusammen, und ein internes SLO, das strenger ist als das öffentliche, schafft Raum, chronische Probleme zu beheben, bevor Nutzer sie bemerken. Das größere Bild zeigt Reliability Engineering.

Was Verfügbarkeitsprozente in Zeit bedeuten

Ein Verfügbarkeitsziel wird erst greifbar, wenn man es in erlaubte Ausfallzeit umrechnet. Die Werte sind reine Arithmetik: (1 minus Ziel) mal Länge des Zeitfensters, bei einer Woche mit 7 Tagen, einem Monat mit 30 Tagen und einem Jahr mit 365 Tagen.

Prüfen Sie, welches Zeitfenster der Vertrag verwendet. Ein Kalendermonat mit 31 Tagen erlaubt mehr Ausfall als einer mit 28, und 99,99 % lassen rund vier Minuten im Monat, die ein einziges langsames Deployment aufbrauchen kann.

So funktioniert SLA-Management

1. Messbare Bedingungen formulieren. Legen Sie Umfang (welche Endpunkte oder Funktionen), Messfenster, die Zählung fehlgeschlagener Anfragen und Ausnahmen fest, etwa vorab angekündigte geplante Wartung.
2. Den SLI von außen messen. Messen Sie, was Kunden erleben, nicht was Ihr Server glaubt. Externe Prüfungen von mehreren Standorten sind schwerer anzufechten als interne Logs allein.
3. Ein strengeres internes SLO setzen. Verspricht das SLA 99,5 % pro Monat, lässt ein internes SLO von 99,9 % etwa 2 Stunden 53 Minuten Spielraum (172,8 Minuten in einem 30-Tage-Monat), bevor der Vertrag gefährdet ist.
4. Auf das SLO alarmieren, nicht auf das SLA. Wenn das SLA verletzt ist, haben Kunden es längst gespürt.
5. Erfüllung berichten. Veröffentlichen Sie die Monatszahl automatisch, zum Beispiel auf einer Statusseite, damit niemand darüber streiten muss.
6. Verletzungen abwickeln. Berechnen Sie Gutschriften nach dem Vertragsplan, informieren Sie den Kunden und führen Sie ein Review durch. Auch die Incident-Kommunikation während des Ausfalls gehört zur SLA-Erfahrung.

Beispiel

Ein SaaS-Unternehmen sagt für seine API 99,5 % Verfügbarkeit pro Monat zu und betreibt intern ein SLO von 99,9 %. In einem 30-Tage-Monat erlaubt das SLO 43 Minuten Ausfall, das SLA 3 Stunden 36 Minuten. Ein fehlerhaftes Deployment verursacht 52 Minuten Fehler: Das SLO ist verfehlt, das Team startet ein Incident-Review, das SLA ist aber weiter erfüllt und es fällt keine Gutschrift an. Ohne internes SLO hätte niemand hingesehen, bevor die Vertragsgrenze überschritten wäre.

Häufige Fehler

• Ein SLA zusagen, ohne passendes SLO und ohne Messung, sodass die Erfüllung aus dem Gedächtnis diskutiert wird.
• Eine Zahl aus einer Tabelle wählen, etwa fünf Neunen, statt dessen, was die Architektur leisten kann.
• Verfügbarkeit von nur einem Standort aus messen, der regionale nicht von globalen Problemen unterscheiden kann.
• Nur Totalausfälle zählen und langsame Antworten ignorieren, die Kunden als Fehler erleben.
• Ausnahmen vage lassen, sodass jeder Vorfall zum Streitfall wird.

SLA-Management mit Tests und Monitoring

Monitoring liefert den SLI. API-Monitoring prüft Ihre Endpunkte nach Zeitplan und erfasst Fehler und Antwortzeiten. Das API-Monitoring von LoadFocus prüft über 25 Cloud-Regionen, alarmiert per E-Mail, Slack, Microsoft Teams und weitere Kanäle und zeigt die Verfügbarkeit über einen wählbaren Zeitraum. Der kostenlose Tarif prüft alle 5 Minuten und enthält eine Statusseite, SLA-Berichte gegen ein Ziel gibt es in den bezahlten Tarifen.

Tests zeigen, ob das Ziel realistisch ist. Ein Latenzversprechen bei Spitzenlast lässt sich ohne Lasttests und Kapazitätstests nicht belegen. Zur Monitoring-Seite lesen Sie den englischen Beitrag Monitoring Best Practices für DevOps und Entwickler.

Häufige Fragen: SLA-Management

Was ist der Unterschied zwischen SLA, SLO und SLI?

Ein SLI ist eine Messung, ein SLO ein Ziel für diese Messung und ein SLA ein Vertrag, der an das Verfehlen des Ziels Folgen knüpft. Teams betreiben SLOs meist intern und sagen extern ein lockereres SLA zu.

Wie viel Ausfall erlaubt 99,9 %?

Etwa 43 Minuten in einem 30-Tage-Monat und etwa 8 Stunden 46 Minuten in einem 365-Tage-Jahr. Jede weitere Neun senkt die erlaubte Zeit auf ein Zehntel.

Was passiert bei einer SLA-Verletzung?

Das hängt vom Vertrag ab. Üblich ist eine Gutschrift nach einem Plan im Vertrag. Genaue Bedingungen, Antragsweg und Ausnahmen stehen in Ihrem eigenen Vertrag.

Sollte das SLO strenger sein als das SLA?

Ja. Ein strengeres internes SLO warnt Sie, bevor der Vertrag gefährdet ist, und lässt Raum, Probleme zu beheben, bevor Kunden sie spüren.

Wer ist für SLA-Management zuständig?

Mehrere Teams. Engineering verantwortet Messung und Architektur, Produkt und Customer Success den Vertrag und seine Formulierung, die Finanzabteilung die Gutschriften.