SLO/SLA und Metriken

SLO/SLA und Metriken

1) Begriffe und Hierarchie

SLI (Service Level Indicator) ist ein messbarer Indikator für „wie der Benutzer uns sieht“: Anteil der erfolgreichen Anfragen, p95-Latenz, Frische der Daten, Anteil der erfolgreich verarbeiteten Schlachten usw.
SLO (Service Level Objective) ist der SLI-Zielwert für das Beobachtungsintervall (28/30/90 Tage). Beispiel: "99. 9% der Anfragen/Zahlungen enden ≤ 400 ms".
Error budget — 1 − SLO. Bei SLO 99. 9% Fehlerbudget = 0. 1% der Zeit/Anfragen.
SLA (Agreement) - rechtlich relevantes Serviceniveau: beinhaltet SLO, Messung, Ausnahmen, Entschädigungen/Strafen.

2) Gestaltungsprinzipien

Symptome> interne Metriken. SLIs sollten die tatsächliche Benutzererfahrung widerspiegeln.
Eine kleine Anzahl von Schlüssel-SLIs. Pro Service - 2-5 Haupt: Erfolg, Latenz, Bandbreite/Frische, Korrektheit.
Abdeckung kritischer Pfade. Für jedes Geschäftsszenario (Checkout, Login, Webhook, ETL-Download) ein anderes SLI/SLO-Set.
Die strenge Semantik des „Erfolgs“. Nicht „Code 200“, sondern „der Nutzer hat rechtzeitig eine Antwort erhalten und das Ergebnis ist gültig“.
Trennung von externen und internen SLOs. Intern - strenger; Der externe SLA ≤ 1-2 Neunen niedriger.

3) SLI-Katalog (Referenz)

3. 1 API/Online-Dienste

Erfolgsrate: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Latenz: p95/p99 'http _ server _ duration _ seconds' nach Route/Methode/Mieter

Kapazität: 'RPS '/Limits/Kontingente

Korrektheit: Anteil gültiger Antworten (Signaturen, Schemata, Invarianten)

3. 2 Webhooks/asynchrone Lieferungen

Lieferung: Anteil der in T-Sekunden und ≤ N-Retrays bestätigten Ereignisse

Kunden: Anteil der Abonnenten ohne große Verzögerung (per tenant)

3. 3 Daten/ETL/DWH

Frische: "jetzt − last_successful_ingest_ts'

Vollständigkeit: 'ingested _ rows/ expected_rows'

Korrektheit: Anteil der Datensätze, die Qualitätsprüfungen bestanden haben

Piplines: Jobanteil vor Deadline abgeschlossen

3. 4 Mobile/Client SDKs

Kundenerfolg: Anteil der Sitzungen ohne fatale Fehler

Round-Trip-Latenz: p95 von der Abfrage bis zum Renderer

Cache-Hits: Anteil der Servierten aus dem Cache (als Performance-Symptom)

4) Formeln und Beispiele für Ziele

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% 'für 30 Tage → error budget = 0. 05% der Anfragen.

• `uptime = (obs_window − downtime) / obs_window`

• „SLO _ latency = p95 (route = “/pay„) ≤ 400 ms “auf 7-Tage-Scheiben, mit Ausnahme von Cache-Aufwärmen (1%)

• "SLO _ freshness (dataset =" orders ") ≤ 10 min 'p99 in 24 Stunden.

5) Fehlerbudget und Änderungsmanagement

Haushaltsmittel (B): „B = 1 − SLO“.
Budgetausgaben (burn): Verhältnis der tatsächlichen Fehler zu den zulässigen.

• Überschreitung (burn> 1) → fichfriz, Fokus auf Zuverlässigkeit.
• Bei Burn Rate> X in einem kurzen Fenster - Incident und Cape. Maßnahmen.
• Planung: Der Anteil des Sprints an der Zuverlässigkeit korreliert mit dem Burn für den letzten Zeitraum.

6) Alerting: Burn Rate und Multi-Window-Regeln

Die Idee: Wir fangen schnelle Lecks und langsames Driften.

• Kritisch: „2% des Budgets in 1 Stunde“ (schnelles Feuer).
• Warnung: „5% des Budgets in 6 Stunden“ (schleichende Degradierung).

• Ein kurzes Fenster (Minute-Stunde) für schnelle Vorfälle.
• Langes Fenster (6-24 Stunden) für Trends.
• Latenz: alert auf p99> Schwelle von ≥5 min, mit Unterdrückung von Flapping und Kommunikation mit Instanzen von Spuren.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Multi-Leasing (Multi-Tenant) und Segmentierung

SLI/SLO werden nach Mietern/Plänen/Regionen gezählt, ansonsten wird der Median die Ausfälle „vertuschen“.
Die minimale Anzahl von Ereignissen für die statistische Signifikanz (guard-rails).
SLA kann nach Tarifen variieren (z.B. "Pro 99. 9%, Free 99. 5%»).

8) Zusammenhang mit Beobachtbarkeit und Traces

SLI-Metriken - von Histogrammen/Zählern mit Beispielen → Übergang zu „schlechten“ Traces.
Logs sind die Quelle der Ursachen: Timeouts, Business Error Codes, Limits.
Für die Daten gibt es eine Verbindung zur Lineage: „Welcher Job hat die Frische-Metrik verzögert“.

