SLO, SLA und Zuverlässigkeitsüberwachung

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

SLO ist ein internes Qualitätsziel, SLA ist eine externe Verpflichtung gegenüber dem Kunden, SLI ist, wie wir Qualität messen. In iGaming sind die wichtigsten SLIs: API-Verfügbarkeit und Gebühren, p95/p99-Latenz kritischer Routen, Time-to-Wallet (TTW), Zahlungsumwandlung, Spielstart sowie Warteschlangenmetriken. Das Zuverlässigkeitsmanagement basiert auf einem Fehlerbudget, Multi-Burn-Alerts, klaren Release-Gates und visuellen Dashboards mit Anmerkungen.

1) Begriffe und Unterschiede

SLI (Service Level Indicator) ist ein messbarer Indikator (z.B. Anteil erfolgreicher Anfragen pro Zeitfenster).
SLO (Service Level Objective) - SLI-Zielwert (z.B. "Verfügbarkeit 99. 9% in 30 Tagen").
SLA (Service Level Agreement) - Vertrag/Verpflichtung mit Entschädigung; basiert auf echten SLOs, umfasst aber rechtliche Vorbehalte und Ausschlussfenster (geplante Wartung, höhere Gewalt).

Regel: Zuerst den SLI/SLO innen stabilisieren und erst dann den SLA nach außen fixieren.

2) SLI-Rahmen für iGaming

TexSLO

Verfügbarkeit: erfolgreiche 2xx/3xx/alle Anfragen.
Latenz: p95/p99 auf den Schlüsselrouten („/deposit', “/bet', „/game/init “).
Errors: Anteil 5xx/Timeouts.
Saturation/Queues: Verzögerung bei Auszahlungs-/Transaktionswarteschlangen.

Business-SLI

Payment conversion: `success/attempt`.
TTW p95: Zeit von der Auszahlungsanfrage bis zur Einschreibung.
Spielstart-Erfolg: Spielsitzungen, Initialisierung des Anbieters.
KYC/AML Flow Erfolg: Erfolgreicher Abschluss der Reise.

3) Fehlerbudget: Wie man zählt

Error Budget = 1 − SLO.
Beispiel: SLO der Verfügbarkeit 99. 9 %/30d ⇒ Fehlerbudget = 0. 1% der Zeit ≈ 43min 12s in einem 30-Tage-Fenster.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO wird auf einem Schiebefenster gezählt (30/7/1 Tag) und ist auf Dashboards sichtbar.

• Schnelles „Verbrennen“ des Budgets → Freeze-Releases, Canary Stop, Arbeiten an der Stabilität.
• → erlauben häufigere Änderungen (kontrolliert).

4) SLO-Beispiele für Key Streams

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (Ausgabe) ≤ 3 min/24h

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job-Erfolg ≥ 99 %/7d, lag <5 min (Spitzenfenster separat).

5) Messung: Formeln und PromQL (Ideen)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Burn-Rate Alerts (Multi-Fenster)

Die Idee: Wir vergleichen die aktuelle Ausgabenquote des Budgets mit der zulässigen.

• Fast Burn: 14 × Budget für 1 Stunde → eine Seite in 5-15 Minuten.
• Slow Burn: 6 × Budget für 24 Stunden → Ticket, Analyse der Ursache.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) Dashboards „SLO-Karte“ und Betriebssystem

• Karten für Dienste: Verfügbarkeit, p95, Fehlerrate, Burn-Rate, Rest des Fehlerbudgets.
• Filter: 'env', 'region', 'tenant', 'version'.
• Anmerkungen zu den Releases: Git SHA, Typ (kanarisch/blau-grün), Schaltzeit.

• Vergleich stable vs canary.
• Schnitt durch PSP/Spieleanbieter.
• Navigieren Sie zu den Beispielen (trace_id) und verknüpften Protokollen.
• Queue lag und Sättigung (USE-Metriken).

8) SLO-Prozesse: Gates, Freeze, Eskalationen

