SLA und SLO Überwachung

1) Begriffe und Rollen

SLA (Service Level Agreement) ist eine externe vertragliche Verpflichtung gegenüber dem Kunden (Strafklauseln, Gutschriften).
SLO (Service Level Objective) ist eine interne Service-Ebene, die die Ausführung von SLAs unterstützt.
SLI (Service Level Indicator) ist ein messbarer Indikator, auf dessen Basis SLO/SLA bewertet werden.
Fehlerbudget - zulässiger Anteil der „Nichtverfügbarkeit/Fehler“ pro Periode: 'Budget = 1 − SLO'.
Scope: gemessen durch die Augen des Benutzers (Ende-zu-Ende). In Microservices - sowohl auf Komponenten- als auch auf End-to-End-Ebene.

2) SLI-Auswahl: Was genau gemessen werden soll

Das Kriterium ist die Korrelation mit der Benutzererfahrung und dem Geschäftswert.

• Verfügbarkeit: Anteil der erfolgreichen Anfragen. 'SLI = erfolgreich/alle'.
• Latenz: Der Anteil der Anfragen ist schneller als der Schwellenwert T. „SLI = P (latency ≤ T)“.
• Qualität: Anteil korrekter Antworten (ohne 5xx/funtz. Fehler).
• Datenaktualität: Replikationsverzögerung/ETL ≤ X Minuten.
• Wirksamkeit des Geschäftsprozesses: Anteil der erfolgreichen Zahlungen/Registrierungen.

Anti-Muster: Zählen Sie nur 200-ki als „Erfolg“ und ignorieren Sie Geschäftsfehler; Messen im Testnetz statt im Anwendernetz.

3) Formeln und Beobachtungsfenster

• `Availability = (OK_requests / All_requests) × 100%`.

• „P95 ≤ T“ → besser ausgedrückt als Anteil: „SLI =% der Anfragen ≤ T“.
• Beispiel: „99% der Suchanfragen ≤ 300 ms in 28 Tagen“.
• Schiebefenster: 28 oder 30 Tage (Balance von Empfindlichkeit und Stabilität). Für Vorfälle - zusätzliche Fenster: 1 h, 6 h, 24 h.

4) Fehlerbudget und Änderungsgeschwindigkeitssteuerung

Berechnung: bei 'SLO = 99. 9% „Budget =“ 0. 1% 'Fehler/Nichtverfügbarkeit pro Periode.

• Budget> 50%: Releases und Experimente nach Plan.
• Budget 10-50%: nur risikoarme Veröffentlichungen, Verschärfung der Kanarienvögel.
• Budget <10%: Release Freeze, Root Cause, Zuverlässigkeitsverbesserungen.
• Verbindung zu progressiven Releases: Kanarische/Feature-Flags „fressen“ das Budget dosiert, mit Auto-Rollback beim Abbau.

5) Alert-Politik: Von Schwellenwerten zu Burn Rate

Warum nicht „daupal SLO - hebe alert“: zu spät. Wir brauchen Proaktivität.

• „BR = (beobachteter Fehler in einem kurzen Fenster/zulässiger Fehler in diesem Fenster)“.
• Wenn 'BR> 1' - das Budget wird schneller ausgegeben als normal.

• Schnelle Alert (Lärm ist empfindlich, fängt Katastrophen): Fenster 5-10 min, Schwelle BR 14-20 ×.
• Langsame Alert (fängt schleichende Degradation): Fenster 1-6 h, Schwelle BR 2-4 ×.
• Bedingungen zu kombinieren: schnell oder langsam gearbeitet - Paging on-call.
• Ebenen: Pager für benutzerdefinierte SLOs, Tickets/Benachrichtigungen für graue Degradationen interner SLIs.

6) Beobachtbarkeit und Quellen der Wahrheit

Logs - Diagnose der Ursachen.
Metriken sind numerische SLIs (Erfolg/Fehler, Perzentillatenzen, Anteile, Zähler).
Traces - End-to-End-Pfade, Lokalisierung von „heißen“ Segmenten.
Synthetik - aktive Proben aus der Peripherie (Region-Aware).
Reale Ereignisse - RUM/Kundentelemetrie, Geschäftsmetriken (Conversion, erfolgreiche Zahlungen).

Anforderungen: einheitliches Bild in Dashboards von Releases und Incidents, Anmerkungen „Version/Kanarienvogel/Flagge“.

7) SLO-Entwurf: Schritt-für-Schritt-Vorlage

1. Beschreiben Sie den kritischen Weg (z.B. „Einzahlung mit Karte“).
2. Definieren Sie SLI: Erfolg/Fehler, Latenzschwelle, Vollständigkeit.
3. Vereinbaren Sie SLO: Ziel für 28 Tage + Ausnahmen (geplante Fenster).
4. Verknüpfen Sie mit SLA: rechtliche Verpflichtung ≦ tatsächliche SLO.
5. Weisen Sie den Eigentümer (Service Owner), RACI und den Alert-Kanal zu.
6. Definieren Sie Alert-Richtlinien (zwei Fenster BR) und Auto-Rollbacks.
7. Implementieren Sie die Berichterstattung: wöchentliche Budgetüberprüfungen, Post-Incident-Reviews.
8. SLO vierteljährlich überprüfen (Last-/Architekturwechsel).

