Réaction aux incidents et aux accidents

(Section : Opérations et gestion)

1) Définitions et objectifs

L'incident est un événement qui viole la SLO/sécurité/conformité ou crée un risque pour les clients, l'argent, les données, la réputation.
Les objectifs de la réaction : rétablir rapidement le service, minimiser les dommages, enregistrer les preuves, communiquer de manière transparente et empêcher la répétition.

Principes clés

Safety first : la protection des personnes/données/argent est plus importante que les fonctions.
One throat to choke : un seul commandant d'incident (IC) prend des décisions.
Maintenant activable : chaque hypothèse est accompagnée d'une vérification/action.
Evidence matters : tout est logé, les artefacts sont signés, le temps est détaillé.

2) Classification (severity & priority)

Déclencheur : violation de SLO, règle d'alerte, répétition manuelle, incident juridique (DPO/CCO).

3) Rôles et responsabilités (RACI)

Le commandant d'incident (A) est le chef de file de l'incident, de l'établissement des tâches, de la prise de décision, des changements d'IC dans les incidents longs.
Tech Lead (R) - diagnostic technique/fictions, coordination SRE/ingénierie.
Comms Lead (R) - le propriétaire du statut-page écrit les statuts-rénovations (au-dedans/extérieurement).
Scribe (R) - protocole, temporisation, collecte d'artefacts.
Security/Legal (C/A pour les cas de titrisation) - évaluation des risques, notifications obligatoires.
Support client (C) - modèles de réponses, routage de tickets.
Lien partenaire (C) - communication avec les fournisseurs/tenants.
Gestion (I) - information, solutions d'affaires (prêts/compensations).

4) Les 15 premières minutes (modèle)

1. Assigner un IC et ouvrir une carte d'incident (chat-chain, vidéo, Jira/Tracker).
2. Attribuer SEV et enregistrer un symptôme SLO (exactement ce qui est perturbé).

• activer les runbooks/runes : circuit-breakers, trottinette, changement d'itinéraire, pause promo ;
• si vous compromettez - kill-switch des fonctions sensibles.
• 4. Commandes : Tech Lead - Diagnostic ; Comms - « hold technique » (10-15 min - première mise à jour).
• 5. Définir les hypothèses (trois maximum), nommer les propriétaires, mettre les minuteurs à l'essai (5-10 min).
• 6. Collectionner des artefacts : snapshots de métriques, configis, hachages de versions, logs avec 'trace _ id', reçus.

5) Première heure (modèle)

Communication v1 (15-20 min) : fait, couverture, symptômes, ce que nous faisons, prochaine mise à jour. Pas de spéculation.
Limites de l'incident : quelles sont les régions/tenants/canaux/versions touchées.
Contrôle des dommages : caps temporaires/restrictions, désactivation des intégrations « bruyantes », activation du mode de dégradation.
Forensica : geler les rotations de loges, protéger les artefacts (WORM/signatures).
Feuille de route de récupération : T + 30/T + 60 avec chèques-points.

6) Communications et status page

Intervalles intérieurs : P1 - toutes les 15 min, P2 - 30-60 min.
Externe : page de statut/tenants/partenaires SLA.

• Ce qui est visible : « avec X : YY UTC augmentation des pannes de checkout dans la région EU (p95> 250 ms) »
• Qui est concerné : « opérateurs A/B/C, ~ 40 % du trafic »
• Ce que nous faisons : "ont inclus un itinéraire alternatif, la trottinette promo ; travailler avec le fournisseur de PSP-1"
• Données/doublures : « prochaine mise à jour dans 15 min »
• Indemnisation : « les notes de crédit selon SLA applicables après la clôture de l'incident »

7) Pleybuki (référents pour iGaming/fintech)

PriceMismatch (vitrine ≠ checkout) : cache de force handicapé, rapprochement 'fx _ version/tax _ rule _ version', gel des promotions dynamiques, compensation des différences de politique.
WebhookLag (partenaires/affiliés) : mise à l'échelle des workers, augmentation des batch, priorité des retraits, caps temporaires pour les nouveaux abonnements.
Paiement Outage/dégradation PSP : basculement vers une PSP de secours, réduction du délai d'attente des clients, compensation manuelle de la file d'attente, transactions « grises » en quarantaine.
RTP Drift : pause bonus, vérification des tables de paiement/versions, extension de la fenêtre d'observation, retour en arrière du profil RTP.
Fraud Spike : resserrer la velocité/limites, inclure un contrôle KYC supplémentaire, isoler les cohortes suspectes, ronfler manuellement les gains élevés.
Exposition Data/PII : isolation des systèmes, notification DPO/Legal, inventaire des dossiers concernés, avis réglementaires selon le calendrier.

