Error Budgets und SLO-Management

1) Warum SLO und Fehlerbudget

SLO (Service Level Objective) - das vom Benutzer wahrgenommene Qualitätsziel; SLI ist eine messbare Metrik; Fehlerbudget - Toleranz für Abweichungen pro Fenster (in der Regel 30/90 Tage).
Das Fehlerbudget verwandelt die Zuverlässigkeit aus einer „Abstraktion“ in eine überschaubare Ressource: Wenn das Budget schnell verbrennt, frieren wir Fichi und Cinim ein; Wenn das Budget gesund ist, können Releases beschleunigt werden.

2) SLI-Auswahl: Was als „gut“ gilt

Kriterium: „aus Nutzersicht erfolgreich“.

2. 1 Klassische SLIs

Verfügbarkeit: Anteil der erfolgreichen Anfragen (ausgenommen stornierte Anfragen des Kunden).
„Erfolg = http_status ∈ {2xx, 3xx, 404} und kein Timeout“ (404 kann als Erfolg für die Read-API angesehen werden, wenn dies die erwartete Semantik ist).
Latenz: Der Anteil der Anforderungen ist schneller als der Schwellenwert (z. B. p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness: „Daten nicht älter als X Minuten“ (Cache, Verzeichnisse, Koeffizienten).
Qualität: Korrektheit des Ergebnisses (Passage von Business Validators/Backend-Invarianten).

2. 2 Grenzen und Segmente

Der SLI muss in wichtigen Abschnitten gezählt werden: 'route', 'tenant/brand', 'region/jurisdiction', 'payment _ provider'. So „verwischen“ Sie nicht den Ausfall eines kritischen Pens im gesamten System.

3) Formeln und Budget

3. 1 Anforderungsbasiert (bevorzugt für API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Zeitbasiert (für Hintergrunddienste/Streaming)

SLO_uptime = good_minutes / total_minutes

3. 3 Beispiel für Ziele

APIs allgemein: 99. 9% Verfügbarkeit in 30 Tagen → Budget = 0. 1%.
Kritische Zahlungsgriffe: 99. 95%; Verzeichnisse/Suche: 99. 5%.
Latenz: p95 ≤ 300 ms auf '/v1/payments', p99 ≤ 800 ms.

4) SLI-Instrumentierung

4. 1 Grundsätze

Logs/Traces → RED-Metriken (Rate/Errors/Duration) mit expliziten Buckets.
Achten Sie darauf, 'tenant', 'region', 'route _ class' (ohne PII) anzubringen.
Zählen Sie zwei Metriken: „Erfolg“ und „alles“ und für Latenz - „schnell“ und „alles“.

4. 2 Beispiel Prometheus (Rate pro 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alerts auf Burn Rate (Multi-Fenster, Multi-Burn)

5. 1 Idee

Wir schauen, wie schnell das Budget im Verhältnis zum Ziel verbrennt. Wenn die Geschwindigkeit auf einem kurzen und langen Fenster hoch ist, hupen wir.

5. 2 Schwellenprofile (für SLO 99. 9%)

Paging: Burn Rate ≥ 14. 4 × (10% des Budgets für 1 Stunde und 5% für 6 Stunden).
Ticket: Burn Rate ≥ 6 × (2% für 6 Stunden und 1% für 24 Stunden).

5. 3 Beispiel für Regeln (Prometheus, Pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Ebenso bei 6h/24h für das Ticket.

6) Budgetmanagement: Prozesse

6. 1 Release Gates

Wenn der Rest des Budgets <25% ist und der Trend negativ ist - „Code-Freeze“ auf Fichi, Priorität SRE/Nachhaltigkeit.
Kanarische Releases müssen einen separaten SLO-Schnitt ('deployment. environment="canary"`).

6. 2 Priorisierung des Becklogs

Verteilen Sie die Teamkapazität proportional zur Verbrennungsgeschwindigkeit und den Auswirkungen auf den Umsatz.
Begründen Sie die technische Verschuldung mit den Metriken: „Fix X wird die Burn Rate um Y% senken“.

6. 3 Post-Vorfall

Jeder Vorfall ist ein RCA und ein „Fix, der nicht rückgängig gemacht werden kann“ (actionable), eine Kontrolle, „ob er in den SLO zurückgekehrt ist“.

7) SLO als Code

7. 1 Beispiel für ein SLO-Manifest (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Generierung von Regeln

Verwenden Sie Generatoren (slo-generator, pyrra, sloth), um automatisch Regeln, Dashboards und Berichte zu erstellen.

8) SLO Abbau und Schutz

Load shedder: Geben Sie schnelle Antworten ohne „teure“ Abhängigkeiten an der Spitze.
Cache & stale: `stale-while-revalidate` для read.
Rate/Concurrency limits: schützt Backends; Wichtige Routen haben Priorität.
Schaltung/Timeout: Schnelle Timeouts und „Fallback“ -Zweige.
Feature-Flags: Deaktivieren Sie schwere Fich mit einer Taste.

9) Beobachtbarkeit für SLO

