Simulations d'incidents

1) Pourquoi faire des simulations

• réduire MTD/MTTA/MTR, augmenter la confiance dans les retraits et les faussaires ;
• identifier les lacunes dans les processus (escalade, communications) et les faiblesses architecturales ;
• servir d'entrée au RCA→CAPA et améliorer la documentation (runbook/SOP) ;
• confirment qu'ils sont prêts à répondre aux exigences du SLA/régulateur/audit.

2) Formats de simulation

Tabletop (bureau) est un scénario parlé sur le plateau/dans le chat : bon marché, rapide, idéal pour travailler les rôles et les communications.
Game Day (exercice en steadge/vente avec restrictions) - étapes pratiques sur le pleybuck ; dans la vente - seulement des actions sûres et réversibles avec des jeux clairs.
Chaos Engineering - pannes gérées (désactivation des dépendances/réseau/nœuds) pour vérifier la stabilité et les gates SLO.
Exercice DR (Disaster Recovery) - échec AZ/région, récupération des backups, changement de fournisseur.
Comms-drill - communications pures : page de statut, modèles de messages, PR/Legal.

3) Rôles et responsabilités

Commandant d'incident (IC) - Prend des décisions, dirige un plan, désescalade.
Tech Lead (TL) - diagnostics, « injections » techniques et hypothèses.
Comms Lead (CL) - Apdates internes/externes, page de statut.
Scribe est un protocole (temps, actions, solutions, artefacts).
Observers/Assessors - enregistrer les métriques et la conformité aux procédures.
Red Team (si désiré) - introduit des « injections » imprévues.

4) Mesures du succès des simulations

MTTD/MTTA/MTR sur un incident synthétique.
Bou SLA : actualité et qualité des updates.
SLO-guardrails : réponse correcte au taux de burn-rate, quorum d'échantillons externes.
Runbook fidelity :% des étapes ont été exécutées sur le document, sans improvisation.
Escalation latency : vitesse de connexion du bon rôle/fournisseur.
Checklists pass-rate : respect « prêt/accepté/fermé ».
Noise & Fatigue : alertes superflues, surchauffe sur appel.
CAPA completion : proportion des actions effectuées après simulation.

5) Préparation : Ce qu'il faut avant le départ

Objectif et hypothèses : ce que l'on vérifie (processus, architecture, personnes).
Scénario et « injections » : séquence de symptômes/événements avec timing.
Restrictions de sécurité : interdiction des changements irréversibles ; points d'annulation.
Données et stands : trafic synthétique, drapeaux de dégradation, clés de sécurité.
Documents : liens vers runbook/SOP, escalade, liste de contact des fournisseurs.
Observabilité : Dashboards/alerts préenregistrés, test-canaries.
Logistique : temps/durée, participants, canal war-room, enregistrement.

6) Réalisation de la simulation : Étapes

1. Brief (5-10 min) : IC rappelle les objectifs, les rôles, les règles de sécurité, les critères d'achèvement.
2. T0 - L'injection des symptômes : alert (s), la chute de l'entreprise SLI, le statut externe du fournisseur.
3. Triage et escalade : appropriation de SEV, sorties freeze, connexion des rôles souhaités.
4. Diagnostic : hypothèses, vérification DNS/TLS/CDN/OBD/cache/bus, annotations de sortie.
5. Activités de mitigation : otkat/kanareyka↓, drapeaux de dégradation de ficha, failover du fournisseur, limites/retraits.
6. Communications : Apdates régulières (format : Impakt→Diagnostika→Deystviya→Sled. update).
7. Récupération et vérification : synthétique externe + SLI dans la zone verte des N intervalles.
8. Debrief (AAR) : 15-30 min - faits, conclusions, CAPA.

7) Exemples de scénarios (catalogue)

Baisse du succès des paiements : le fournisseur A se dégrade dans un pays ; les actions attendues sont la redistribution du trafic, l'inclusion d'un UX simplifié, la communication.
Échec DNS : erreur d'écriture/TTL, certains utilisateurs ne résolvent pas le domaine ; les étapes attendues sont les fictions/folback, le nettoyage du CDN, le statut d'apdate.
Certificat TLS périmé : la poignée de main est cassée pour les anciens clients ; une extension d'urgence et une vérification de la chaîne sont prévues.
Kafka lag : augmentation du retard dans les événements KYC/AML ; les attentes sont de mettre à l'échelle les consommateurs, de limiter les producteurs.
DB p99 ↑ et croissance 5xx : indices étroits, limite de connexions ; attentes - drapeaux de ficha, limites, hotfix/retour.
Panne régionale : Désactivation de l'AZ/PoP ; attentes - GSLB/Anycast commutation, vérification des données et SLO.
Communication Drill : tout est « vert », mais nous vérifions les modèles, les intervalles et l'alignement avec Legal/PR.

