Betrieb und Management → Audit von Metriken und SLAs

Prüfung von Metriken und SLAs

1) Warum es notwendig ist

Wenn die Metriken falsch sind - Entscheidungen werden falsch sein, SLAs werden „auf dem Papier“ verletzt oder umgekehrt, um Probleme zu verbergen. Die Prüfung von Metriken und SLAs garantiert die Vergleichbarkeit, Glaubwürdigkeit und Rechtssicherheit der Versprechen gegenüber Nutzern und Partnern.

• Sorgen Sie für eine einzige „Quelle der Wahrheit“ (SSOT) und reproduzierbare Berechnungen.
• Reduzieren Sie Diskrepanzen zwischen Dashboards/Berichten/Rechnungen.
• Machen Sie SLAs durchführbar und überprüfbar (evidence-based).
• Degradationen bei Messungen genauso früh zu erkennen wie bei Dienstleistungen.

2) Grundbegriffe und Haftungsgrenzen

Metrisch: Messgröße (RPS, p95, CR, GGR, Success Rate).
KPI/OKR: Ziele, an die die Metriken gebunden sind.
SLO: Zieldienstqualität (z. B. "p99 ≤ 400 ms 99. 9% der Zeit").
SLA: externes Versprechen; rechtlich relevant, basiert auf SLO.
OLA: interne Vereinbarung zwischen Teams/Anbietern, unterstützt SLA.
SSOT: System/Speicher, dessen Daten als Referenz für Berichte gelten.

3) Taxonomie der Metriken (Schichten)

1. Infrastruktur: CPU/Memory/IO/Net, Pods/Nodes, HPA/VPA.
2. Plattform: Warteschlangen/Streams (lag, throughput), DB/Caches (connects, hit), API (p95/p99, 5xx).
3. Geschäftsströme: Einzahlungen/Auszahlungen, Wetten, Spielstart, Autorisierung, KYC.
4. Produkt/Marketing: Conversions, ARPPU/LTV, Kampagnen.
5. Prozessqualität: MTTA/MTTR, Change Failure Rate, Checklistenabdeckung.

Regel: Jede Metrik muss eine Ebene, einen Besitzer und eine Formel haben.

4) Datenquellen und „Wahrheit“

TV-Metrie online: Prometheus/OTel, Protokolle (ELK/ClickHouse), Traces.
Veranstaltungen und Buchhaltung: Kafka/Outbox, DWH/Data Marts (BigQuery/ClickHouse).
Manuelle Artefakte: Postmortems, Tickets, Ereignisregister.
Externe Register: Berichte der Anbieter (PSP/KYC/Studios), Abrechnung.

Konfliktlösung: Bei Unstimmigkeiten „online vs DWH“ gelten Prioritätsregelungen (z.B. für SLAs - Aggregate aus DWH mit Quellentraceability).

5) Prüfprozess der Kennzahlen (Regelkreis)

1. Inventar: Metrikverzeichnis/SLO/SLA (Name, Besitzer, Layer, Formel, Quelle, Berechnungshäufigkeit).
2. Formelverifizierung: Abgleich von SQL/Prom-Abfragen mit der Definition (Unit-Berechnungstests).
3. Sampling und Re-Reviews: Samples von Ereignis-/Logzeilen und manueller Abgleich.
4. Konturvergleich: Vergleich von Online-Dashboards und DWH-Berichten.
5. Kontrolle von Änderungen: Revue-Formeln bei Schaltungs-/Logik-Releases.
6. SLA-Audit: Überprüfung der Korrektheit von Baugruppen und Ausnahmen (geplante Wartung, höhere Gewalt).
7. Bericht und Verbesserungen: Liste der festgestellten Diskrepanzen und Terminfixes.

6) Definitionen und Formeln (Proben)

• `success = requests - (5xx + timeouts + circuit_open)`
• `success_rate = success / requests`

• Eine einzige Fensterdefinition (Rolling 5m/1h) und Aggregation (HDR/TDigest) werden in SSOT erfasst.

