Alerting und Reaktion auf Störungen
(Abschnitt: Technologie und Infrastruktur)
Kurze Zusammenfassung
Starkes Alerting ist ein Signal für eine Verletzung des Benutzerwerts und nicht nur eine „rote Metrik“. Für iGaming sind SLO-Gates (Latenz, Verfügbarkeit, Zahlungsumwandlung, Time-to-Wallet), Multi-Burn-Regeln, klare On-Call-Rollen, Eskalationen, ChatOps und Runbooks wichtig. Ziel ist es, die Abweichung schnell zu sehen, diejenigen zu informieren, die korrigieren können, und das Wissen zu erfassen, um beim nächsten Mal noch schneller und billiger zu reagieren.
1) Grundlagen: Von Metriken zu Aktionen
SLI → SLO → Alert: Messbare Qualität → Zielniveau → Zustand „Budget brennt“.
Severity (SEV): SEV1 - kritisch (Umsatz/GGR gefährdet), SEV2 - ernst, SEV3 - moderat, SEV4 - Moll.
Impact/Urgency: Wer ist betroffen (alle/Region/Tenant/Kanal) und wie dringend (TTW↑, p99↑, error- rate↑).
Actionability: Für jeden Alarm gibt es eine bestimmte Aktion (Runbook + Besitzer).
2) Taxonomie der Signale
ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
BusinessSLO: Zahlungsumwandlung (attempt→success), Time-to-Wallet (TTW), Wetterfolg, Startfähigkeit von Spielen.
Zahlungswege: PSP-spezifische Metriken (Timeout/Decline Spikes).
Front/Mobile: RUM-Metriken (LCP/INP), Crash-Rate, Syntheseszenarien (Login/Einzahlung/Wette/Ausgabe).
3) Alerting-Politik: SLO und Burn-Rate
Beispiele für SLI/SLO
Verfügbarkeit der „payments-api“ ≥ 99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d
Die Konversion von 'payments_attempt→success' ≥ baseline − 0. 3% / 24h
TTW p95 ≤ 3 min/24h
Multi-window / Multi-burn (идея PromQL)
Fast Burn: SLO-Verletzung ist 5-10 × schneller als normal (Alert-Page in 5-15 Minuten).
Langsames Brennen: langsames Ausbrennen des Budgets (Ticket + Analyse in 1-3 Stunden).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4) Rauschunterdrückung und Signalqualität
Die richtige Quelle der Wahrheit: Alertieren Sie nach Aggregaten (Aufzeichnungsregeln) und nicht nach schweren „rohen“ Ausdrücken.
Deduplizierung: Alertmanager gruppiert nach „service/region/severity“.
Hierarchie: zuerst alert auf Business/SLI, unten - Techmetrics als Diagnose.
Unterdrückung: während der geplanten Wartung/Veröffentlichung (Anmerkungen), mit Upstream-Vorfällen.
Kardinalität: Verwenden Sie' user _ id/session _ id 'nicht in alert Labels.
Testalerts: regelmäßige „Training“ -Auslöser (Überprüfung von Kanälen, Rollen, Runabook-Links).
5) Alertmanager: Routing und Eskalationen
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]SEV = page → PagerDuty/SMS der Rest ist Slack/Ticket. Die Hemmung unterdrückt den „Hype“ der unteren Ebenen mit einem aktiven SEV höher.
6) Grafana Alerting (als zusätzliche Schicht)
Zentrale Warnregeln auf Dashboards (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silences: geplante Arbeiten, Migrationen, Releases.
Snapshots mit Auto-Screenshot-Panel in Ticket.
7) On-Call und „Live“ -Prozesse
Rotation: 1. Linie (SRE/Plattform), 2. Linie (Service Owner), 3. Linie (DB/Payments/Sec).
SLA-Reaktion: Anerkennung ≤ 5 Minuten (SEV1), Diagnose ≤ 15 Minuten, Kommunikation alle 15-30 Minuten.
Kanäle im Dienst:'# incident-warroom','# status-updates'(nur Fakten).
Runbooks: Link in jeder Alert + schnelle ChatOps-Befehle ('/rollback', '/freeze', '/scale').
Lernalarme: monatlich (Überprüfung von Personen, Kanälen, Runabook-Relevanz).
8) Vorfälle: Lebenszyklus
1. Gegenstand (alert/report/synthetics) → Acknowledge on-call.
2. Triage: SEV/Betroffene/Hypothese ermitteln, Kriegsraum öffnen.
3. Stabilisierung: Roulbooks/Roll-Back/Scale-Up/Ficheflags.
4. Mitteilungen: Statusvorlage (siehe unten), ETA/nächste Schritte.
5. Close: Bestätigung der SLO-Wiederherstellung.
6. Post-Incident Review (RCA): in 24-72 Stunden, keine Gebühren, Aktionsgegenstände.
- Was ist kaputt/wer ist betroffen (Region/Tenant/Kanal)
- Wann hat begonnen/SEV
- Vorläufige Maßnahmen (Mitigation)
- Nächstes Status-Update nach N Minuten
- Kontakt (Incident Manager)
9) Spezifität von iGaming: „schmerzhafte“ Zonen und Warnungen
Zahlungen/TTW: PSP-Timeout-Anteil, Anstieg der Codefehler, TTW p95> 3m.
Turnierspitzen: p99 API/Startzeit der Spiele/queue lag; Verbreitung von Limits/Auto-Scale.
Mittelrückschlüsse: SLA Backoffice/manuelle Prüfungen, Länderlimits.
Spieleanbieter: Verfügbarkeit nach Studios, Session-Initialisierungszeit, sinkende Starts.
RG/Compliance: Ausbrüche von langen Sitzungen/“ Dogon“, Überschreitung von Schwellenwerten - keine Seite, sondern ein Ticket + Benachrichtigung an das RG-Team.
10) Regelbeispiele (optional)
Hohe Latenz p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"Warteschlange „brennt“
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"Zahlungsumwandlung gesunken
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11) ChatOps und Automatisierung
Alert Auto-Posting mit Action-Buttons: Stop Canary, Rollback, Scale + N.
Befehlsabkürzungen: „/incident start “, „/status update“, „/call
Bots ziehen den Kontext hoch: letzte Deploys, Abhängigkeitsgraph, Trace-Beispiele (exemplarisch), zugehörige Tickets.
12) Post-Incident-Arbeit (RCA)
Fakten: Zeitlinie, was Sie gesehen/versucht haben, was funktioniert hat.
Root cause: technische und organisatorische Gründe.
Detections & Defenses: welche Signale geholfen/versagt haben.
Aktionselemente: spezifische Aufgaben (SLOs/Alerts/Codes/Limits/Tests/Runabook).
Due dates & owners: Termine und Verantwortliche; Follow-up-Sitzung in 2-4 Wochen.
13) Checkliste Umsetzung
1. Definieren Sie SLI/SLO für Key Streams (API/Payments/Games/TTW).
2. Konfigurieren Sie die Recording-Regeln und Multi-Burn-Alerts + Alertmanager-Routing.
3. Geben Sie On-Call mit Rotation, SLO Reaktionen und Eskalationen.
4. Binden Sie Alerts an Runbooks und ChatOps-Teams.
5. Konfigurieren Sie Unterdrückungen/stille Fenster, Anmerkungen zu Releases/Arbeiten.
6. Machen Sie Trainingsalarme und Game-Day-Szenarien (PSP-Fall, p99-Wachstum, Queue-Lag-Wachstum).
7. Alert Quality: MTTA/MTTR,% noisy/false, coverage by SLO.
8. Regelmäßige RCAs und Überprüfung von Schwellenwerten/Prozessen.
9. Geben Sie den Status der Kommunikation mit dem Unternehmen/Sapport (Vorlagen) ein.
10. Dokumentieren Sie alles als Code: Regeln, Routen, Runabook-Links.
14) Anti-Muster
Alerting für „jede Metrik“ → alert-fetig, ignorant.
Es gibt kein SLO → es ist nicht klar, was die „Norm“ ist und was „brennt“.
Keine Unterdrückung/Hemmung → Lawinendeduplizierung.
Page in der Nacht für Minor Events (SEV ist nicht vergleichbar mit Impact).
Alertas ohne Runbook/Besitzer.
„Manuelle“ Aktionen ohne ChatOps/Audit.
Keine RCA/Action items → Wiederholung von Vorfällen.
Ergebnisse
Alerting und Reaktion ist ein Prozess, kein Regelwerk. Verknüpfen Sie SLOs mit Multi-Burn-Alerts, bauen Sie eine klare On-Call-Eskalation auf, fügen Sie ChatOps und Live-Runabook-i hinzu, führen Sie regelmäßig RCA- und Trainingseinheiten durch. Dann werden die Vorfälle seltener, kürzer und billiger, und die Veröffentlichungen sind auch in den heißen Stunden von iGaming vorhersehbarer.