Root Cause Analysis

1) Qu'est-ce que RCA et pourquoi il est nécessaire

Root Cause Analysis est un processus structuré pour identifier les causes racines d'un incident afin d'éviter la répétition. Au centre, il y a les faits, les causalités et les améliorations systémiques (processus, architecture, tests), pas la recherche des coupables.
Objectifs : prévenir la rechute, réduire le TTMO et le taux d'incidents, améliorer le SLO, renforcer la confiance des organismes de réglementation et des partenaires.

2) Principes (Just Culture)

Pas d'accusation. Nous ne punissons pas les gens, mais les pratiques à risque.
Factualité. Seulement les données vérifiables et les artefacts.
E2E-look. Du client au backend et aux fournisseurs.
La vérifiabilité des hypothèses. Toute affirmation - avec test/expérience.
Fermeture CAPA. Mesures correctives et préventives avec les propriétaires et délais.

3) artefacts d'entrée et préparation

Temporisation UTC : Détection T0 → T + actions → T + récupération.
Données d'observation : logs, métriques (par cohorte), trajets, synthétiques, page de statut.
Changements : sorties, drapeaux fich, confights, événements providentiels.
Environnement : versions, hachage d'artefacts, SBOM, étiquettes d'infrastructure.
Base d'incident : description de l'impact (SLO/SLA, clients, chiffre d'affaires), décisions prises, workaround's.
Chain of custody : qui et quand a recueilli/modifié les preuves (important pour la conformité).

4) Techniques RCA : quand laquelle

1. 5 Why - découvrez rapidement la chaîne causale pour les problèmes étroits. Risque : « réduire » un système complexe à la règle.
2. Diagramme Ishikawa (Fishbone) : Décomposez les facteurs en catégories : People/Process/Platform/Policy/Partner/Product. Utile au début.
3. Analyse des arbres de Fault (FTA) est une déduction d'un événement à un ensemble de causes (AND/OR). Pour les infrastructures et les pannes « par bois ».
4. Causal Graph/Event Chain est un graphe de dépendances avec probabilités et poids de contribution. Bon pour les microservices et les fournisseurs externes.
5. FMEA (Failure Modes & Effects Analysis) - prévention : modes de défaillance, gravité (S), fréquence (O), détectabilité (D), RPN = S × O × D.
6. Change Analysis - comparaison « comment il a été/comment il est devenu » (diff configs, schema, versions).
7. Human Factors Review est le contexte des décisions des gens (fatigue alerte, mauvais playbooks, surchauffe).

Ligament recommandé : Fishbone → Change Analysis → Causal Graph/FTA → 5 Why par branche clé.

5) Processus étape par étape RCA

1. Initier : désigner le propriétaire du RCA, définir le délai de publication du rapport (par exemple, 5 jours ouvrables), rassembler l'équipe (IC, TL, Scribe, représentants des fournisseurs).
2. Rassembler les faits : temps, graphiques, sorties, logs, artefacts ; enregistrer les versions et contrôler les montants.
3. Cartographier l'impact : quels SLI/SLO ont été touchés, quelles cohortes (pays, fournisseurs, VIP).
4. Construire des hypothèses : primaires, alternatives ; noter quels sont les vérifiables maintenant.
5. Vérifier les hypothèses : reproduction sur steadge/simulation/canari, analyse de trajets, fausse injection.
6. Identifier les causes profondes et contributives : technologique, process, organisationnel.
7. Former un CAPA : correctif (corriger) et avertisseur (empêcher) ; métriques de succès et échéances.
8. Harmoniser et publier le rapport : base de connaissances interne +, si nécessaire, version externe pour les clients/régulateurs.
9. Vérifier l'effet : points de contrôle après 14/30 jours ; fermeture des actions.

6) Ce qui est considéré comme une « cause racine »

• tests faibles/drapeaux fich, limites manquantes/alertes, documentation ambiguë, défauts de paiement incorrects, architecture fragile.
• C'est souvent une combinaison de facteurs (configuration × absence de gate × charge × fournisseur).

7) CAPA : mesures correctives et préventives

• fix code/configues, retour en arrière du modèle, modification des limites/délais, ajout d'index, réplique/charding, redistribution du trafic, mise à jour des certificats.

• tests (contractuels, cas de chaos), alerts (taux de burn, quorum synthétique), politique de libération (canary/blue-green), GitOps sur les configues, formation/chèque, duplication du fournisseur, exercice DR.

À chaque action : propriétaire, dedline, effet attendu, métrique de validation (par exemple réduction de X % du taux de changement-failure, pas de répétition de 90 jours).

8) Vérification des hypothèses et des effets

Expériences : fault injection/chaos, trafic shadow, A/B configs, charge avec des profils réels.
Métriques de succès : récupération de SLO, stabilisation p95/p99, pas de surtensions de taux d'erreur, réduction de MTTR, tendance de taux de burn et zero-reopen pendant 30 jours.
Points de contrôle : D + 7, D + 30, D + 90 - révision de l'exécution du CAPA et de l'influence.