8) Outils et runes (auto-actions)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Garde : protection contre la « selle » - les retours sont limités, les journaux sont signés, chaque action est ↔ IC/Scribe.
Preuve : signatures DSE, hachages de snapshots, Merkle-tranches de logs.

9) Fin de l'incident

Critères : SLO récupéré, file d'attente remboursée, données/argent réduit, risques fermés, communications envoyées.
Rituel de clôture : la mise à jour finale du statut, le temps fixé, la liste des influences, les hypothèses préliminaires des causes, la date du post-mortem a été fixée.

10) Post-mortem (sans charges)

Délai : P1 - dans les 3 jours ouvrables ; P2 - 5 jours ouvrables.
Contenu : faits/temps, causes profondes (5 Whys/FRAM), impact (SLO, finances, clients), ce qui a fonctionné/non, éléments d'action (owner, durée, effet mesurable).
Contrôle de l'efficacité : après 30 à 60 jours - rhubarbe d'exécution et métriques (répétabilité, MTTR, bruit d'alertes).

11) Métriques et SLO incident-gestion

MTD/MTTA/MTR, Taux d'échec de changement, Time to Comms v1, % auto-autorisé (runes).
Alert Noise : proportion de signaux non pertinents, pages per on-call shift.
Répétitions : proportion de répétitions en 90 jours.
SLA post-mortem : proportion effectuée/fermée à temps.
Réaction SLO : P1 est la première communication ≤ 15 min ; MTTR ≤ 60 min ; la plénitude des artefacts = 100 %.

12) Droit/conformité/vie privée

Mentions légales : délais des régulateurs locaux pour les fuites/incidents.
Minimisation des PII : accès à la primaire uniquement par des jobs approuvés ; Tokenisation/masquage.
Stockage des artefacts : Journaux WORM, période de conservation par juridiction ; contrôle d'accès (RBAC/ABAC, JIT).
Contreparties : SLA contractuels, processus d'escalade, reçus de procédure.

13) Organisation des opérations de garde et d'escalade

24 × 7 on-call : rotation par rôle (SRE, App, Data, Security, Payments).
Matrice d'escalade : qui sont les régions/produits/fournisseurs ; duplication des contacts (chat/voix/SMS).
L'exercice (GameDays) : simulations - chute de la PSP, avalanche de retraits, dissynchron des prix, compromission de la clé, refus de la région.

14) Dashboards d'incidents

Chaleur (maintenant) : statut SLO, p95/p99, carte des régions/tenants, file d'attente des tâches, artefacts collectés/non.
Historique : tendances par type d'incident, efficacité des runes, répétabilité des causes.
Contrôle de qualité : exhaustivité du temps, « coverage » post mortem, communications SLA.

15) Chèque de mise en œuvre

• Approuver l'échelle SEV et les déclencheurs SLO.
• Attribuer des rôles (IC/Tech/Comms/Scribe/Sec/Legal) et des rotations 24 × 7.
• Exécutez un modèle unique de carte d'incident et une page de statut.
• Décrire les playbacks (PriceMismatch/WebhookLag/Payments/RTP/Fraud/PII).
• Réaliser des runes avec un audit et un « bouton rouge ».
• Inclure la politique forenzik : WORM/signatures/collecte d'artefacts.
• Règlement sur les communications (interne/externe). , les mises à jour SLA.
• Post-mortem processus et modèles ; KPI d'exécution d'items d'action.
• GameDays mensuellement ; examen trimestriel des tendances des incidents.
• Métriques IR sur dashboard (MTTA/MTTR/Noise/Repeat/Comms SLA).

16) FAQ

Pourquoi « IC one » ?
Un seul point de décision élimine le chaos et accélère la réaction.

Quand annoncer publiquement ?
Dès qu'il y a un fait confirmé et un plan de stabilisation. Évaluer les délais réglementaires.

Qu'y a-t-il de plus important - une fiction ou un rapport ?
D'abord, la restauration et la sécurité. En parallèle, la collecte d'artefacts. Rapport - après stabilisation.

Puis-je tout automatiser ?
Non, mais les runes ferment les étapes « fréquentes et simples ». Le reste est à travers des playbooks clairs et l'entraînement.

Résumé : Une forte réponse d'incident n'est pas seulement PagerDuty et un canal de chat. C'est la discipline des rôles, les 15 premières minutes rapides, les runes guidées, les communications transparentes, la forenserie avec preuve et le post-mortem obligatoire. Avec une telle boucle, vous réduisez le MTTR, protégez l'argent et les données, et augmentez la confiance des clients et des régulateurs.