• „SLO _ availability _ month = (Betriebszeit - zulässige Ausnahmen )/Gesamtzeit“

• `SLA_month = 99. 90% des UTC-Fensters, ausgenommen geplante Fenster (T-48 Benachrichtigung), nachweisbare Unfälle bei Transitbetreibern (Dokumente). "

7) Datenqualität: Kontrollen und Warnungen

• Полнота (completeness): `received_events / expected_events ≥ 0. 99`.
• Aktualität (Timeliness): Download-Lag ≤ N Minuten.
• Einzigartigkeit (uniqueness): keine Tastenüberschneidungen (idempotency-key).
• Konsistenz (consistency): Beträge/Währung/Zeichen.
• Linearität (Monotonicity): Zähler werden nicht „zurückgerollt“.

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) SLA/OLA-Audit: Methodik

1. Sammeln Sie einen Kalender von Ausnahmen: geplante Fenster, vereinbarte Degradierung, Handlungen von Anbietern.
2. Berechnung des Aptymes: auf einer einzigen Zeitzone, basierend auf SSOT.
3. Abgleich mit den Vorfällen: Timeline, Tickets, Postmortems.
4. Attribution: eigene Ausfälle, Anbieter, Transit, DDoS, Routinearbeiten.
5. SLA Perimeter: Benutzererfahrung (E2E) vs eine bestimmte API.
6. Berichterstattung: Monats-/Quartalsbericht: Fakt, Abweichungen, Entschädigungen (falls zutreffend), Korrekturmaßnahmen.

9) Überprüfung der Reproduzierbarkeit der Berechnungen

Formelversionierung: Git-Repository mit SQL/PromQL/Dock-Spezifikationen.
Unit-Tests von Metriken: auf synthetic Daten (Edge-Fälle: Auslassungen, Takes, Datumsgrenzen).
Data lineage: vom Dashboard zurück zu den ursprünglichen Tabellen und Ereignissen.
Snapshots: Frieren Sie Daten in einem Cut-Off ein, damit die Re-Berechnungen vergleichbar sind.

10) Kontrollproben (Sampling)

Täglich: 10-20 Ereignisse nach Schlüsselströmen (Einzahlung/Wette/CUS) - manueller Trace-Abgleich ↔ DWH.
Wöchentlich: 1% Sample zum Vergleich „online vs DWH“ nach Aggregaten.
Monatlich: Eine Reihe von Vorfällen mit SLA-Effekt - detaillierte Rekonstruktion.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Prüfung von Dashboards und Warnungen

Einheitliches Metrikwörterbuch: Glossar direkt auf dem Dashboard.
Anmerkungen zu Releases/Events: um die Ursache der Abweichungen zu sehen.
Vergleich „vor/nach Release“: Automatische Regressionsfelder.
Duplikate/Diskrepanzen: „zwei verschiedene p99“ identifizieren - Formeln/Fenster bearbeiten.
Verfügbarkeit der Panels: Rechte, Reserve, Link-/Versionskontrolle.

12) Änderungsmanagement bei Metriken

RFC-Prozess: Formel/Fenster/Quelle ändern - über RFC mit Bewertung der Auswirkungen auf SLA/Berichte.
Migration „expand → migrate → contract“: Wir führen vorübergehend beide Versionen, vergleichen und schalten dann die alte aus.
Kommunikation: Informieren Sie das Produkt/Unternehmen im Voraus über Wertverschiebungen „nach der neuen Methode“.

13) Besonderheiten iGaming/Fintech

Nachfragespitzen: Metriken müssen explosiven Belastungen standhalten (Aggregationen „kleben“ nicht).
Anbieter: SLA ist abhängig von OLA-Anbietern → speichert ihre Berichte, Incident Status und Quoten.
Kosten: 'cost _ per _ 1k _ calls' und 'cost of success' sind Pflichtfelder.
Anti-Fraud/Risiko: Empfindlichkeit gegenüber Verzögerungen und „falsch positiven“ Metriken.

14) Audit Dashboards (Mindestsatz)

Metrics Health: completeness/timeliness/duplicates, ingest-lag, ошибки ETL.
SLO/SLA Evidence: berechnete SLO, tatsächliche SLA, Ausnahmen, Hinweise auf Vorfälle/Handlungen.
Online vs DWH Compare: p95/p99/Success Rate, Abweichungen und Trends.
Vendor SLA: Uptime/Quoten/Timeouts/Kosten im Querschnitt der Anbieter.
Release Impact: Regressionen von Metriken nach Berechnungen/Einschlüssen.

15) Audit Checkliste (operativ)

• Der Metrikkatalog/SLO/SLA mit Eigentümern und Formeln ist aktuell.
• Das SSOT ist für jeden Bericht/Panel definiert.
• Unit-Tests der Formeln sind grün, die Pipelines der Berechnungen sind dokumentiert.
• Alerts zur Datenqualität sind aktiv (completeness/timeliness/duplicates).
• „Online vs DWH“ Abweichungen ≤ zulässigen Schwellenwert (z. B. ≤2%).
• Die vereinbarten SLA-Ausnahmen sind dokumentiert und dem Bericht beigefügt.
• Es wurden Kontrollstichproben durchgeführt und Rechtsakte erlassen.
• Alle Formeländerungen haben RFC und Migration bestanden.

16) Beispiele (Fragmente)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anti-Muster

Zwei verschiedene Formeln der „gleichen“ Metrik in verschiedenen Panels.
Änderung der Metrik ohne Migration und Benachrichtigung - „Sprünge“ in OKR/SLA.
Berichte in lokalem Excel als „wahr“ (nicht reproduzierbar).
Mischen Sie Zeitzonen und Kalender in SLA-Berechnungen.
SLA-Ausnahmen werden nicht dokumentiert.
Keine Alert auf die Qualität der Messungen.

18) Messreife KPI

Drift Rate Online↔DWH (Ziel ≤2%)

Metrics Health Uptime (Zeit ohne Ingest/ETL-Degradation).
Time-to-Fix Formula (Zeit, um einen Fehler in der Formel zu beheben).
SLA Dispute Rate (Häufigkeit strittiger Fälle mit Partnern).
Coverage SLO/SLA (Anteil kritischer Pfade mit formal beschriebenen SLO/SLA).

19) Rollen und Verantwortung

Metrik-/Servicebesitzer: Formel, Quelle, Dashboard, Warnungen.
Observability/SRE: SSOT/Plattform, Formeltests, Datenqualitätsalerts.
Daten/BI: DWH, Reproduzierbarkeit der Berichte, Lineage.
Rechtsanwälte/Partner-Manager: SLA-Vereinbarungen und Ausnahmen.
Incident Manager: Zuordnung und Bündelung von SLA-Vorfällen.

20) Schnellstart (30 Tage)

Woche 1: Inventar der Metriken/SLOs/SLAs und Eigentümer; Zuweisen von SSOT.
Woche 2: Aktivieren Sie Datenqualitätsalerts und das Panel „Online vs DWH“.
Woche 3: Kontrollproben durchführen, p95/p99-Fenster ausrichten.
Woche 4: Formalisieren Sie den RFC-Prozess für Formeln, erstellen Sie einen monatlichen SLA-Bericht mit Anhängen.

21) FAQ

F: Was ist SSOT für SLA?
A: Speicher mit reproduzierbaren Berechnungen (DWH) und voller Lineage; Online-Panels - zur operativen Kontrolle, nicht für Rechtsakte.

F: Wie geht man mit „zwei p99“ um?
A: Fenster/Aggregationsmethode im Metrikkatalog fixieren, Panels migrieren, Alert zur Drift hinzufügen.

Q: Wie kann man geplante Arbeiten berücksichtigen?
A: Halten Sie einen Ausschlusskalender und subtrahieren Sie sie automatisch von SLAs gemäß den Vertragsregeln; Aufbewahrung von Artefakten.