8) Modèle « d'injection » (carte)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Sécurité et conformité

Les simulations de prod ne sont réversibles que : drapeaux de fich, changement de trafic en petites parts, répliques à lire, « shadow traffic ».
Contrôle d'accès/audit : toutes les activités via ChatOps/Pipline ; logs dans un coffre-fort immuable.
PII/secrets - ne sont pas utilisés dans les artefacts de formation ; les données sont dépersonnalisées.
Réglementation : si la simulation affecte les communications des clients - le marquage « enseignement » dans les canaux privés ; les posts publics ne sont pas imités.

10) Évaluation et AAR → RCA → CAPA

AAR (After Action Review) - juste après l'exercice : ce qui s'attendait/a vu ce qui a fonctionné/non.
RCA - pour les échecs importants (par exemple, l'escalade n'a pas fonctionné) selon le modèle RCA.
L'APA est une liste d'actions avec les propriétaires/délais/mesures de l'effet (changements dans les playbooks, alertes, architecture).
Points de contrôle - D + 14/D + 30 : vérification d'exécution, mini-drill répétée par endroits vulnérables.

11) Documentation et artefacts

Plan de simulation : objectifs, scénario, injections, participants, fenêtres, critères de succès.
Timline (UTC) : T0...Tn, solutions IC, étapes techniques, updates.
Photos de dashboards/logs, extraits d'alerts et de statuts.
Rapport final : métriques, écarts avec les pleybuks, CAPA.
Mises à jour de la documentation : modifications de runbook/SOP/contacts, liens vers de nouveaux dashboards.

12) Fréquence et couverture

Tabletop : 2 à 4 fois par mois (par flux clé et par rôle).
Game Days en steadge : 1-2 fois par mois.
Case Chaos (prod-light) : trimestrielle, strictement par gayte.
Exercice DR : 1 à 2 fois par an avec un changement réel.
Comms-drill : mensuel pour l'entraînement des modèles et des updates SLA.

13) Chèques-feuilles

Avant la simulation

• Scénario, « injections », critères de succès, fenêtres de sécurité.
• Les rôles, les canaux, l'état des modèles sont harmonisés.
• La disponibilité des stands/drapeaux/dashboards a été vérifiée.
• Le plan d'annulation et de réversibilité est documenté.
• Les risques et l'impact sur les OSL/clients sont évalués.

Pendant

• SEV attribué, versions libres (si nécessaire).
• Communications programmées, format maintenu.
• Toutes les actions via des outils avec vérification.
• Scribe tient un protocole, recueille des artefacts.
• Sécurité : les interdictions/restrictions sont respectées.

Après

• L'AAR a eu lieu, le rapport a été conservé.
• RCA (en cas d'échec) initié.
• Les ACPA sont formalisées avec les propriétaires/délais.
• runbook/SOP/contacts mis à jour.
• Un retest des lieux vulnérables est prévu.

14) Anti-modèles

« L'improvisation au lieu du plan » - il n'y a pas de scénario et de critères de succès.
Les risques sans gates et sans plan d'annulation - les exercices se transforment en incident.
Seule la technique sans communication et sans escalade.
L'absence d'AAR/RCA - l'équipe n'apprend pas.
Le chaos sans observation et les gardes SLO.
Droits opaques : modifications manuelles secrètes dans la vente.

15) Mini-modèles

Journée du jeu (60-90 min)

1. Brief (5 min) → Objectifs, rôles, sécurité.
2. Scénario T0 (5 min) → Présentation des symptômes.
3. Triage/escalade (10 min).
4. Diagnostic + actions (30-45 min) - 1-2 « injections ».
5. Récupération et vérification (10 min).
6. AAR (15 min) - conclusions, CAPA.

Modèle AAR (court)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Résultat

Les simulations d'incidents sont un « simulateur » pour les personnes, les processus et l'architecture. Des exercices réguliers, sûrs et mesurables transforment les crises en une routine : l'équipe réagit plus rapidement, les playbacks fonctionnent vraiment, l'architecture est plus durable et le régulateur et les clients voient la maturité de la fonction opérationnelle. L'essentiel est des objectifs clairs, des gates sûrs, de bonnes mesures et un AAR→RCA→CAPA obligatoire.