Gates in CD: Canary Promotion ist nur erlaubt, wenn ein SLO-Proxy ausgeführt wird (availability, p95, conv).
Freeze: mit Fast-Burn oder Null-Budget-Saldo - Stoppen Sie die Veröffentlichungen vor der Wiederherstellung.
Eskalationen: SEV-Matrix (SEV1 Zahlungen/Einzahlungen, SEV2 Spiele, SEV3 Backophis).
RCA: Analyse ohne Gebühren, Aktualisierung der Tests/Limits/Ficheflags.

9) Daten/ML-SLO (für Recommender/LLM)

Latenz: p95 Antwortmodell ≤ 300 ms (oder Token/s ≥ N).
Qualitätsproxy: Anteil der validen Reaktionen/geringe Toxizität, Anteil der Hilfe.
Freshness: Das Alter der Daten ≤ X Stunden.
Kosten pro 1k Veranstaltungen: Ausgaben im Haushalt.
Die SLO-Gates werden in die Modellfreigaben (A/V/Kanarienrollout) integriert.

10) SLA-Design basierend auf SLO

Wählen Sie konservative SLOs als Basis für SLAs.
Definieren Sie Ausnahmen (geplante Arbeiten, externe abhängige Anbieter, Störfallregelungen).
Geben Sie Entschädigungen nach Verletzungsstufen (Gutschrift/Rabatt), Berichts- und Verifizierungsmechanismen ein.

11) Häufige Fehler und Anti-Muster

Kein SLO, nur „uptime 100%“ - unrealistisch, demotivierend und Risiken versteckend.
Alerts für „jede Metrik“ statt Burn-Rate - alert-fetig und ignorant.
Mix PII in Metriken/Logs für SLO - Compliance-Risiken.
Die Kardinalität explodiert: 'user _ id/session _ id' als Labels.
Fehlende Release-Annotationen - Es ist schwierig, Degradationen mit Änderungen in Verbindung zu bringen.
Intransparentes Fehlerbudget - das Team versteht nicht, wann es „möglich“ ist, Risiken einzugehen.
SLO ist nicht an das Geschäft gebunden - die Techmetriken sind „grün“, die Einnahmen „rot“.

12) Checkliste Umsetzung

1. Genehmigen Sie grundlegende SLIs (Verfügbarkeit, p95/p99, Fehlerrate, TTW, Konvertierung).
2. Legen Sie den SLO auf 30/7/1-Tage-Fenster fest und zählen Sie das Fehlerbudget.
3. Fügen Sie recording rules und burn-rate alerts (fast/slow) hinzu.
4. Erstellen Sie eine SLO-Karte mit Release-Annotationen und Canary/Stable-Vergleichen.
5. Schalten Sie die Tore in die CD ein: ohne SLO-ok - ohne Promotion.
6. Geben Sie die Freeze-Prozeduren und die SEV-Matrix der Eskalationen ein.
7. Verknüpfen Sie SLO mit Geschäftsmetriken (conv, TTW) und Zahlungswegen.
8. Definieren Sie für Data/ML latency/quality/freshness-SLO.
9. Regelmäßige RCAs und Überprüfung der SLOs/Schwellenwerte (vierteljährlich).
10. SLA erst nach Stabilisierung des SLO dokumentieren.

13) Beispiele für „fertige“ Ziele (als Start)

APIs allgemein: Verfügbarkeit 99. 9 %/30д; p95 ≤ 250 ms/30d; Error-rate ≤ 0. 3 %/30д.
Payments: Conversion ≥ baseline − 0. 3 %/24ч; TTW p95 ≤ 3 min/24h.
Games init: Success ≥ 99. 5 %/7д; p95 ≤ 600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; Lag ≤ 5 min/7d.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness ≤ 6h.

Ergebnisse

Der SLO/SLA-Ansatz macht Zuverlässigkeit von „besser als gestern“ zu einer messbaren Disziplin: transparente SLIs, ein nachvollziehbares Fehlerbudget, Brenngeschwindigkeitsalerts, verständliche Dashboards und in Releases eingebettete Qualitätstore. Diese Kontur gibt der iGaming-Plattform ein vorhersehbares p95/p99, stabile Zahlungen und TTW, was bessere Einnahmen und weniger Vorfälle in den heißesten Stunden bedeutet.