Infrastruktur-KPIs und Aptime

Warum es notwendig ist

Infrastruktur-KPIs verwandeln „Gefühle“ über Stabilität in messbare Ziele, steuern das Risiko und den Fokus der Arbeit. Die richtigen Metriken verknüpfen technische SLIs mit Geschäftsergebnissen (Conversion, Time-to-Wallet, LTV) und ermöglichen die Planung von Entwicklung, Auslastung und Innovationsanteil vs. Zuverlässigkeit.

Grundbegriffe: SLI, SLO, SLA und Fehlerbudget

SLI (Service Level Indicator) ist ein messbarer Qualitätsindikator: Anteil erfolgreicher Abfragen, p95 Latenz, Aptame pro Intervall.
SLO (Service Level Objective) ist ein SLI-Ziel (z. B. "Erfolg ≥ 99. 9% in 30 Tagen").
SLA (Agreement) - externes Versprechen mit Strafen/Krediten. Immer abgeleitet von SLO, aber nicht gleich ihm.
Fehlerbudget = „1 − SLO“. Dies ist der maximal zulässige Anteil des „Fehlschlags“ pro Messfenster. Wird verwendet, um Entscheidungen über Risikofreigaben und Experimente zu treffen.

• SLO Verfügbarkeit 99. 95% in 30 Tagen → Fehlerbudget 0. 05% ≈ 21. 6 Minuten „Versagen“ in einem Kalendermonat.

Vier „goldene“ Signale und zusätzliche

1. Latenz (p50/p90/p95/p99, tail wichtiger als Durchschnitt).
2. Fehler (5xx/timeout/Geschäftsfehler).
3. Datenverkehr/Bandbreite (RPS/QPS, MBps).
4. Sättigung (CPU/RAM/IO/FD/Anschlüsse/GC/Quoten).
Optional: Kaltstart, Warteschlangen/Becklog, Deploy Time, SLO-Compliance.

SLI-Modell für verschiedene Servicetypen

HTTP/API

Verfügbarkeit: '(erfolgreiche 2xx/3xx − logische Fehler )/( alle Anfragen) '

Latenz: „p95“ für erfolgreiche Abfragen; Ziel für „heiße“ Routen.
Qualität: Anteil der Anfragen mit 'audience/scope' korrekt (keine authZ-Fehler).

Warteschlangen/Asynchron

Verarbeitungszeit der Nachricht: p95 Ende-zu-Ende ≤ N Sek.
Backlog: Median <X, Schwanz p99 <Y.
Versandfehler: ≤ Z ppm.

Datenbank/Cache

Latenz der Operationen: p95 get/put/commit.
Sättigung: Verbindungspool Verwendung, Hit-Verhältnis des Cache.
Fehler: timeouts, deadlocks, eviction storms.

CDN/Statik

Hit Ratio: ≥ des Zielniveaus Verschlechterung → Erhöhung der Belastung der Herkunft.
POP-Verfügbarkeit: Anycast-Layout, Ausfälle werden von Nachbarn kompensiert.

Zahlungen (Business SLI)

Time-to-Wallet p95, Einzahlungs-/Auszahlungserfolg%, Ausfallrate PSP.

Berechnung von Verfügbarkeit und „Aptime“

Verfügbarkeit des Dienstes = „erfolgreiche Anfragen/alle Anfragen“ (vorzugsweise, nicht „Minuten des Starts“).
Alternative für Infrastrukturknoten: 'Zeit im Zustand' Grün '/Fensterzeit'.
Kalenderfenster: 28-31 Tage, Schiebefenster: letzte 30/90 Tage.
Arbeitszeiten/kritische Fenster: Für Backoffice kann ein Aptame im Zeitplan betrachtet werden (z. B. 08: 00-22: 00 Ortszeit).

