SLA, SLO und Zuverlässigkeitskennzahlen

1) Begriffe und Unterschiede

SLI (Service Level Indicator) ist ein messbarer Qualitätsindikator (z.B. Anteil erfolgreicher Anfragen, p95 Latenz).
SLO (Service Level Objective) - SLI-Zielwert pro Zeitfenster (z. B. "Erfolg ≥ 99. 9% in 28 Tagen").
Budgetfehler (Error Budget) - der zulässige Anteil der Nichterfüllung von SLO: „1 − SLO“.
SLA (Service Level Agreement) - vertragliche Verpflichtungen mit Geldbußen/Krediten (extern).
Zuverlässigkeits-KPIs sind operative Prozessmetriken (MTTD/MTTA/MTTR/MTBF,% automatische Mitigate, Alert Coverage, etc.).

2) Wie wählt man SLI (basierend auf Golden Signals)

1. Latency - p95/p99 für wichtige Endpunkte.
2. Traffic - RPS/RPM/Nachrichtenfluss.
3. Errors - Anteil von 5xx/Geschäftsfehler (z.B. Zahlung „decline durch PSP Schuld“ ausschließen).
4. Sättigung - Sättigung von Ressourcen (CPU/RAM/IO/lag).

• Korreliert mit der Benutzererfahrung (user-perceived).
• Technisch verfügbar und stabil in der Messung.
• Wir kontrollieren (Maßnahmen zur Verbesserung sind möglich).
• Niedrige Kosten für die Sammlung.

3) Formeln und Beispiele

3. 1 Verfügbarkeit (availability)

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Beispiel: SLO 99. 9% in 30 Tagen → Fehlerbudget = 0. 1%, was 43 min 12 sec Nichtverfügbarkeit entspricht.

3. 2 Latenz

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Zahlungen (Geschäftsebene)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Fehlerhaftes Budget und Burn-Rate

Budgetfehler - Ihr „Treibstofftank“ für Innovationen (Freigaben, Experimente).

• schneller Kanal (Detail in ~ 1 h),
• langsamer Kanal (Trend ~ 6-12 h/24 h).

• Wenn Burn-Rate> 14. 4 für 1 Stunde - SEV-1 (wir essen das Tagesbudget für ~ 100 Minuten).
• Wenn Burn-Rate> 6 in 6 Stunden - SEV-2 (schnelle Degradation).

5) Alerting durch SLO (Multi-Window, Multi-Burn)

Fehlerindikator: Anteil von 5xx oder Latenzstörungen.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLI/SLO Beispiele nach Domain

6. 1 API-Gateway/Edge

SLI-Fehler: Anteil der Antworten 5xx <0. 1% (28d).
SLI-Latenz: p95 ≤ 250 ms (Tag).
SLO: Availability ≥ 99. 95% (Quartal).

6. 2 Zahlungen

SLI-Erfolg: Erfolgsabrechnung (ohne Kundenausfälle) ≥ 99. 8% (28d).
SLI-Latenz: Autorisierung ≤ 2 Sekunden für 99% (Tag).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Datenbanken (PostgreSQL)

SLI-Lag: Replikations-Lag p95 ≤ 1 sec (Tag).
SLI-Errors: Anteil der Abfragefehler ≤ 0 05% (28d).
SLO: Cluster-Verfügbarkeit ≥ 99. 95%.

6. 4 Warteschlangen/Streaming (Kafka)

SLI-Lag: Verbraucherlag von p95 ≤ N Nachrichten (Stunde).
SLI-Durability: Schreibbestätigung ≥ 99. 99% (28d).
SLO: Verfügbarkeit von Brokern ≥ 99. 9%.

7) KPI des Zuverlässigkeitsprozesses

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% der automatischen Mitigationsvorfälle

SLO/Alert-Abdeckung der Top-Verkehrswege (Ziel ≥ 95%)

Anteil der Freigaben mit Kanarienstufe

Verbrauch von fehlerhaften Budgets nach Teams/Fics

8) Wie man SLO realistisch setzt

1. Messen Sie die aktuelle Grundzuverlässigkeit (3-4 Wochen).
2. Identifizieren Sie „sensible“ Benutzerpfade (Login, Einzahlung, Spiel).
3. Berücksichtigen Sie die Kosten jeder Abweichung (Zeit, Geld, Ruf).
4. Wählen Sie ein ehrgeiziges, aber erreichbares Ziel (10-30% Verbesserung gegenüber dem Basisziel).
5. Überprüfen Sie vierteljährlich.