9) Verträge und SLAs

• SLI/Messmethode/Fensterdefinitionen.
• Ausnahmen (geplante Arbeiten, höhere Gewalt).
• Verfahren für Incidents und Kommunikation (Status-Seite, RFO/RCA).
• Entschädigung (Service Credits) und die Reihenfolge der Anfrage.
• Gerichtsstand, Gültigkeitszeitraum, Revisionsbedingungen.

• Versprechen Sie niemals öffentlich SLOs strenger, als es die Architektur und die Betriebspraktiken erlauben.
• Trennen Sie interne SLOs und externe SLAs.

10) Kosten und Priorisierung

Der Preis der Neunen steigt nicht linear. «99. 9% → 99. 99%" = eine andere Architekturklasse (N + 1, Multizone, Asset-Asset).
Setzen Sie SLO auf die wertvollsten Benutzeraktionen.
Steuern Sie die Kosten der Telemetrie: Downsampling, Quoten, Replik und Lagerung nach Klassen.

11) Verfahren und Berichterstattung

Wöchentliche Berichte: Durchführung von SLOs durch Dienstleistungen/Mieter, Budgetausgaben, Top-Gründe, Verbesserungspläne.
Postinzidente RCAs: Verknüpfung mit Budgetteilen; Wir setzen uns die Aufgabe, die Ursachen zu beseitigen.
Fichfriz: Ein-/Rücknahmekriterien.

12) Vorlagen (für einen schnellen Start)

12. 1 SLO-Karte (Beispiel)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 Tabelle „SLO-Reife“

13) Regelbeispiele (Fragmente)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO für Daten und ML (Features)

End-to-End-Daten-SLOs: Frische von p99, Vollständigkeit von p99, Zeit des „Re-Working“ nach einem Ausfall.
Datenverträge: erwartete Schemata, Volumen, Fristen; Verletzung → Vorfall von Daten.
ML: SLO auf Inferenz-Latenz, SLA auf Verfügbarkeit des Fitch-Stores, Driftüberwachung (Modellqualität ist ein separates Thema, außerhalb des SLA).

15) Integration mit Sicherheit und Privatsphäre

SLI-Logs ohne PII/Geheimnisse; Tokenisierung/Maskierung.
Prüfung von SLO/SLA-Änderungen und Berichtsveröffentlichungen in unveränderlichen Journalen.
Für regulatorische Wege (Zahlungen/PII) - separate, strengere SLOs.

16) Checklisten

Vor dem Start des Dienstes/der Funktion

• SLI „Erfolg/Latenz/Durchsatz/Frische“ definiert.
• SLO und Fenster eingestellt; Das Fehlerbudget wird berechnet.
• Burn-Rate-Alerts konfiguriert (kurz + lang).
• Dashboards RED + Beispiele → Strecke; Runibooks von Vorfällen.
• Multiartikelschnitte und Signifikanzschwellen.
• Fichfries- und Berichtsverfahren.

Betrieb

• Wochenbericht zu SLO/burn, hardening plans.
• Neubewertung von SLO bei Architektur-/Lastwechsel.
• Periodische „Zwischenfall-Übungen“ und Aktualisierung der Runybuks.
• Kontrolle der Telemetriekosten und der SLI-Menge.

17) Runbook’и

Runbook: Schnelles Wachstum von p99/pay

1. Alert p99> Schwelle → Öffnen Sie das Dashboard → gehen Sie zum Beispiel zum Trace.
2. Schmale CLIENT/SERVER-Span finden, Regionen/Versionen vergleichen.
3. Degradierung aktivieren (Cache/Limit/Vollback), Abhängigkeitsbefehl benachrichtigen.
4. Nach Stabilisierung - RCA, Optimierungsprobleme, Aktualisierung der SLO-Messungen.

Runbook: Budgetausgaben> 50% pro Woche

1. Fichi einfrieren, Zuverlässigkeit priorisieren.
2. Fehlerclusterbildung: nach Routen/Mietern/Abhängigkeiten.
3. Rollen Sie die Korrekturen aus → bestätigen Sie die Trendwiederherstellung.
4. Retrospektive und Anpassung der Warnhinweise/Schwellenwerte.

18) FAQ

F: Wie viel SLO wird benötigt?
A: Minimum für kritische Benutzerszenarien: Erfolg + Latenz. Alles andere ist notwendig.

Q: Was ist besser - Verfügbarkeit nach Zeit oder auf Anfrage?
A: Auf Anfrage - mehr benutzerdefinierte Metrik. Zeitlich günstig für Netzwerkkomponenten/infra.

F: Warum p95 und nicht Durchschnitt?
A: Der mittlere verbirgt den Schwanz; Benutzer fühlt p95/p99.

F: Wie kann man die Schrauben nicht zu stark „anziehen“?
A: Beginnen Sie mit realistischen Zielen (historische Daten) und verschärfen Sie dann, wenn Sie reif sind.

• „Beobachtbarkeit: Protokolle, Metriken, Traces“
• „Verteilte Traces“
• „Audit und unveränderliche Protokolle“
• „Garantien für die Lieferung von Webhooks“
• „Verschlüsselung in Transit/At Rest“
• „Herkunft der Daten (Lineage)“