Gestion des incidents

(Section : Technologie et infrastructure)

Résumé succinct

La gestion des incidents est un processus répétable de récupération rapide de la valeur utilisateur et de réduction des dommages à l'entreprise. Le support - des rôles clairs (Insident Manager, Tech Lead, Comms), des gates SLO, des escalades, des processus ChatOps, des runabuks préparés et des analyses post-incidents « inoffensives » avec des items mesurables.

1) Objectifs et principes

Rapidité et sécurité : diagnostic rapide → stabilisation sûre → rétablissement durable.
Seul propriétaire : le Gestionnaire d'incidents (GI) désigné prend des décisions de processus.
Communications en tant que produit : Apdates prévisibles pour les stackholders et les utilisateurs.
Données> opinions : SLO/métriques/remorques/logs sont la source de la vérité.
Blameless : analyse des causes sans charges personnelles ; mettre l'accent sur les améliorations systémiques.

2) Classification des incidents (Severity/Impact/Urgence)

• SEV1 (Le critique) : le préjudice sérieux à la recette/TTW/paiements,> 20 % des utilisateurs ou les régions entières; SLA perturbée/menace PII.
• SEV2 (élevé) : dégradation partielle des flux clés (dépôt/pari/lancement de jeux), impact de 5 à 20 %.
• SEV3 (moyenne) : dégradation marquée des services secondaires, il y a contournement.
• SEV4 (faible) : mineur, effet limité, sans effet sur le SLO/SLA.

Impact : qui sont touchés (tous/région/tenant/canal). Urgence : taux de dégradation (fast-burn/slow-burn sur le budget des erreurs).

3) Cycle de vie de l'incident

1. Detect est le signal des alerts/SLO/synthétiques/répliques.
2. Acknowledge - on-call confirme la réception, attribue IM.
3. Triage - évaluation SEV/Impact, collecte d'hypothèses, ouverture de la salle de guerre.
4. Mitigate - stabilisation (retour/changement de route/ficheflagi/mise à l'échelle).
5. Communicate est un statut apdate régulier (intérieur/extérieur).
6. Recover - Restauration complète des métriques SLO/métier.
7. Close - fixation de la chronologie, collecte des artefacts, PIR (RCA + action items).

4) Rôles et responsabilités (schéma RACI)

Incident Manager (IM) - le propriétaire du processus, attribue des rôles, surveille le temps, prend des décisions de processus (R).
Direction technique (TL) - dirige les diagnostics/hypothèses/fiches, coordonne les ingénieurs (A/R).
Communications (Comms) - État-update, lien avec le support/entreprise/PR, page de statut (R).
Scribe est un protocole (temporel, décisions prises, références, artefacts) (R).
Stakeholders - produits/paiements/fournisseurs de jeux/sécurité (C/I).

Minimum par SEV1 : IM + TL + Comms + Scribe. Vous pouvez combiner les rôles sur le SEV2.

5) War-Room и ChatOps

Canaux individuels : '# incident-warroom- <id>' (ouvrier), '# incident-status' (updates uniquement).
Commandes de modèle : '/incident start ', '/status update', '/call <owner> ', '/rollback', '/freeze ', '/scale + N'.
Bot resserre le contexte : dernières sorties, dashboards, alertes connectées, trace implars, schémas de dépendance.
Règles de communication : Bref, sur les faits, un orateur (TL), IM modère.

6) Déclencheurs et gates

Gates SLO : fast/slow burn, baisse de la conversion des paiements, TTW p95> seuil, API p99 ↑, files de paiement « brûlent ».
Autopsie : stop canary, rollback, activation du mode degrade (limitation des fonctions), activation des synthétiques haute fréquence.
Freeze : toutes les sorties/migration stop avant stabilisation et PIR.

7) Scénarios types (modèles de runabook)

A) Paiements : Augmentation du délai d'attente/refus du PSP

1. Stop promote et le gel des versions du circuit de paiement.
2. Commuter l'itinéraire PSP en attente, soulever le délai/retraits par politique.
3. Rapprochement des transactions en cours, répétition des clés idempotentes.
4. Communication Comms → Sapport : Est-ce que la réserve fonctionne ? ETA.

B) API p99↑ et 5xx après la sortie

1. Retour arrière (bleu-vert/canary → stable).
2. Vérifiez le cache, la profondeur des files d'attente, les points chauds des bases de données/fournisseurs de jeux.
3. Mise à l'échelle temporaire, limitation des fiches lourdes grâce à la fonctionnalité flags.

C) Fournisseur de jeux non disponible

1. Changer le trafic vers les studios/jeux disponibles, afficher la bannière de statut.
2. Inclure les contrôles synthétiques tous les 30-60c.
3. Négocier les rémunérations/bonus (selon la politique) - verser au PIR.

D) Fuite/suspicion de PII

1. Composant d'isolation, révocation des clés/tokens, collection de logs (WORM).
2. Harmonisation de la communication juridique/réglementation.
3. Actions post-incidents : rotation secrète, masquage, accès.

