PSP-X latency & loss

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Chaos Engineering ist eine wissenschaftliche Methode für die Produktion: Man formuliert eine Stabilitätshypothese, stört die Umgebung kontrolliert und beweist, dass der Nutzerwert (SLO/Business Metrics) erhalten bleibt. Für iGaming sind dies Zahlungsprüfungen (Payment Checks, PSPs), Initialisierung von Spielen, Pin-Warteschlangen, Multi-Regionen und Spitzenlasten - angesichts von Verzögerungen, Ausfällen und „Sturm“ -Retrays - bevor dies Live-Benutzern passiert.

1) Prinzipien des Chaos-Engineering

1. Vom Steady-State zur Hypothese. Definieren Sie die Norm: Verfügbarkeit, p95/p99, TTW, Zahlungsumwandlung.
2. Kleiner Blast Radius. Experiment zuerst in Staging/Kanar, 1-5% Verkehr/1-2 Pods/eine Region.
3. Beobachtbarkeit zuerst. Metriken/Logs/Traces + Anmerkungen zum Experiment.
4. Guardrails и abort. Enge SLO/Business-KPI-Schwellenwerte für den automatischen Stopp.
5. Wiederholbarkeit und Automatisierung. Experimente als Code (IaC/GitOps), Spieltagsplan.
6. Blameless Kultur. Das Experiment ist nicht die Suche nach Schuldigen, sondern die Suche nach Schwächen.

2) Steady-State und Erfolgsmetriken

TexSLI: p95/p99 API, error-rate, saturation (CPU/IO), queue lag (withdrawals/deposits), latency provider.
Business SLI: Conversion 'attempt→success', TTW p95, Erfolgsquote' game init', Anteil der PSP-Fehler nach Codes.

3) Klassen von Experimenten (was „brechen“)

Netzwerk: Latenz/Jitter/Paketverlust/Blackhole, DNS-Fehler, MTU-Anomalien.
Ресурсы: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
Prozesse und Standorte: kill/evict pods, node failure, zone/region failover.
Abhängigkeiten: PSP-Timeouts/Fehler, Unzugänglichkeit des Spieleanbieters, CDN/Cache-Degradation.
Warteschlangen/Streaming: Kafka lag Wachstum, Consumer Pause, Party/Leader Pause.
Daten/DB: Replikationsverzögerungen, Indexdegradation, Read-Only-Modus.
Releases/Ficheflags: Migrationsfehler, fehlerhafte Configs, Kill-Switch.
Front/RUM: LCP/INP Fall, Kundencrash in der Spitze.
Daten/ML: Alterung der Daten, Erhöhung der Latenz des Modells, Rückgang der Token/s, Verschlechterung der Qualität.

4) Prozess: Von der Hypothese zur Verbesserung

1. Formulieren Sie eine Hypothese (spezifische SLOs/Business KPIs + erwartetes Schutzverhalten).
2. Entwerfen Sie ein Experiment: Art des Versagens, Dauer, Blast Radius, Guardrails/Abbruch.
3. Vorbereitung der Beobachtbarkeit: Dashboards „release/experiment compare“, Anmerkungen.
4. Starten Sie unter IM/TL-Kontrolle, benachrichtigen Sie das On-Call/Business (falls betroffen).
5. Messergebnis: SLO, p95/p99, TTW, Conversion, Lags, Retrays.
6. Bilden Sie Aktionselemente: Limits, Timeouts, Retrays mit Jitter, Outlier-Ejection, PDB/HPA/KEDA, Pullback-Flow.
7. Automatisieren (im Reg-Paket von Game-Day/CI-Inspektionen der Infrastruktur enthalten).

5) Guardrails und Stoppkriterien

• SLO Fast-Burn aktiviert (z.B. 14 × Budget für 1 h),
• Die Umwandlung von Zahlungen ↓ um mehr als 0%. 3 Punkte,
• TTW p95> 3 min hintereinander 10-15 min,
• error-rate > 1. 5% und wächst in zwei Fenstern.
• Kommunikation: vorab genehmigter Kanal/Statusvorlage, „roter Button“ in ChatOps ('/experiment abort').

6) Beispiele für Experimente (Kubernetes/Cloud)

6. 1 Netzwerkverzögerungen zum PSP (Canary Deploy)

Ziel: Retrays/Timeouts/Routing prüfen.
Injektion: + 200 ms RTT und 3% Paketverlust nur für 'payments-api' → 'pspX'.

yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius

Erwartet: p95 '/deposit'<250 ms, error-rate <1%, conversion ≥ baseline − 0. 3 Punkte; bei Verschlechterung - automatische Umschaltung der PSP-Route.

6. 2 Ausfall von Knoten und PDB

Ziel: PDB/Anti-Affinität/HPA prüfen.
Injektion: Drain/Terminate eines Nodes mit 'games-api' Pods.

Erwartung: kein Verfügbarkeitsverlust, Peak p99 geht nicht über SLO hinaus, Autoscaler holt Replikate heraus, PDB verhindert „Doppelschlag“.

6. 3 Kafka lag и KEDA

Das Ziel: Nachhaltigkeit der Auszahlungen bei der Häufung von Nachrichten.
Injektion: Consumer für 5-10 Minuten einfrieren, dann einschalten.

Warten: KEDA skaliert die Worker, TTW p95 bleibt ≤ 3 Minuten nach der Resorption, keine Duplikate (Idempotenz, Schlüssel).