8) SLO-Beispiele (Vorlagen)

• Verfügbarkeit: '≥ 99. 95%'(28d, ausgenommen angekündigte Fenster ≤ 30 min/mo).
• Latenz: „≥ 99%“ der Antworten „≤ 400 ms“.
• Geschäftserfolg: '≥ 98. 5% 'erfolgreiche Autorisierungen (Fraud-Filter berücksichtigt).

• Latenz: „≥ 99%“ der Anfragen „≤ 300 ms“.
• Cache-Relevanz: '≤ 5 min' Verzögerung in 99% der Fälle.

• Lieferung: ≥ 99. 9% 'innerhalb von' ≤ 60 s'(Ende-zu-Ende, mit Retrays).
• Verlust: '≤ 0. 01% 'der Nachrichten (Idempotenz/Deduplizierung enthalten).

9) Multi-Region und Multi-Tenant

SLO „nach Kohorten“: Land, Zahlungsanbieter, VIP-Segment, Gerät.
Lokale SLOs am Rand: Metriken von Punkten, die dem Benutzer am nächsten sind (Edge/PoP).
Aggregation: Das Gesamt-SLO sollte Misserfolge in wichtigen Kohorten nicht verbergen.
Anbieterwechsel: Automatische Fallback-Routen auf SLO-Gate-Ebene.

10) Dashboards und Berichterstattung

Release Dashboard: Version, Kanarienvogel (% des Traffics), SLI (Erfolg/Latenz), BR, Flag Annotationen.
Operative Dashboards: Burn-down-Budget nach Tagen, Top-Vorfälle, MTTR, Problemkohorten.
Wochenberichte: Budget-Rest, BR-Trends, technische Schulden (Engpässe), Verbesserungsplan.

11) Prozesse: Incidents, RCAs und Verbesserungen

Incident Management: Alert → BR-Bewertung → Kanariengröße/Flaggen → Rollback/Fix.
RCA (root cause): facts/timeline/hypotheses/corrections/effect check by SLI.
Lessons Learned: Nicht-ernsthafte Post-Mortems, obligatorische Aktionselemente mit Eigentümern und Fristen.
Zyklusschluss: Änderungen bei Tests, Ficha-Flags, Limits, Caches, Retrays, Quoten.

12) Compliance und Audit

SLO/SLI als Kontrollartefakte (Policy-as-Code, unveränderliche Protokolle).
Bindung an Anforderungen (z.B. Verfügbarkeit von Zahlungsvorgängen).
Beweise: Alert-Protokolle, Budgetberichte, Veröffentlichungs-/Rollback-Protokolle.

13) Häufige Fehler und wie man sie vermeidet

“99. 99% oder Tod": unerreichbare Ziele → ständiges Alert-Noise. Wählen Sie realistische SLOs.
Globale Durchschnitte verbergen lokale Misserfolge → führen Kohorten ein.
Metriken sind nicht e2e: Hohe SLOs bei tatsächlichem Abbau auf dem Client → RUM/Synthetik hinzufügen.
Alertas → eine Schwelle nach der anderen auf eine Zwei-Fenster-Burn-Rate umstellen.
Kein Zusammenhang mit Änderungen → Releases sind nicht annotiert, kein Auto-Rollback.

14) Mini-Checkliste zur Umsetzung

• Kritische Pfade und deren SLI/SLO werden beschrieben.
• Überwachungs- und Ausschlussfenster festgelegt.
• Zwei Fenster BR-Alerts konfiguriert (schnell und langsam).
• Dashboards von Releases und Operationen mit Versions-/Flag-Anmerkungen.
• Die error budget-Richtlinie wirkt sich auf Releases aus.
• Regelmäßige Budgetüberprüfungen und Post-Incident-RCAs.
• Dokumentation und Eigentümer der Indikatoren.

15) Berechnungsbeispiel (Besonderheiten)

API Verfügbarkeit SLO: 99. 9% für 28 Tage → Budget = 0. 1%.
In 7 Tagen hat sich 0 angesammelt. 06% der Fehler → 60% des Wochenbudgets ausgegeben.
Bei einem kurzen Fenster von 15 min werden 2% Fehler beobachtet. Gültig in diesem Fenster:'0. 1% × (15 Min ./40320 Min.) ≈ 0. 000037%`.
Burn Rate ≫ 1 (Dutzende von ×) → ein schneller Pager wird ausgelöst, der Kanarienvogel rollt auf 1% zurück, die Ficha-Flagge „degrade-payments-UX“ wird aktiviert, RCA wird gestartet.

16) Das Ergebnis

SLA/SLO-Überwachung ist nicht nur die Zahlen im Bericht, sondern ein Mechanismus, um das Risiko von Änderungen und die Qualität des Dienstes zu verwalten. Korrekte SLIs, realistische SLOs, Error-Budget-Management, Zwei-Fenster-Burn-Rate-Alerts und e2e-Observability machen Metriken zu Arbeitslösungen: Werte schneller freigeben und die Benutzererfahrung vorhersehbar halten.