Linuxguide

SLAs, SLOs und SLIs – Service-Level-Management 2025

Verfügbarkeitsziele definieren und automatisch messen

S
SeeColors IT
11. Juni 20264 Min. Lesezeit40 Aufrufe

SLA vs. SLO vs. SLI

SLI (Service Level Indicator):
Messbare Kennzahl: "Wie oft schlagen Requests fehl?"

SLO (Service Level Objective):
Internes Ziel: "99,9% aller Requests sollen erfolgreich sein"

SLA (Service Level Agreement):
Vertragliche Zusage: "99,5% Verfügbarkeit, sonst Gutschrift"

Error Budget:
Budget = 100% - SLO
Bei 99,9% SLO: 0,1% = 43,8 Minuten/Monat Downtime erlaubt

SLIs mit Prometheus definieren

# Availability SLI: % erfolgreiche HTTP-Requests
# SLO: 99.9% aller Requests sind 2xx oder 3xx

# prometheus.yml / alerts.yml
groups:
  - name: slo
    rules:
      # SLI: Fehlerrate (Basis für SLO)
      - record: job:http_requests:error_rate5m
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m]))

      # Alert wenn SLO gefährdet (burn rate > 5x)
      - alert: SLOBurnRateTooHigh
        expr: job:http_requests:error_rate5m > 0.001 * 5
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Error Budget wird zu schnell verbraucht"
          description: "Aktuelle Fehlerrate: {{ $value | humanizePercentage }}"

      # Critical: Burn Rate 14x (30 Tage Budget in 2 Tagen leer)
      - alert: SLOCriticalBurnRate
        expr: job:http_requests:error_rate5m > 0.001 * 14
        for: 1m
        labels:
          severity: critical

Error Budget berechnen

# Verbleibendes Error Budget (letzte 30 Tage)
1 - (
  sum(rate(http_requests_total{status=~"5.."}[30d]))
  /
  sum(rate(http_requests_total[30d]))
) / (1 - 0.999)
# Wert 1.0 = Budget voll, 0 = Budget leer, <0 = SLO gerissen!

# Downtime-Minuten (bei 99.9% SLO, 30 Tage)
# Budget: 30 * 24 * 60 * 0.001 = 43.2 Minuten

# Verbraucht:
(1 - slo_erfolgsrate) * 30 * 24 * 60

Grafana SLO-Dashboard

Import Dashboard ID: 14981 – Sloth SLO Dashboard

Panels:
- Verfügbarkeit (letzte 7/30 Tage)
- Error Budget verbleibend (%)
- Burn Rate (1h / 6h / 24h)
- Slow Burn / Fast Burn Alerts

SLO-Vorlage für KMU

Website (öffentlich):
  Verfügbarkeit:   99.5% (3.6h/Monat Downtime erlaubt)
  Latenz p95:      < 2s
  Error Rate:      < 0.5%

Interne API:
  Verfügbarkeit:   99.9% (43 Min/Monat)
  Latenz p99:      < 500ms

Datenbank:
  Verfügbarkeit:   99.95% (22 Min/Monat)
  Write Latenz:    < 100ms p99

FAQ

Was passiert wenn das Error Budget aufgebraucht ist?
SRE-Best-Practice: kein Feature-Deploy mehr bis Budget sich erholt hat (nur Bugfixes/Reliability-Verbesserungen).

Fazit

SLOs mit Error Budgets geben Entwicklern und Ops gemeinsame Ziele – kein "Blame Game" mehr, sondern messbare Reliability-Verbesserung.

SRE und Service-Level-Management für KMU in Heidelberg, Mannheim und der Rhein-Neckar-Region. Anfragen.

Artikel teilen

War dieser Artikel hilfreich?

Dein Feedback hilft uns, bessere Inhalte zu erstellen.

Kommentar hinterlassen

Verwandte Artikel