6. 4 DNS-Fehler des Spieleanbieters

Ziel: Fallback/Caching/Retrays.
Injektion: NXDOMAIN/Timeout für Domain 'providerA. example`.

Erwartung: schneller Folback auf 'providerB', in UI - degradierender Modus und Status-Banner; 'game init success' ≥ 99. 5%.

6. 5 Nur lesende DB

Ziel: Schreibverlustverhalten.
Injektion: Umschalten des Replikats in Read-Only für 10-15 Min.

Warten: Der Code behandelt Fehler korrekt, kritische Routen sind begrenzt, Warteschlangen halten Anträge zurück, es gibt keine Verluste/Doppelabbuchungen.

7) Automatisierung und GitOps

Experimente als Code: Skripte/Parameter/Guardrails in Git speichern, Revue passieren lassen via PR.
Spieltagsplan: Zeitplan, Besitzer, Metriken, Abortbedingungen, Checkliste der Kommunikation.
Anmerkungen in Grafana: Start/Ende des Experiments, config, finale SLO.

8) Beobachtbarkeit während Chaos

Beispiele: von p95/p99 - in spezifische' trace _ id'.
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
Traces: Externe Anrufe sind mit 'fault. injected = true', Retrays/Timeouts sind sichtbar.
Dashboards: „SLO-Karte“, Release/Experiment vergleichen, Zahlungen/Game init/Queues.

9) Die Besonderheiten von iGaming: was zuerst zu überprüfen

1. Zahlungen und TTW: PSP-Timeouts, Folback-Route, Idempotenz.
2. Initialisierung von Spielen: Unzugänglichkeit/Langsamkeit von Studios, CDN-Ausfälle.
3. Lead/Bonus-Warteschlangen: Lag-Wachstum, Neubearbeitung.
4. Multi-Region: Zonen-/RPO-Ausfall, Führungswechsel, DB-Replikation.
5. Peaks: Auto-Scale, Rate-Limit, Circuit-Breaker, Aufwärmen der Caches.
6. RG/Compliance: korrekte Protokollierung bei Ausfällen, keine PII in der Telemetrie.

10) Risikomanagement (Governance)

Kalender und Fenster: Experimente außerhalb der Spitzenturniere, Abstimmung mit dem Geschäft.
Роли: Experiment Lead, Observer (SRE), Business Rep; IM an der Hotline.
Datenrichtlinien: keine PII in Artefakten; WORM-Speicher für die Prüfung.
Rechtliche Grenzen: SLA-verletzende Szenarien ohne Harmonisierung ausschließen.

11) Game-Day: Skript-Vorlage

12) Typische Funde und Aktionen

Zu aggressive Retrays → ein Sturm von Anfragen → Timeouts/Jitter/Limits hinzufügen.
Keine outlier ejection → „giftige“ instance verdirbt p99 → schalten Sie die Keulung.
Fragile Migration → read-only bricht den Strom → expand→migrate→contract + ficheflagi.
Ein falsches HPA-Signal wird → spät gesendet → auf RPS/lag-Metriken umgestellt.
Der gemeinsame Cache für Versionen → Rollbacks verderben Daten → Versionsschlüssel.

13) Checkliste zur Reife der Chaos-Praxis

1. Steady-State und SLO sind beschrieben, die Dashboards stehen bereit.
2. Experimente als Code, Revue/Audit in Git.
3. Guardrails/abort sind automatisiert (Alertmanager/ChatOps).
4. Beobachtbarkeit: Beispiele, trace/log Korrelation, Anmerkungen.
5. Game-day Vierteljährlich, die Drehbucher decken plateschi/igry/otscheredi/multiregion ab.
6. Post-experimentelle Aktionselemente sind im Sprintplan enthalten; Überwachung der Umsetzung.
7. Schwellenwertrichtlinien für Retrays/Timeouts/Circuit-Breaker in Config-Repos.
8. Verbriefungen/PII-Richtlinien werden eingehalten, Artefakte ohne sensible Daten.
9. Auto-Remediationen nach SLO (Rollback/Scale/Reroute) werden im Chaos getestet.
10. Prozessmetriken:% ohne Abbruch bestanden, MTTR bei Übungen, Reduzierung von Klassenvorfällen.

14) Anti-Muster

„Wir brechen alles in der Produktion“ ohne SLO/guardrails/Beobachtbarkeit.
Experimente ohne Hypothesen und messbare Ziele.
Großer Blast Radius beim ersten Start.
Retrays ohne Timeouts/Jitter → kaskadierende Fehlertoleranz.
Chaos statt Prävention: Symptome behandeln, Wurzelursachen ignorieren.
Keine RCA/Action-Elemente nach dem Training.
Experimente in Spitzenzeiten ohne Absprache mit dem Geschäft.

Ergebnisse

Chaos-Engineering ist der methodische Beweis für Nachhaltigkeit: Man reproduziert reale Disruptionen im Vorfeld, misst die Auswirkungen auf SLOs und Geschäftsmetriken und stärkt die Architektur - von Retrays und Circuit-Breaker über multiregionale Orchestrierung bis hin zu Auto-Remediationen. Mit regelmäßigen Spieltagen und der Disziplin guardrails behält die iGaming-Plattform p95/p99, Conversion und TTW auch in den heißesten Perioden.