8) Communications (internes/externes)

Fréquence des apdates : SEV1 - toutes les 15-30 min, SEV2 - 30-60 min.

• Ce qui est cassé : « Dépôts via PSP-X : augmentation des délais ».
• Qui a été touché : « TR/BR, ~ 18 % des utilisateurs du flux ».
• Quand a commencé : « 12:07 EET, SEV1. »
• Ce que nous faisons : « Nous passons de l'itinéraire à PSP-Y, les retraits/plafonds de taux sont inclus ».
• « Dans 20 minutes ».
• Contact : « IM @ duty-im, TL @ oncall-pay ».

Statut public (page/réseaux sociaux) - abrégé, sans PII et détails supplémentaires, avec ETA et un lien vers d'autres mises à jour.

9) Collecte et vérification des artefacts

Événements temporels (précision des minutes), versions des services, drapeaux ficha, changements de configues.
Photos de dashboards, pistes approximatives (trace_id), logs « avant/pendant/après ».
Liens vers tickets, PR, communiqués, runabooks.
Rapport sur les communications (quand/à/quoi).
C'est une carte d'incident.

10) Fermeture et PIR (Post-Incident Review)

• Résumé : ce qui s'est passé, échelle, durée, SEV.
• Impact : utilisateurs/régions, SLO/SLA, fin. effet.
• Timline : en détail, par minute.
• Root Cause : Technique + organisationnel (pourquoi pas détecté avant).
• Detections & Defenses : ce qui a aidé/laissé tomber (alertes, synthétiques, ficheflags).
• Éléments d'action : tâches spécifiques, propriétaires, échéances (et comment vérifier l'effet).
• Lessons Learned : ce qui change dans le processus/architecture/observabilité.

Règles : pas de charges, maximum de faits, obligatoire follow-up après 2 à 4 semaines de vérification des points remplis.

11) Métriques de fiabilité du processus

MTD (Mean Time To Detect) est le temps moyen de détection.
MTTA (… Acknowledge) - avant de confirmer on-call.
MTTR (… Restore) - avant la restauration de SLO.
Change Failure Rate - % des versions qui ont conduit à des incidents.
Taux d'incident par SEV, distribution par domaine (Payments/Games/Infra).
Qualité d'alerte : proportion de bruits/faux, temps avant l'action après l'alerte.
Comm-SLA : respect de la périodicité des status-updates.

12) Intégrations avec SLO et versions

Gates en CD : promotion canaris uniquement sous proxy SLO vert (disponibilité, p95, bou, TTW).
Procédures Freeze : À la fast-burn/SEV1 - stop releases to PIR.
Annotations automatiques dans les graphiques : les sorties/drapeaux/migrations sont visibles sur les dashboards.

13) Réglementation et conformité

PII : masquage/pseudonyme dans les logs/trajets, référentiel d'audit WORM, contrôle d'accès.
Régionalité : ne pas amener les données des utilisateurs hors des juridictions autorisées.
Rapports : Lettres officielles/avis aux organismes de réglementation - modèles et processus d'escalade.

14) Formation et préparation (Game-Day)

Exercice trimestriel : « chute PSP », « fournisseur de jeux inaccessible », « p99 sursaut », « fuite de clé ».
Minuteurs sur MTTA/MTR, rétro par exercice.
Mise à jour des runabooks et des contacts, vérification des commandes ChatOps.

15) Chèque de disponibilité (avant l'incident)

1. Règles SEV et matrice d'escalade harmonisées.
2. Rotation sur appel, IM/TL/Comms/Scribe.
3. Runabooks par scénarios clés (paiements, jeux, bases de données, caches, files d'attente).
4. SLO map et burn-rate alerte, status page.
5. ChatOps-bot : commandes, contact automatique, modèles de statut.
6. Modèles PIR et cartes d'incident.
7. Jour-jeu régulier et révisions des contacts/droits.
8. Politique de freeze et « bouton rouge » (rollback/kill-switch).

16) Anti-modèles

Il n'y a pas d'IM unique, la « foule est en tête » → le chaos et les retards.
L'absence de gats SLO → la détection tardive, les alertes bruyantes.
La sortie lors de l'incident sans freeze → des pannes en cascade.
Il n'y a pas assez de loges et de caravanes, pas d'artefacts → un PIR faible.
La culture accusatrice → les erreurs cachées, la peur de l'escalade.
Communications « par inspiration » → perte de confiance des entreprises/utilisateurs.

17) Modèles (copiez dans votre wiki)

A) Carte d'incident (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Statut d'apdate (interne)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (chapeau)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Résultats

Une gestion forte des incidents est une structure + discipline : des rôles prédéfinis, des gates SLO, des runabooks travaillés, des communications transparentes et un PIR « inoffensif ». Ce circuit réduit MTTA/MTR, réduit le coût des interruptions, renforce la confiance des utilisateurs et permet une sortie plus audacieuse - mais en toute sécurité.