SLA, SLO, SLI

Die drei Säulen der Service-Zuverlässigkeit – SLI misst, SLO definiert Ziele, SLA ist der Vertrag. Grundlage für Reliability Engineering.

Fortgeschritten2 Min Lesezeit

Erklärung starten

Auf einen Blick

3 Punkte

  1. SLI (Indicator): Was messen wir? (z.B. Latenz, Verfügbarkeit)
  2. SLO (Objective): Was ist unser Ziel? (z.B. 99.9% Verfügbarkeit)
  3. SLA (Agreement): Was versprechen wir Kunden? (mit Konsequenzen)

Sofortantwort

SLA, SLO, SLI einfach erklärt

SLI misst Performance, SLO setzt Ziele, SLA ist der Vertrag mit Kunden.

Kurz gesagt
SLI (Indicator): Was messen wir? (z.B. Latenz, Verfügbarkeit)
Typischer Einsatz
API-Services, ML-Inference, Cloud-Dienste
Wichtig zu wissen
SLA (Agreement): Was versprechen wir Kunden? (mit Konsequenzen)

SLA, SLO, SLI im Überblick

SLI, SLO und SLA sind die drei Ebenen, um Service-Zuverlässigkeit zu definieren und zu messen.

Die Hierarchie:

SLA (Service Level Agreement)
│   "Wir garantieren 99.9% Verfügbarkeit, sonst Gutschrift"
│   → Vertrag mit Kunden, rechtlich bindend

└── SLO (Service Level Objective)
    │   "Unser internes Ziel: 99.95% Verfügbarkeit"
    │   → Strenger als SLA, gibt uns Puffer

    └── SLI (Service Level Indicator)
        "Gemessene Verfügbarkeit letzte 30 Tage: 99.97%"
        → Die tatsächliche Messung

Beispiel für eine API:

TypBeispiel
SLILatenz P99 = 145ms
SLOLatenz P99 soll unter 200ms sein
SLALatenz P99 unter 500ms, sonst 10% Gutschrift

Technisch betrachtet

Typische SLIs

KategorieSLIMessung
VerfügbarkeitErfolgreiche Requests / Alle RequestsProzent
LatenzAntwortzeit P50, P95, P99Millisekunden
DurchsatzRequests pro SekundeRPS
FehlerrateFehler / Alle RequestsProzent
KorrektheitKorrekte Antworten / Alle AntwortenProzent

SLO Definition

# slo.yaml
slos:
  - name: api-availability
    description: "API sollte verfügbar sein"
    sli:
      type: availability
      good_events: "http_status < 500"
      total_events: "all requests"
    objective: 99.9%
    window: 30d
    
  - name: api-latency
    description: "API sollte schnell antworten"
    sli:
      type: latency
      threshold: 200ms
      percentile: 99
    objective: 99%
    window: 30d

Error Budget

SLO: 99.9% Verfügbarkeit über 30 Tage

Error Budget = 100% - 99.9% = 0.1%
             = 0.1% × 30 Tage × 24h × 60min
             = 43.2 Minuten Downtime erlaubt

Aktueller Verbrauch:
- Incident 1: 15 Minuten
- Incident 2: 10 Minuten
- Verbraucht: 25 Minuten (58%)
- Übrig: 18.2 Minuten (42%)

Prometheus SLI-Messung

# Verfügbarkeit SLI
- record: sli:api_availability:ratio
  expr: |
    sum(rate(http_requests_total{status!~"5.."}[5m]))
    /
    sum(rate(http_requests_total[5m]))

# Latenz SLI (P99 unter 200ms)
- record: sli:api_latency:ratio
  expr: |
    sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
    /
    sum(rate(http_request_duration_seconds_count[5m]))

SLO-basiertes Alerting

# Alert wenn Error Budget zu schnell verbraucht wird
groups:
  - name: slo-alerts
    rules:
      - alert: ErrorBudgetBurnRate
        expr: |
          (
            1 - sli:api_availability:ratio
          ) > 14.4 * (1 - 0.999)
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error Budget wird zu schnell verbraucht"

Die 9er-Tabelle

VerfügbarkeitDowntime/JahrDowntime/Monat
99% (zwei 9)3.65 Tage7.3 Stunden
99.9% (drei 9)8.76 Stunden43.8 Minuten
99.95%4.38 Stunden21.9 Minuten
99.99% (vier 9)52.6 Minuten4.38 Minuten
99.999% (fünf 9)5.26 Minuten26.3 Sekunden

01Einsatzbereiche

Wann ist SLA, SLO, SLI sinnvoll?

Geeignet für

  • API-ServicesLatenz und Verfügbarkeit für externe APIs garantieren
  • ML-InferenceAntwortzeiten und Accuracy für Modell-Endpoints
  • Cloud-DiensteAWS, GCP, Azure haben SLAs für ihre Services
  • Enterprise-VerträgeVertragliche Zusagen an Geschäftskunden

↑ Inhalt

02Werkzeuge

Womit SLA, SLO, SLI umgesetzt wird

↑ Inhalt

Merksatz

SLI ist wie ein Thermometer (misst Temperatur), SLO ist wie die Wunschtemperatur (20°C), SLA ist wie der Mietvertrag (Vermieter garantiert funktionierende Heizung, sonst Mietminderung).

  1. SLI (Indicator): Was messen wir? (z.B. Latenz, Verfügbarkeit)
  2. SLO (Objective): Was ist unser Ziel? (z.B. 99.9% Verfügbarkeit)
  3. SLA (Agreement): Was versprechen wir Kunden? (mit Konsequenzen)

04Redaktion

Herkunft und Stand

Redaktion und Aktualität

Ebenex RedaktionRedaktion

Veröffentlicht
Aktualisiert

Dieses Feld entwickelt sich schnell. Oben stehen Veröffentlichung und letzte Änderung; ein Prüfdatum kommt dazu, sobald die Erklärung nach ihrer letzten Änderung geprüft wurde.

↑ Inhalt

05FAQ

Häufige Fragen zu SLA, SLO, SLI

Was ist der Unterschied zwischen SLO und SLA?

SLO ist intern (unser Ziel). SLA ist extern (Vertrag mit Kunden). SLOs sollten strenger sein als SLAs, um Puffer zu haben.

Wie viele 9en brauche ich?

99% = 3.65 Tage Downtime/Jahr. 99.9% = 8.76 Stunden. 99.99% = 52 Minuten. Mehr 9en = exponentiell teurer. Wähle basierend auf Business-Anforderungen.

Was ist ein Error Budget?

Die erlaubte Fehlerquote. Bei 99.9% SLO hast du 0.1% Error Budget. Wenn aufgebraucht: Keine neuen Features, nur Stabilität.

↑ Inhalt

06Weiterlernen

Was möchtest du als Nächstes verstehen?

  • Grundlage nachholen

    Monitoring

    Kontinuierliche Überwachung von KI-Systemen zur Fehlererkennung.

  • Technisch vertiefen

    Observability

    Fähigkeit, den Zustand eines Systems durch Logs, Metrics und Traces zu verstehen.

↑ Inhalt