SLA, SLO, SLI: Kubernetes-Verfügbarkeit messen

TL;DR

SLIs messen konkrete Metriken wie Latenz oder Fehlerrate. SLOs definieren Zielwerte für diese Metriken. SLAs sind vertragliche Zusagen mit Konsequenzen bei Nichteinhaltung. Für Kubernetes-Services beginnt man mit zwei SLIs (Availability und Latency), setzt realistische SLOs (99.9% statt 99.99%) und berechnet daraus ein Error Budget, das Engineering-Entscheidungen steuert.

Die Hierarchie: SLI → SLO → SLA

Viele Teams verwechseln die drei Begriffe oder verwenden sie synonym. Die Unterscheidung ist aber entscheidend für den praktischen Nutzen.

Ein SLI (Service Level Indicator) ist eine Messung. Konkret: ein Prometheus-Query, der eine Zahl liefert.

# SLI: Verfügbarkeit als Anteil erfolgreicher Requests
sum(rate(http_requests_total{code!~"5.."}[30d]))
/
sum(rate(http_requests_total[30d]))

Ein SLO (Service Level Objective) ist ein Zielwert für diesen SLI: "99.9% aller Requests sollen erfolgreich sein." Ein SLA (Service Level Agreement) ist ein Vertrag, der Konsequenzen festlegt, wenn das SLO gebrochen wird — Gutschriften, Kündigungsrechte oder Penalty-Zahlungen.

Das SLA ist immer lockerer als das SLO. Wenn Ihr SLO bei 99.9% liegt, sollte das SLA bei 99.5% liegen. Sonst brennt das Error Budget ab, bevor jemand reagieren kann.

Zwei SLIs, mit denen jedes Team starten sollte

Statt zehn Metriken halbherzig zu tracken, beginnen Sie mit zwei SLIs, die für fast jeden Kubernetes-Service relevant sind.

1. Availability SLI

Anteil der Requests, die keinen Server-Error (5xx) zurückgeben:

# Availability SLI über 30 Tage (Rolling Window)
1 - (
  sum(increase(http_requests_total{code=~"5..", namespace="production"}[30d]))
  /
  sum(increase(http_requests_total{namespace="production"}[30d]))
)

2. Latency SLI

Anteil der Requests, die unter einem Schwellwert beantwortet werden:

# Latency SLI: Anteil der Requests unter 300ms
sum(rate(http_request_duration_seconds_bucket{le="0.3", namespace="production"}[30d]))
/
sum(rate(http_request_duration_seconds_count{namespace="production"}[30d]))

Beide Queries funktionieren mit dem Standard-Prometheus-Setup im Cluster. Falls Sie den kube-prometheus-stack nutzen, sind die Metriken bereits vorhanden.

Error Budget: Das Steuerungsinstrument

Das Error Budget macht SLOs erst operativ nützlich. Es beantwortet die Frage: "Wie viel darf noch schiefgehen, bevor wir das SLO verletzen?"

Bei einem SLO von 99.9% Availability über 30 Tage ergibt sich:

• 30 Tage = 43.200 Minuten
• Error Budget = 0.1% × 43.200 = 43,2 Minuten Downtime pro Monat

# PrometheusRule: Alert wenn Error Budget unter 25% fällt
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: slo-error-budget
  namespace: monitoring
spec:
  groups:
    - name: slo.rules
      rules:
        - alert: ErrorBudgetBurnRateHigh
          expr: |
            (
              1 - (
                sum(rate(http_requests_total{code!~"5..", namespace="production"}[1h]))
                /
                sum(rate(http_requests_total{namespace="production"}[1h]))
              )
            )
            /
            (1 - 0.999)
            > 14.4
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Error Budget wird mit 14.4x Geschwindigkeit verbraucht"
            description: "Bei dieser Burn Rate ist das monatliche Error Budget in 2 Stunden aufgebraucht."

Der Burn-Rate-Alert ist effektiver als ein einfacher Schwellwert-Alert. Er erkennt nicht nur, dass Fehler auftreten, sondern wie schnell das Budget aufgebraucht wird. Ein Burn-Rate-Faktor von 14.4 bedeutet: In einer Stunde wird so viel Budget verbraucht wie normalerweise in 14,4 Stunden.

SLO-Template für neue Services

Jeder neue Service in Kubernetes sollte ein SLO-Dokument mitbringen. Hier ein Template:

