---

name: define-slo-sli-sla description: > Service Level Objectives (SLO), Service Level Indicators (SLI) und Service Level Agreements (SLA) mit Fehlerbudget-Tracking, Burn-Rate-Alerts und automatisierter Berichterstellung mit Prometheus und Tools wie Sloth oder Pyrra definieren. Verwenden, wenn Zuverlaessigkeitsziele fuer kundenseitige Services festgelegt werden, Feature- Geschwindigkeit und Systemzuverlaessigkeit durch Fehlerbudgets abgewogen werden, von willkuerlichen Uptime-Zielen zu datengetriebenen Metriken migriert wird oder Site-Reliability-Engineering-Praktiken implementiert werden. locale: de source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: observability complexity: intermediate language: multi tags: slo, sli, sla, error-budget, burn-rate

SLO/SLI/SLA definieren

Messbare Zuverlaessigkeitsziele mit Service Level Objectives festlegen, mit Indikatoren verfolgen und Fehlerbudgets verwalten.

Wann verwenden

• Zuverlaessigkeitsziele fuer kundenseitige Services oder APIs festlegen
• Klare Erwartungen zwischen Service-Anbietern und Verbrauchern etablieren
• Feature-Geschwindigkeit mit Systemzuverlaessigkeit durch Fehlerbudgets ausbalancieren
• Objektive Kriterien fuer Incident-Schweregrad und -Reaktion erstellen
• Von willkuerlichen Uptime-Zielen zu datengetriebenen Zuverlaessigkeitsmetriken migrieren
• Site-Reliability-Engineering-Praktiken (SRE) implementieren
• Servicequalitaet im Laufe der Zeit messen und verbessern

Eingaben

• Pflichtfeld: Service-Beschreibung und kritische Benutzer-Journeys
• Pflichtfeld: Historische Metrikdaten (Request-Raten, Latenzen, Fehlerquoten)
• Optional: Bestehende SLA-Verpflichtungen gegenueber Kunden
• Optional: Geschaeftsanforderungen fuer Service-Verfuegbarkeit und -Performance
• Optional: Incident-Verlauf und Daten zu Kundenauswirkungen

Vorgehensweise

Unter Extended Examples sind vollstaendige Konfigurationsdateien und Templates verfuegbar.

Schritt 1: SLI-, SLO- und SLA-Hierarchie verstehen

Die Beziehungen und Unterschiede zwischen diesen drei Konzepten erlernen.

Definitionen:

SLI (Service Level Indicator)
- **What**: A quantitative measure of service behavior
- **Example**: Request success rate, request latency, system throughput
- **Measurement**: `successful_requests / total_requests * 100`

SLO (Service Level Objective)
- **What**: Target value or range for an SLI over a time window
- **Example**: 99.9% of requests succeed in 30-day window
- **Purpose**: Internal reliability target to guide operations

SLA (Service Level Agreement)
- **What**: Contractual commitment with consequences for missing SLO
- **Example**: 99.9% uptime SLA with refunds if breached
- **Purpose**: External promise to customers with penalties

Hierarchie:

SLA (99.9% uptime, customer refunds)
  ├─ SLO (99.95% success rate, internal target)
  │   └─ SLI (actual measured: 99.97% success rate)
  └─ Error Budget (0.05% failures allowed per month)

Schluessprinzip: Das SLO sollte strenger als das SLA sein, um einen Puffer zu bieten, bevor Kunden betroffen sind.

Beispiel:

• SLA: 99,9 % Verfuegbarkeit (Kundenzusage)
• SLO: 99,95 % Verfuegbarkeit (internes Ziel)
• Puffer: 0,05 % Spielraum vor SLA-Verletzung

Erwartet: Team versteht Unterschiede, Einigung, welche Metriken zu SLIs werden, Abstimmung zu SLO-Zielen.

Bei Fehler:

• Google-SRE-Buch-Kapitel zu SLI/SLO/SLA lesen
• Workshop mit Stakeholdern zur Abstimmung ueber Definitionen durchfuehren
• Mit einfachem Erfolgsquoten-SLI beginnen, bevor komplexe Latenz-SLOs erstellt werden

Schritt 2: Geeignete SLIs auswaehlen

SLIs auswaehlen, die Benutzererfahrung und Geschaeftsauswirkungen widerspiegeln.

Die vier goldenen Signale (Google SRE):

1. Latenz: Zeit zur Bearbeitung einer Anfrage

   # P95 latency
   histogram_quantile(0.95,
     sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
   )
   

2. Traffic: Nachfrage an das System

   # Requests per second
   sum(rate(http_requests_total[5m]))
   