9) Modèle de rapport RCA (interne)

1. Bref résumé : ce qui s'est passé, quand, qui a été touché.
2. Impact : SLI/SLO, utilisateurs, régions, chiffre d'affaires/sanctions (le cas échéant).
3. Timline (UTC) : événements majeurs (alertes, solutions, sorties, fiches).
4. Observations et données : graphiques, logs, tracés, configis (diffas), statuts de fournisseurs.
5. Hypothèses et vérifications : acceptées/rejetées, références à des expériences.
6. Causes profondes : processus, processus, organisation.
7. Facteurs contributifs : « pourquoi n'a-t-on pas remarqué/arrêté ».
8. Plan CAPA : tableau d'activités avec les propriétaires/échéanciers/métriques.
9. Risques et vulnérabilités résiduelles : quoi d'autre à surveiller/tester.
10. Annexes : artefacts, liens, graphiques (liste).

10) Exemple (bref, résumé)

Événement : baisse de 35 % du taux de réussite des paiements à 19 h 05-19 h 26 (SEV-1).
Impact : 21 mines sont e2e-SLO perturbées, 3 pays touchés, retours/indemnités.
Raison 1 (s) : la nouvelle version du validateur de carte a augmenté la latence à 1. 2 s → de temps d'attente au fournisseur.
Raison 2 (%) : il n'y avait pas de canary pour le fournisseur « A », la sortie a eu lieu immédiatement à 100 %.
Raison 3 (org) : le seuil d'alerte de l'IAS d'entreprise ne couvrait pas une bande BIN spécifique (cohorte VIP).
CAPA : récupérer l'ancienne version du validateur ; introduire 1/5/25 % de canary ; ajouter des IAS d'entreprise par cohortes BIN ; négocier un échec de 30 % pour le fournisseur « B » ; « slow upstream ».

11) Métriques de maturité du processus RCA

Exécution de l'APA dans les délais (pourcentage fermé de 30 jours).
Taux de renouvellement (incidents rouverts dans les 90 jours).
Change-failure-rate avant/après.
Proportion d'incidents où des causes systémiques ont été trouvées (et pas seulement une « erreur humaine »).
Couvrir avec les tests de nouveaux scénarios de RCA.
Heure de publication du rapport (publication SLA).

12) Caractéristiques des domaines réglables (fintech/iGaming, etc.)

Rapports à l'extérieur : versions client/réglementaire du rapport sans détails sensibles, mais avec un plan de prévention des répétitions.
Audit-logs et immuabilité : stockage des artefacts, rapports signés, liens vers les tickets, CMDB, logs de sortie.
Données utilisateur : dépersonnalisation/masquage dans les exemples de logs.
Délais de notification : attacher aux contrats et aux normes (p. ex. N heures pour la notification principale).

13) Anti-modèles

« La faute de Vasia » est un arrêt sur un facteur humain sans raison systémique.
L'absence de vérification des hypothèses est une conclusion de l'intuition.
RCA trop général (« le service a été surchargé ») - pas de changements spécifiques.
Pas de CAPA ou pas de propriétaires/délais - rapport pour le rapport.
Cacher des informations est une perte de confiance, l'impossibilité de former une organisation.
Surchauffe avec des métriques sans lien avec SLO/SLI d'affaires.

14) Outils et pratiques

Stockage RCA (wiki/base de connaissances) avec métadonnées : service, SEV, causes, CAPA, statut.
Modèles et bots : génération d'un cadre de rapport à partir d'un incident (temps, graphiques, versions).
Graphique de causalité : Construction d'une carte de cause à effet (par exemple, basée sur des logs/trajets).
Répertoire Chaos : scripts pour lire les incidents passés dans le steadge.
Dashboards « après RCA » : widgets individuels qui confirment l'effet CAPA.

15) Chèque-feuille « prêt à être publié »

• Le temps et les artefacts sont complets et vérifiés.
• Les causes racines sont déterminées et prouvées par des tests/expériences.
• Les causes racine et contributive sont séparées.
• L'APCA contient les propriétaires, les délais, les mesures mesurables de l'effet.
• Il y a un plan de vérification dans 14/30 jours.
• Version préparée pour les stackholders externes (si nécessaire).
• Le rapport est passé par/%.

16) Résultat

RCA n'est pas une rétrospective pour la formalité, mais un mécanisme d'apprentissage du système. Lorsque les faits sont recueillis, que la causalité est prouvée et que les CAPA sont scellés et testés par des expériences, l'organisation devient chaque fois plus résistante : SLO est plus stable, le risque de rechutes est plus faible et la confiance des utilisateurs et des régulateurs est plus élevée.