# slo-definition.yaml (kein Kubernetes-Manifest, Dokumentation)
service: checkout-api
owner: team-commerce
slos:
  - name: availability
    sli: "Anteil erfolgreicher HTTP-Responses (non-5xx)"
    target: 99.9%
    window: 30d
    error_budget_minutes: 43.2
    alert_burn_rate_1h: 14.4
    alert_burn_rate_6h: 6.0

  - name: latency-p99
    sli: "99. Perzentil der Response-Latenz"
    target: "< 500ms"
    window: 30d
    measurement: "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))"

  - name: latency-p50
    sli: "Median der Response-Latenz"
    target: "< 100ms"
    window: 30d

review_cadence: monatlich
escalation:
  budget_below_50pct: "Feature Freeze evaluieren"
  budget_below_25pct: "Nur noch Reliability-Arbeit"
  budget_exhausted: "Incident Review, Post-Mortem"

Dieses Dokument lebt im Repository des Services — nicht in einem Wiki, das niemand liest.

SLOs und Incident Response

SLOs verändern, wie Teams auf Incidents reagieren. Ohne SLOs ist jeder Alert gleich dringend. Mit SLOs gibt es eine klare Priorisierung:

Error Budget > 50%: Normalbetrieb. Feature-Entwicklung läuft weiter. Kleinere Fehler werden im nächsten Sprint behoben.

Error Budget 25-50%: Vorsicht. Neue Deployments werden genauer geprüft. Riskante Changes werden verschoben.

Error Budget < 25%: Feature Freeze. Das Team fokussiert sich ausschließlich auf Reliability. Jedes Deployment braucht explizite Genehmigung.

Error Budget aufgebraucht: Vollständiger Deployment-Stop bis zum nächsten Fenster. Post-Mortem für die Ursachen. Maßnahmenplan für den nächsten Monat.

Diese Eskalationsstufen machen aus einem abstrakten Zielwert ein konkretes Steuerungsinstrument. Product Owner verstehen, warum Feature-Arbeit pausiert, weil die Zahl im Dashboard für alle sichtbar ist.

Typische Fehler bei SLO-Definitionen

Drei Fehler sehe ich immer wieder:

Zu ambitionierte SLOs. 99.99% klingt gut, erlaubt aber nur 4,3 Minuten Downtime pro Monat. Für die meisten internen Services ist 99.9% realistisch und ausreichend. Starten Sie konservativ und verschärfen Sie das SLO, wenn Sie es konsistent einhalten.

SLOs ohne Konsequenzen. Wenn ein gebrochenes SLO keine Verhaltensänderung auslöst, ist es nur eine Zahl auf einem Dashboard. Definieren Sie vorher, was bei 50%, 25% und 0% Error Budget passiert.

Zu viele SLOs. Drei SLOs pro Service sind genug. Availability, Latency und eventuell Throughput. Mehr führt dazu, dass keines ernst genommen wird.

FAQ

Brauche ich SLOs auch für interne Services ohne externe Kunden?

Ja. Interne Services haben interne Kunden — andere Teams, deren Dienste von Ihrem abhängen. Ohne SLO gibt es keine gemeinsame Sprache für "wie zuverlässig muss das sein". Das SLA entfällt, aber SLI und SLO sind genauso wichtig.

Wie unterscheidet sich Uptime-Monitoring von einem SLI?

Uptime-Monitoring prüft binär, ob ein Endpunkt antwortet. Ein SLI misst den Anteil erfolgreicher Interaktionen aus Nutzersicht. Ein Service kann "up" sein, aber 10% der Requests mit 500er-Fehlern beantworten — das Uptime-Monitoring zeigt grün, der SLI zeigt ein Problem.

Welche Tools helfen bei SLO-Management in Kubernetes?

Sloth generiert Prometheus-Recording-Rules und Burn-Rate-Alerts aus einer einfachen YAML-Definition. Pyrra bietet zusätzlich ein Web-UI für SLO-Dashboards. Beide sind Open Source und integrieren sich in den kube-prometheus-stack.

Was ist ein guter Startwert für das erste SLO?

Messen Sie zwei Wochen lang Ihren aktuellen SLI, ohne ein SLO zu setzen. Wenn Ihre aktuelle Availability bei 99.95% liegt, setzen Sie das SLO auf 99.9%. So haben Sie Spielraum, ohne das Ziel unerreichbar niedrig zu setzen.