3. Fehler: Rate fehlgeschlagener Anfragen

   # Error rate percentage
   sum(rate(http_requests_total{status=~"5.."}[5m]))
   / sum(rate(http_requests_total[5m])) * 100
   

4. Saettigung: Wie "voll" das System ist

   # CPU saturation
   avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))
   

Gaengige SLI-Muster:

# Availability SLI
availability:
  description: "Percentage of successful requests"
  query: |
    sum(rate(http_requests_total{status!~"5.."}[5m]))
    / sum(rate(http_requests_total[5m]))
  good_threshold: 0.999  # 99.9%

# Latency SLI
latency:
  description: "P99 request latency under 500ms"
  query: |
    histogram_quantile(0.99,
      sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
    ) < 0.5
  good_threshold: 0.95  # 95% of windows meet target

# Throughput SLI
throughput:
  description: "Requests processed per second"
  query: |
    sum(rate(http_requests_total[5m]))
  good_threshold: 1000  # Minimum 1000 req/s

# Data freshness SLI (for batch jobs)
freshness:
  description: "Data updated within last hour"
  query: |
    (time() - max(data_last_updated_timestamp)) < 3600
  good_threshold: 1  # Always fresh

SLI-Auswahlkriterien:

• Benutzersichtbar: Spiegelt tatsaechliche Benutzererfahrung wider
• Messbar: Kann aus vorhandenen Metriken quantifiziert werden
• Handlungsorientiert: Team kann es durch Engineering-Arbeit verbessern
• Bedeutsam: Korreliert mit Kundenzufriedenheit
• Einfach: Leicht zu verstehen und zu erklaeren

Vermeiden:

• Interne Systemmetriken, die Benutzern nicht sichtbar sind (CPU, Arbeitsspeicher)
• Eitelkeitsmetriken, die keine Kundenauswirkungen vorhersagen
• Uebermassig komplexe zusammengesetzte Bewertungen

Erwartet: 2-4 SLIs pro Service ausgewaehlt, mindestens Verfuegbarkeit und Latenz abdeckend, Team-Einigung zu Messabfragen.

Bei Fehler:

• Benutzer-Journey abbilden, um kritische Ausfallpunkte zu identifizieren
• Incident-Verlauf analysieren: Welche Metriken sagten Kundenauswirkungen voraus?
• SLI mit A/B-Test validieren: Metrik verschlechtern, Kundenbeschwerden messen
• Mit einfachem Verfuegbarkeits-SLI beginnen, Komplexitaet iterativ hinzufuegen

Schritt 3: SLO-Ziele und Zeitfenster festlegen

Realistische und erreichbare Zuverlaessigkeitsziele definieren.

SLO-Spezifikationsformat:

service: user-api
slos:
  - name: availability
    objective: 99.9
    description: |
      99.9% of requests return non-5xx status codes
# ... (see EXAMPLES.md for complete configuration)

Auswahl des Zeitfensters:

Gaengige Fenster:

• 30 Tage (monatlich): Typisch fuer externe SLAs
• 7 Tage (woechentlich): Schnelleres Feedback fuer Engineering-Teams
• 1 Tag (taeglich): Hochfrequente Services mit schneller Reaktion erforderlich

Beispiel-Fehlerbudget fuer 30-Tage-Fenster:

SLO: 99.9% availability over 30 days
Allowed failures: 0.1%
Total requests per month: 100M
Error budget: 100,000 failed requests
Daily budget: ~3,333 failed requests

Realistische Ziele setzen:

1. Aktuelle Performance als Ausgangspunkt nehmen:

   # Check actual availability over past 90 days
   avg_over_time(
     (sum(rate(http_requests_total{status!~"5.."}[5m]))
     / sum(rate(http_requests_total[5m])))[90d:5m]
   )
   # Result: 99.95% → Set SLO at 99.9% (safer than current)
   

2. Kosten der Neunen berechnen:

   99%    → 7.2 hours downtime/month (low reliability)
   99.9%  → 43 minutes downtime/month (good)
   99.95% → 22 minutes downtime/month (very good)
   99.99% → 4.3 minutes downtime/month (expensive)
   99.999% → 26 seconds downtime/month (very expensive)
   

3. Benutzer-Glueck gegenueber Engineering-Kosten abwaegen:

   • Zu streng: Teuer, verlangsamt Feature-Entwicklung
   • Zu locker: Schlechte Benutzererfahrung, Kundenverlust
   • Optimaler Punkt: Etwas besser als Benutzererwartungen

Erwartet: SLO-Ziele mit Zustimmung der Geschaefts-Stakeholder gesetzt, mit Begruendung dokumentiert, Fehlerbudget berechnet.

