# SLOs & SLIs: Die Wissenschaft der Zuverlässigkeit (SRE Principles)

TL;DR / Management Summary “Das System muss immer laufen” ist keine realistische Anforderung. In der Welt des Site Reliability Engineering (SRE) definieren wir präzise Messgrößen: SLIs (Service Level Indicators) sind die harten Fakten (z.B. Latenz), SLOs (Service Level Objectives) sind die Zielwerte (z.B. “99.9% aller Anfragen < 200ms”). Ein Senior Admin nutzt diese Begriffe, um mit dem Business über Error Budgets zu verhandeln: Wie viel Unzuverlässigkeit dürfen wir uns leisten, um schneller neue Features auszurollen?

# 1. Die Begriffs-Hierarchie

Was ist was?

1. SLI (Indicator): Eine spezifische Metrik. (z.B. “Verfügbarkeit der OPNsense-API”).
2. SLO (Objective): Das Ziel für den SLI. (z.B. “API ist zu 99.95% im Monat online”).
3. SLA (Agreement): Der Vertrag mit dem Kunden. (z.B. “Wenn die API < 99.9% online ist, zahlen wir Strafe”).
   • Wichtig: Ihr internes SLO sollte immer strenger sein als das externe SLA!

# 2. Gute SLIs definieren

Messen, was der User fühlt.

Wählen Sie Metriken nach dem RED-Modell:

• Rates: Anzahl der Requests pro Sekunde.
• Errors: Anzahl der fehlgeschlagenen Requests.
• Duration: Zeit bis zur Antwort.
• Senior Tipp: Messen Sie die Latenz nicht als Durchschnitt (Mean), sondern in Perzentilen (z.B. P99). “99% aller User erhalten eine Antwort in < 500ms”.

# 3. Deep Dive: Das Error Budget

Die Erlaubnis zum Fehlermachen.

Ein SLO von 99.9% bedeutet ein Error Budget von 0.1% pro Monat (ca. 43 Minuten Downtime).

• Nutzung: Solange das Budget voll ist, darf das Team riskante neue Features oder Proxmox-Updates (Artikel 719) ausrollen.
• Budget aufgebraucht: Wenn die 43 Minuten weg sind -> Feature Freeze. Der Fokus liegt nun zu 100% auf Stabilisierung und Fehlersuche.

# 4. Day-2 Operations: Burn-Rate Monitoring

Frühzeitig warnen.

Nutzen Sie Prometheus (Artikel 817), um die Burn-Rate Ihres Error Budgets zu überwachen.

• Alarm: “Wir verbrauchen unser Monats-Budget gerade mit 10-facher Geschwindigkeit!”
• Vorteil: Sie reagieren Stunden bevor das SLO offiziell verletzt wird.

# 5. Troubleshooting & “War Stories”

Wenn die Metrik lügt.

# Top 3 Fehlerbilder

1. Symptom: SLI zeigt 100% Erfolg, aber User rufen wütend an.

   • Ursache: Sie messen an der falschen Stelle (z.B. am Loadbalancer, der “200 OK” liefert, während die App dahinter eine leere Seite zeigt).
   • Lösung: Messen Sie die End-to-End Funktionalität.

2. Symptom: Unmögliche SLOs (z.B. 100%).

   • Folge: Ständige Frustration und Ignorieren von Alarmen.
   • Lösung: Akzeptieren Sie, dass Hardware und Netzwerke (Artikel 721) immer Fehler machen.

3. Symptom: Zu viele SLIs vernebeln die Sicht.

# “War Story”: Der “Erfolgreiche” Error

Ein Team definierte seinen SLI als “HTTP Status 200 Rate”. Das Ereignis: Die Datenbank stürzte ab. Die Applikation fing den Fehler ab und zeigte eine hübsche Fehlermeldung (“Entschuldigung, wir sind gleich wieder da”). Das Ergebnis: Da die Applikation technisch korrekt mit HTTP 200 antwortete (um die Fehlermeldung zu senden), blieb der SLI bei 100%. Die Admins schliefen weiter, während der Dienst für 4 Stunden tot war. Lehre: Ein SLI muss den semantischen Erfolg messen. Suchen Sie nach spezifischen Inhalten im Body oder nutzen Sie korrekte HTTP Error Codes (5xx).

# 6. Monitoring & Reporting

Transparenz für das Management.

# SLO Dashboard (Grafana)

Bauen Sie ein Board mit:

• Remaining Error Budget (%).
• Estimated Time until Budget Exhaustion.
• Service Reliability Trend (Letzte 12 Monate).

# 7. Fazit & Empfehlung

SLOs sind der Friedensvertrag zwischen Entwicklung und Betrieb.

• Empfehlung: Starten Sie mit zwei SLIs pro Dienst: Verfügbarkeit und Latenz.
• Wichtig: Überprüfen Sie Ihre SLOs quartalsweise. Wenn ein SLO nie verletzt wird, ist es vielleicht zu locker und motiviert das Team nicht zur Verbesserung.

# Anhang: Cheatsheet (Downtime-Tabelle)

# Referenzen

• Google SRE Book: Service Level Objectives
• The SLO Book (Alex Hidalgo)
• Prometheus: Alerting on SLOs