• „Availability (A) ≈ Av (B) × Av (C) × Av (A'B, C)“ - es ist wichtig, SLOs an den Grenzen zu platzieren.

Beispiel für ein SLO-Set (Beispiel)

Gateway-API: Verfügbarkeit ≥ 99. 95 %/30д; p95 Latency ≤ 120 ms Fehler ≤ 0. 2%.
Checkout/Zahlungen: Erfolg der Einzahlung ≥ 98. 5 %/30д; Time-to-Wallet p95 ≤ 90 с; PSP-timeouts ≤ 0. 3%.
Datenbank: p95 lesen ≤ 10 ms; p95 write ≤ 25 ms replica lag p95 ≤ 150 мс.
Cache: Trefferverhältnis ≥ 85%; eviction storms = 0/30д.
Auszahlungen: p95 Verarbeitung ≤ 5 min; False-Fols-Positive ≤ 0 3%.

Fehlerbudget und Änderungsmanagement

Wenn das Fehlerbudget zu 50% + vor der Mitte des Fensters erschöpft ist, wird ein „Einfrieren“ von Fich/Releases eingeführt, wobei der Schwerpunkt auf der Stabilisierung liegt.
Wenn das Budget langsam ausgegeben wird, können Sie die Experimente/Kanarienvögel beschleunigen.
Verknüpfen Sie den Budgetverbrauch mit bestimmten Releases/Incidents über 'release _ id'.

Alerting: Wie man nicht umsonst „nachts anruft“

Alertas nur für SLO-Abbau und Vitalzeichen, nicht für jede Metrik.
Multi-Fenster, Multi-Burn Rate: kurzes Fenster (5-15 Min.) + langes Fenster (1-6 h).
Beispiel: „Burn rate 14 × in 5 Minuten und 6 × in 1 Stunde“ → eine On-Call-Seite.
Stille Uhr für Nicht-P1-Signale; Verantwortlichkeit (ownership).

Dashboards und Visualisierungspraktiken

SLO-Panel: Service Compliance, Restbudget, Abhängigkeitskarten.
Latency-Panel: p50/p90/p95/p99, Zerlegung nach Routen/Tenanten/Ländern/ASN.
Fehler-Panel: Codes/Ursachen, Korrelation mit Releases/Fichflags.
Kapazität-Panel: CPU/RAM/IO/Netzwerk/FD/Konnektivität, Trends und Prognosen.
Business Panel: Conversion, Time-to-Wallet, Einzahlungen/Auszahlungen, Auswirkungen von Schutzmaßnahmen (WAF/Anti-Bots).

Vorfälle, MTTRs und Post-Mortems

• MTTD (Detection), MTTA (Accept), MTTR/MTTC (Recovery/Containment),% der Vorfälle ohne RCA auf Zeit.
• Playbooks: Wer eskaliert, wie man Fichflags/Blöcke einschaltet, wie man eine Veröffentlichung zurückrollt, Kommunikation mit dem Geschäft.
• Postmortem (blameless): Fakten, Zeitlinie, Ursachen (te/Prozesse), Aktionen: sofort/langfristig, Regressionstests, Einfluss auf SLO.

Leistung, Sättigung und Degradation

Headroom: Soll-Ressourcenbestand (z.B. CPU <70% p95, RAM <75% p95).
Heiße Pfade: Profilierung kritischer Routen; 'p99' ist wichtiger als der Durchschnitt.
Degradationsmodi: Cache-only, read-only, Drop-Grinding unwichtiger Anfragen, „Wettlimit „/Quoten.

Formeln und Beispielberechnungen

1) Verfügbarkeit auf Anfrage

availability = (total_requests - error_requests) / total_requests

wobei 'error _ requests' = 5xx + timeouts + business error (konfigurierbar) ist.

2) Fehlerbudget (Minuten)

error_budget_minutes = window_minutes (1 - SLO)

Beispiel: 30 Tage (43.200 min), SLO 99. 95% → 21. 6 Minuten

3) Burn rate

burn_rate = observed_error_ratio / (1 - SLO)

Wenn SLO 99. 9% (Haushalt 0. 1%) und 1% Fehler → burn_rate = 10 ×.

4) Zusammengesetzte Verfügbarkeit

A_total ≈ A_gw × A_auth × A_db × A_psp

Kleine Stürze treffen multiplikativ das gesamte A.

Mess- und Ausschlussrichtlinien

Ungeplante Fenster (Vorfälle) - werden berücksichtigt.
Geplante Wartungsfenster - werden nur berücksichtigt, wenn der SLA so vorgeschrieben ist; für SLOs oft nicht subtrahiert (oder separat als' planned _ downtime' gekennzeichnet).
Synthetics vs echte Benutzer: Es ist nützlich, beide Kanäle zu haben (RUM + synthetische Überprüfungen).

Beispiele für Artefakte