Bei Fehler:

• Mit erreichbarem Ziel beginnen (z. B. 99 %, wenn aktuell 98,5 %)
• SLO-Ziele vierteljaehrlich basierend auf tatsaechlicher Performance iterieren
• Fuehrungsunterstuetzung fuer realistische Ziele vs. "fuenf Neunen"-Anforderungen einholen
• Kosten-Nutzen-Analyse fuer jede zusaetzliche Neun dokumentieren

Schritt 4: SLO-Monitoring mit Sloth implementieren

Sloth verwenden, um Prometheus-Recording-Rules und Alerts aus SLO-Spezifikationen zu generieren.

Sloth installieren:

# Binary installation
wget https://github.com/slok/sloth/releases/download/v0.11.0/sloth-linux-amd64
chmod +x sloth-linux-amd64
sudo mv sloth-linux-amd64 /usr/local/bin/sloth

# Or Docker
docker pull ghcr.io/slok/sloth:latest

Sloth-SLO-Spezifikation erstellen (slos/user-api.yml):

version: "prometheus/v1"
service: "user-api"
labels:
  team: "platform"
  tier: "1"
slos:
# ... (see EXAMPLES.md for complete configuration)

Prometheus-Regeln generieren:

# Generate recording and alerting rules
sloth generate -i slos/user-api.yml -o prometheus/rules/user-api-slo.yml

# Validate generated rules
promtool check rules prometheus/rules/user-api-slo.yml

Generierte Recording-Rules (Auszug):

groups:
  - name: sloth-slo-sli-recordings-user-api-requests-availability
    interval: 30s
    rules:
      # SLI: Ratio of good events
      - record: slo:sli_error:ratio_rate5m
# ... (see EXAMPLES.md for complete configuration)

Generierte Alerts:

groups:
  - name: sloth-slo-alerts-user-api-requests-availability
    rules:
      # Fast burn: 2% budget consumed in 1 hour
      - alert: UserAPIHighErrorRate
        expr: |
# ... (see EXAMPLES.md for complete configuration)

Regeln in Prometheus laden:

# prometheus.yml
rule_files:
  - "rules/user-api-slo.yml"

Prometheus neu laden:

curl -X POST http://localhost:9090/-/reload

Erwartet: Sloth generiert Multi-Window-Multi-Burn-Rate-Alerts, Recording-Rules werden erfolgreich ausgewertet, Alerts werden waehrend Incidents entsprechend ausgeloest.

Bei Fehler:

• YAML-Syntax mit yamllint slos/user-api.yml validieren
• Sloth-Versionskompatibilitaet pruefen (v0.11+ empfohlen)
• Prometheus-Recording-Rule-Auswertung pruefen: curl http://localhost:9090/api/v1/rules
• Mit synthetischer Fehlerinjektion testen, um Alerts auszuloesen
• Sloth-Dokumentation fuer das SLI-Ereignisabfrageformat pruefen

Schritt 5: Fehlerbudget-Dashboards erstellen

SLO-Compliance und Fehlerbudget-Verbrauch in Grafana visualisieren.

Grafana-Dashboard-JSON (Auszug):