Dashboards: SLO tatsächlich vs Ziel, Budget Rest, Burn Rate, Beitrag auf Routen/Anbieter.
Korrelation: Aus dem „Loch“ des SLO → im Beispiel → eine bestimmte Spur → Protokolle/Profile.
Berichte: wöchentlich - Trends, Budgetverbrauch, Top-Ursachen für Degradationen.

10) Antipatterns

Ein „globales“ SLO für die ganze → verschleiert die Probleme. Segmentieren Sie.
«99. 99% auf alles" ohne Kosten und Realität. Wählen Sie Ziele aus der Benutzererfahrung.
Alerts über CPU/Heap statt Burn Rate/SLO.
Ignorieren von 4xx/langen Weiterleitungen, die UX verderben.
Undurchsichtiges Fenster (Rolling vs Kalender) - Vergleiche von „Äpfeln mit Orangen“.

11) Spezifität von iGaming/Finanzen

Geldwege (Ein-/Auszahlungen): Einzelne SLOs liegen über dem Gesamtniveau (z.B. 99. 95% Verfügbarkeit; p95 ≤ 250 ms)

PSP/KYC-Anbieter: SLOs für jeden Anbieter + Alerts für ihren Beitrag zu Burn; Automatische Routenumschaltung (Smart Routing).
Jurisdiktionen/Tenants: SLOs und Budgets nach 'region/jurisdiction/brand', damit das lokale Problem die globale Metrik nicht „überflutet“.
Verantwortungsvolles Spielen: SLO für die Dauer der Limits/Selbstausschlüsse (Compliance-Formeln).
Audit/Regulierung: Speichern Sie SLO und Incident Reports; Transparenz für interne Audits.

12) Checkliste Prod-Ready

• SLIs (availability/latency/quality/freshness) und Segmente (route/tenant/region) sind definiert.
• Die Ziele (SLO) sind realistisch und mit dem Unternehmen abgestimmt; es gibt rollende Fenster 30/90 Tage.
• Alerts auf Burn Rate mit Multi-Fenstern (Paging/Ticket).
• SLO als Code (Regelgenerator/Dashboards); Haushaltsberichte.
• Release Gates sind an den Rest des Budgets gebunden; Kanarienscheiben.
• Degradationsmechanismen (Shedder, Cache Stale, Circuit, Limits) werden implementiert und getestet.
• Korrelation von Metriken ↔ Traces (Beispiele), klare Runbooks.
• Finanzielle/gerichtliche Wege - einzelne SLO/Warnhinweise; PSP/KYC sind getrennt.
• Regelmäßige Retro-Incidents und Investitionen in Zuverlässigkeit basierend auf Burn.

13) TL; DR

Definieren Sie den SLI anhand des Benutzerwerts, legen Sie realistische SLOs fest, und steuern Sie über Error Budget und Burn Rate mit Multi-Fenstern. Aktivieren Sie SLO-as-a-Code, Release-Gates und Degradierung nach Plan. Segmentieren Sie nach Routen/Tenanten/Regionen; Halten Sie für Geldpfade härtere Ziele und separate Alerts.