KQL/PromQL (Ideen)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (Business SLI für Zahlungen)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Verwalten von Abhängigkeiten und Kaskaden

SLO-Verträge zwischen Teams: gateway↔auth↔wallet↔PSP.
Degradationsrichtlinien: Wenn die Abhängigkeit sinkt, wechselt der Dienst in den „vereinfachten Modus“.
Feature Flags: Deaktivierung nicht kritischer Funktionen, „graue Freigabe“, um Latenzschwänze zu reduzieren.

Kapazitätsplanung und Prognosen

Schomes. RPS/MBps Prognose für Trends und Events (Turniere, Matches, Aktionen).
Load-Tests auf „goldenen Pfaden“, separate Tests für PSP/Auszahlungen.
Bestand in der Spitze: Zielfaktor 1. 3×–2. 0 × der zu erwartenden Belastung.

Checkliste für die SLO/KPI-Implementierung

1. Identifizieren Sie kritische Benutzerpfade und vereinbaren Sie SLI „aus Kundensicht“.
2. Wählen Sie SLO Ziele und Fenster (30/90 Tage); Berechnen Sie das Budget für Fehler.
3. Integrieren Sie die Sammlung von Metriken in Gateways/Dienste, normalisieren Sie Codes/Ursachen.
4. Konfigurieren Sie Burn-Rate-Alerts (kurzes + langes Fenster), Routing und On-Call.
5. SLO-Compliance visualisieren, mit Releases/Fichflags verknüpfen.
6. Starten Sie eine Budget-gegen-Change-Politik und einen Einfrierprozess.
7. Retrospektiven und RCA für jede Überschreitung, Regressionstests.
8. Revidieren Sie die SLOs vierteljährlich nach tatsächlicher Budgetverwendung und Geschäftszielen.

Typische Fehler

Messen Sie „Ping-Aptime“, indem Sie Anwendungsfehler ignorieren.
SLOs werden „in Reserve“ ausgestellt (99. 999%), sind aber unerreichbar und lösen nichts.
Alerts durch Low-Level-Metriken anstelle von benutzerdefinierten Symptomen.
Es gibt keine Abhängigkeitskarte → es ist nicht klar, wo es brennt.
Es gibt keine Verbindung zwischen SLO und Veröffentlichungen → es ist nicht klar, wer das Budget „gegessen“ hat.
Ignoriere die p99-Schwänze → gute durchschnittliche, aber schlechte UX-VIP-Benutzer.

Spezifität für iGaming/Fintech

Planmäßige Spitzen: Matches/Events/Promotions - Erhöhen Sie die Kapazität im Voraus, wärmen Sie den Cache/CDN auf und fügen Sie spezielle Limitprofile hinzu.
Business SLI: Time-to-Wallet, Ein-/Auszahlungserfolg, „Auszahlungsrate“ p95; in der Wurzel der Dashboards.
PSPs/Partner: separate SLOs/Dashboards nach Anbieter, automatische Routenumschaltung.
Anti-Bot/Anti-Fraud: Das Fehlerbudget darf nicht wegfressen - trennen Sie „berechtigte Blöcke“ von „technischen Fehlern“.
Regulatory: Protokollspeicherung, Reproduzierbarkeit von SLO/SLA-Berechnungen, Incident Reports.

FAQ

Müssen geplante Arbeiten vom SLO abgezogen werden?
Normalerweise nicht: SLO spiegelt die Erfahrung des Benutzers wider. Für SLAs können Ausnahmen festgelegt werden.

Warum p95 und nicht Durchschnitt?
Der Durchschnitt maskiert die Schwänze; UX bestimmen die Schwänze (p95/p99).

Ist ein SLO für das gesamte Produkt möglich?
Sie benötigen einen SLO-Baum: aggregiert nach Produkt und untergeordnet nach kritischen Pfaden/Komponenten.

Summe

Ein starkes Infrastruktur-KPI-System sind benutzerdefinierte SLIs, realistische SLOs, ein Fehlerbudget als Hebel für das Änderungsmanagement, intelligente Alerting und Incident-Disziplin und RCAs. Verknüpfen Sie technische Metriken mit Geschäftsmetriken, automatisieren Sie die Erfassung und Visualisierung - und die Infrastruktur wird vorhersehbar, und das Unternehmen wird auch in Spitzenszenarien kontrolliert.