{
  "dashboard": {
    "title": "SLO Dashboard - User API",
    "panels": [
      {
        "type": "stat",
# ... (see EXAMPLES.md for complete configuration)

Zu visualisierende Schluesselmetriken:

• SLO-Ziel vs. aktueller SLI
• Verbleibendes Fehlerbudget (prozentuell und absolut)
• Burn-Rate (wie schnell das Budget erschoepft wird)
• Historische SLI-Trends (gleitendes 30-Tage-Fenster)
• Bis zur Erschoepfung verbleibende Zeit (bei aktueller Burn-Rate)

Dashboard fuer Fehlerbudget-Richtlinien (Markdown-Panel):

## Error Budget Policy

**Current Status**: 78% budget remaining

### If Error Budget > 50%
- ✅ Full speed ahead on new features
# ... (see EXAMPLES.md for complete configuration)

Erwartet: Dashboards zeigen Echtzeit-SLO-Compliance, Fehlerbudget-Abbau sichtbar, Team kann fundierte Entscheidungen zur Feature-Geschwindigkeit treffen.

Bei Fehler:

• Recording-Rules pruefen: curl http://localhost:9090/api/v1/rules | jq '.data.groups[].rules[] | select(.name | contains("slo:"))'
• Prometheus-Datenquelle in Grafana auf korrekte URL pruefen
• Abfrageergebnisse in der Explore-Ansicht validieren, bevor zum Dashboard hinzugefuegt wird
• Sicherstellen, dass der Zeitbereich auf das entsprechende Fenster eingestellt ist (z. B. 30d fuer monatliche SLOs)

Schritt 6: Fehlerbudget-Richtlinie etablieren

Organisatorischen Prozess zur Verwaltung von Fehlerbudgets definieren.

Vorlage fuer Fehlerbudget-Richtlinien:

service: user-api
slo:
  availability: 99.9%
  latency_p99: 200ms
  window: 30 days

# ... (see EXAMPLES.md for complete configuration)

Richtliniendurchsetzung automatisieren:

# Example: Deployment gate script
import requests
import sys

def check_error_budget(service):
    # Query Prometheus for error budget
# ... (see EXAMPLES.md for complete configuration)

In CI/CD-Pipeline integrieren:

# .github/workflows/deploy.yml
jobs:
  check-error-budget:
    runs-on: ubuntu-latest
    steps:
      - name: Check SLO Error Budget
        run: |
          python scripts/check_error_budget.py user-api
      - name: Deploy
        if: success()
        run: |
          kubectl apply -f deploy/

Erwartet: Klare Richtlinie dokumentiert, automatisierte Gates verhindern riskante Deployments waehrend der Budget-Erschoepfung, Team-Abstimmung zu Zuverlaessigkeitsprioritaeten.

Bei Fehler:

• Mit manueller Richtliniendurchsetzung beginnen (Slack-Erinnerungen)
• Schrittweise mit weichen Gates automatisieren (Warnungen, keine Blockierungen)
• Fuehrungsunterstuetzung vor harten Gates einholen (Deployments blockieren)
• Richtlinieneffektivitaet vierteljaehrlich ueberpruefen, Schwellenwerte nach Bedarf anpassen

Validierung

• SLIs ausgewaehlt, die Benutzererfahrung und Geschaeftsauswirkungen widerspiegeln
• SLO-Ziele mit Stakeholder-Zustimmung und dokumentierter Begruendung gesetzt
• Prometheus-Recording-Rules generieren SLI-Metriken erfolgreich
• Multi-Burn-Rate-Alerts konfiguriert und mit synthetischen Fehlern getestet
• Grafana-Dashboards zeigen Echtzeit-SLO-Compliance und Fehlerbudget
• Fehlerbudget-Richtlinie dokumentiert und an Team kommuniziert
• Automatisierte Gates verhindern riskante Deployments waehrend Budget-Erschoepfung
• Woechentliche/monatliche SLO-Reviewmeetings geplant
• Incident-Retrospektiven beinhalten SLO-Auswirkungsanalyse
• SLO-Compliance-Berichte werden mit Stakeholdern geteilt

Haeufige Stolperfallen

• Zu strenge SLOs: "Fuenf Neunen" ohne Kostenanalyse setzen fuehrt zu Erschoepfung und verlangsamter Feature-Entwicklung. Erreichbar beginnen, iterativ steigern.
• Zu viele SLIs: 10+ Indikatoren verfolgen schafft Verwirrung. Auf 2-4 kritische kundenseitige Metriken konzentrieren.
• SLO ohne SLA-Puffer: SLO gleich SLA setzen laesst keinen Spielraum fuer Fehler vor Kundenauswirkungen. 0,05-0,1 % Puffer halten.
• Fehlerbudget ignorieren: SLOs verfolgen, aber nicht auf Budget-Erschoepfung reagieren, macht den Zweck zunichte. Fehlerbudget-Richtlinie durchsetzen.
• Eitelkeitsmetriken als SLIs: Interne Metriken (CPU, Arbeitsspeicher) statt benutzersichtbarer Metriken (Latenz, Fehler) verwenden, fuehrt zu Fehlausrichtung der Prioritaeten.
• Kein Stakeholder-Buy-in: Nur Engineering-SLOs ohne Produkt/Geschaefts-Vereinbarung fuehren zu Konflikten. Fuehrungsunterstuetzung einholen.
• Statische SLOs: Ziele niemals ueberpruefen oder anpassen, wenn das System sich weiterentwickelt. Vierteljaehrlich basierend auf tatsaechlicher Performance und Benutzerfeedback ueberpruefen.

Verwandte Skills

• setup-prometheus-monitoring - Prometheus konfigurieren, um Metriken fuer SLI-Berechnung zu sammeln
• configure-alerting-rules - SLO-Burn-Rate-Alerts mit Alertmanager fuer On-Call-Benachrichtigungen integrieren
• build-grafana-dashboards - SLO-Compliance und Fehlerbudget-Verbrauch visualisieren
• write-incident-runbook - SLO-Auswirkungen in Runbooks fuer die Priorisierung der Incident-Reaktion einschliessen