Alerting et réponse aux pannes
(Section : Technologie et infrastructure)
Résumé succinct
L'alerte forte est un signal de violation de la valeur de l'utilisateur, pas seulement une « métrique rouge ». Pour iGaming, les gates SLO (latence, disponibilité, conversion de paiement, Time-to-Wallet), les règles multi-burn, les rôles clairs sur appel, l'escalade, ChatOps et runbooks sont importants. L'objectif est de voir rapidement l'écart, d'informer ceux qui seront en mesure de corriger, et d'enregistrer les connaissances afin de réagir encore plus rapidement et moins cher la prochaine fois.
1) Bases : des métriques aux actions
SLI → SLO → Alert : qualité mesurable → niveau cible → conditions « budget en feu ».
Severity (SEV) : SEV1 est critique (chiffre d'affaires/GGR en danger), SEV2 grave, SEV3 modéré, SEV4 mineur.
Impact/Urgence : qui souffre (tout/région/tenant/canal) et quelle est l'urgence (TTW↑, p99↑, error- rate↑).
Activability : pour chaque alarme, une action spécifique (runbook + propriétaire).
2) Taxonomie des signaux
ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
BusinessSLO : conversion des paiements (attempt→success), Time-to-Wallet (TTW), succès des paris, lancement des jeux.
Itinéraires de paiement : métriques spécifiques à la PSP (timeout/decline spikes).
Front/mobile : métriques RUM (LCP/INP), taux de crash, script synthétique (login/dépôt/pari/retrait).
3) Politique d'alerte : SLO et burn-rate
Exemples de SLI/SLO
Disponibilité de 'payments-api' ≥ 99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d
Conversion 'payments_attempt→success' ≥ baseline − 0. 3% / 24h
TTW p95 ≤ 3 min/24h
Multi-window / Multi-burn (идея PromQL)
Fast burn : violation du SLO 5-10 × plus rapide que la normale (alert page en 5-15 min).
Slow burn : lent burn du budget (ticket + analyse en 1-3 h).
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) Réduction du bruit et qualité des signaux
La bonne source de vérité est d'alerter sur les agrégats (règles d'enregistrement) plutôt que sur les expressions « brutes » lourdes.
Déduplication : Alertmanager regroupe par 'service/region/severity'.
Hiérarchie : d'abord alert sur Business/SLI, ci-dessous - la technique comme diagnostic.
Suppression : lors de la planification-maintenance/release (annotation), lors d'incidents upstream.
Cardinalité : n'utilisez pas 'user _ id/session _ id' dans les étiquettes alertes.
Alerts de test : déclencheurs « d'apprentissage » réguliers (checkpoints, rôles, liens runabook).
5) Alertmanager : routage et escalade
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" ]Idée : SEV = page → PagerDuty/SMS ; le reste est Slack/ticket. L'inhibition supprime le « bruit » des niveaux inférieurs avec un SEV actif plus élevé.
6) Alerting Grafana (comme couche dopante)
Alert rules centralisées sur les dashboards (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silences : travaux planifiés, migrations, sorties.
Snapshots avec une capture d'écran automatique du panneau en ticket.
7) Processus d'appel et « en direct »
Rotation : ligne 1 (SRE/plateforme), ligne 2 (propriétaire du service), ligne 3 (DB/Paiements/Sec).
Réactions SLA : reconnaissance ≤ 5 min (SEV1), diagnostic ≤ 15 min, communications toutes les 15 à 30 min.
Chaînes en service : '# incident-warroom', '# status-updates' (faits uniquement).
Runbooks : lien dans chaque alerte + commandes rapides ChatOps ('/rollback ', '/freeze', '/scale ').
Anxiété d'apprentissage : mensuelle (vérification des personnes, des canaux, de la pertinence runabook).
8) Incidents : Cycle de vie
1. Detect (alert/report/synthétique) → Acknowledge on-call.
2. Triage : définir le SEV/affecté/hypothèse, ouvrir la salle de guerre.
3. Stabilisation : rouleau/retour/mise à l'échelle/ficheflagi.
4. Communications : modèle de statut (voir ci-dessous), ETA/prochaines étapes.
5. Fermeture : confirmation de la récupération de SLO.
6. Post-Incident Review (RCA) : 24-72 h plus tard, sans charges, éléments d'action.
- Ce qui est cassé/affecté (région/tenant/canal)
- Quand a commencé/SEV
- Mesures provisoires (mitigation)
- Prochaine mise à jour du statut en N minutes
- Contact (Gestionnaire des incidents)
9) Spécificité d'iGaming : Zones « douloureuses » et alertes
Paiements/TTW : proportion de temps PSP, augmentation des pannes par code, TTW p95> 3m
Pics de tournois : p99 API/heure de début des jeux/queue lag ; promotion des limites/auto-skale.
Conclusions des fonds : SLA backoffice/contrôles manuels, limites par pays.
Fournisseurs de jeux : disponibilité par studio, heure d'initialisation de la session, baisse des lancements.
RG/Conformité : sursaut de longues sessions/ » dogon », dépassement des seuils - pas de page, mais tiquet + notification à l'équipe RG.
10) Exemples de règles (en option)
Haute latence 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"La file des conclusions « brûle »
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"Conversion des paiements échoués
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 et automatisation
Auto-poster alerts avec boutons d'action : Stop canary, Rollback, Scale + N.
Abréviations de commande : '/incident start ', '/status update', '/call
Les bots resserrent le contexte : les derniers déployages, le graphe des dépendances, les exemples de trace (exemplars), les tickets associés.
12) Travail post-incident (RCA)
Faits : Le temps qu'on a vu/ce qu'on a essayé, ce qui a marché.
Root cause : raisons techniques et organisationnelles.
Detections & Defenses : quels signaux ont aidé/laissé tomber.
Éléments d'action : tâches spécifiques (SLO/alertes/codes/limites/tests/runabook).
Due dates & owners : délais et responsables ; follow-up-session dans 2-4 semaines.
13) Chèque de mise en œuvre
1. Identifiez les SLI/SLO pour les flux clés (API/Payments/Games/TTW).
2. Configurez les règles d'enregistrement et les alertes multi-burn + le routage Alertmanager.
3. Entrez en ligne avec rotation, réactions SLO et escalade.
4. Attachez les alertes aux commandes runbooks et ChatOps.
5. Configurez la suppression/fenêtres silencieuses, annotations de versions/œuvres.
6. Faire des angoisses d'apprentissage et des scénarios de jour de jeu (baisse de PSP, croissance de p99, croissance de queue lag).
7. Mesurer la qualité d'alerte : MTTA/MTR, % noisy/false, coverage par SLO.
8. CR réguliers et révision des seuils/processus.
9. Entrez l'état des communications avec votre entreprise/Sapport (modèles).
10. Documentez tout comme un code : règles, itinéraires, liens runabook.
14) Anti-modèles
Alerting sur « chaque métrique » → alert-fetig, ignoré.
Est absent SLO → il est incompréhensible que "la norme" et que "brûle".
Absence de suppression/inhibition → avalanche de doublons.
Page la nuit pour les événements mineurs (SEV n'est pas comparable à Impact).
Alert sans runbook/propriétaire.
Actions « manuelles » sans ChatOps/audit.
Aucun items RCA/Action → répétition d'incidents.
Résultats
L'alerte et la réponse sont un processus, pas un ensemble de règles. Liez le SLO aux alertes multi-burn, construisez une escalade en ligne claire, ajoutez des ChatOps et des runabook-i en direct, effectuez régulièrement des RCA et des séances d'entraînement. Alors les incidents seront moins fréquents, plus courts et moins chers, et les versions sont plus prévisibles même pendant les heures chaudes d'iGaming.