• Gleich „fünf Neuner“ ohne Begründung.
• SLO durch Metriken, die für den Benutzer nicht sichtbar sind (z. B. CPU ohne UX-Kommunikation).
• Zu viel SLO → Sprühen Fokus.

9) Berichterstattung über SLOs und Budgets

• Ausführung für jedes SLO: Tatsache vs Ziel, Trends, Vertrauen.
• Zusammenfassung des Fehlerverbrauchs: Wie viel Budget wird „verbrannt“ als von wem (Release/Incident).
• Top fünf Ursachen für Degradationen, CAPA-Plan und Aufgabenstatus.
• Auswirkungen auf das Geschäft: Conversion, ND, Retention, LTV.

10) Verknüpfung mit Release Policy

Fehlerbudget <50% → freie Releases.
50-80% → „vorsichtiger Modus“: nur low-risk/Kanarienschnitt.

11) SLA (vertraglich) - Klauselvorlagen

Verfügbarkeitspflicht: z.B. 99. 9 %/Monat.
Ausnahmen (Force Majeure): DDoS außerhalb angemessener Kontrolle, Drittanbieter.
Messfenster und Verantwortungsbereich: Metrikquellen, Berechnungsmethode.
Credits/Strafen: Tabelle der Stufen (z. B. Unzugänglichkeit 60-120 min → Kredit X%).
Eskalations- und Benachrichtigungsverfahren: Fristen, Kanäle.
Daten und Privatsphäre: Maskierung, Speicherung, Legal Hold.
Arbeitsplan zur Vermeidung von Wiederholungen (CAPA) im Falle eines Verstoßes.

12) Messwerkzeuge

Passive Metriken: Prometheus/Mimir/Thanos, Exporteure.
Logs: Loki/ELK für die Erfolgs-/Fehlerzählung auf Business-Ebene.
Synthetik: aktive Proben (Login/Einzahlung/Spiel) von cron.
Spurenlage: Tempo/Jaeger für „Engstellen“ p99.
Zahlung/Finanzen: Quellen der Ground Truth für Payment SLI.

13) Beispielabfragen (Vorlagen)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14) FinOps und Zuverlässigkeit

Kosten pro 9: Die Kosten für das Hinzufügen einer „Neun“ steigen exponentiell.
Nutzenkurve: Optimum, wo Umsatzsteigerung/Verlustminderung die Kosten der zusätzlichen „9“ ≥.
SLO-Portfolio: unterschiedliche Ebenen für unterschiedliche Pfade (kritische Zahlungen „teurer“, Reporting „günstiger“).

15) SLO/alert Qualität - Checkliste

• SLI korreliert mit UX- und Geschäftsmetriken.
• Fenster und Aggregation vereinbart (Rolling 28d/Quartal).
• Alerts Multi-Fenster, ohne Flapping, mit Rollenführung.
• Dokumentation: Besitzer, Formel, Quellen, Runbook.
• SLO-Demo-Panel mit fehlerhaftem Budget und Burn-Indikatoren.
• Regelmäßige Überprüfung der Ziele (vierteljährlich).
• Synthesetests nach Schlüsselszenarien.

16) Implementierungsplan (4 Iterationen)

1. Woche 1: Inventar der Benutzerpfade, SLI-Entwürfe, grundlegende Dashboards.
2. Woche 2: SLO-Formalisierung, Budgetberechnung, Alerts (Fast/Slow Burn).
3. Woche 3: Integration in den Incident/Release-Prozess, Freeze-Regeln.
4. Woche 4 +: vertragliche SLAs, vierteljährliche Revuen, Finopmodell „cost per 9“.

17) Mini-FAQ

Brauche ich ein SLO pro Service?
Besser 2-3 Schlüssel (Erfolg + Latenz) statt Dutzende von sekundären.

Was tun, wenn das Budget erschöpft ist?
Freeze-Releases, Fokus auf Stabilisierung und CAPA, Rücknahme experimenteller Fich.

Wie vermeidet man den Konflikt zwischen Release-Geschwindigkeit und Zuverlässigkeit?
Planen Sie Veröffentlichungen „nach Budget“, implementieren Sie kanarische Layouts und Feature-Flags.

Ergebnis

Die Zuverlässigkeit wird nicht durch eine Reihe unterschiedlicher Metriken gesteuert, sondern durch ein System: SLI → SLO → Budgetfehler → Burn Alerting → Incident Process → CAPA → SLA. Standardisieren Sie Definitionen, Datenquellen und Berichte, verknüpfen Sie Ziele mit Benutzererfahrung und Wirtschaftlichkeit und überprüfen Sie regelmäßig die Neunerstufe, abhängig vom tatsächlichen ROI.