Analiza cauzei rădăcinii

1) Ce este RCA și de ce este necesar

Root Cause Analysis este un proces structurat pentru identificarea cauzelor profunde ale unui incident pentru a preveni recurența. În centru - fapte, relații cauzale și îmbunătățiri sistemice (procese, arhitectură, teste), și nu căutarea de vină.
Obiective: prevenirea recidivei, reducerea ratei MTTR/incident, îmbunătățirea SLO, construirea încrederii cu autoritățile de reglementare și partenerii.

2) Principii (Just Culture)

Fără taxe. Nu pedepsim oameni, ci practici riscante.
Factualitate. Numai date și artefacte verificabile.
Vizualizare E2E. De la client la backend la furnizori.
Testabilitatea ipotezelor. Orice declarație - cu un test/experiment.
Închiderea CAPA. Măsuri corective și preventive cu proprietarii și termene limită.

3) Artefacte de intrare și pregătire

Linia de timp UTC: detectarea T0 → acțiunile T + → recuperarea T +.
Date de observabilitate: jurnale, valori (inclusiv prin cohortă), trasee, sintetice, pagină de stare.
Modificări: versiuni, steaguri de caracteristici, configurații, evenimente furnizor.
Mediu: versiuni, hash artefact, SBOM, etichete de infrastructură.
Baza de incidente: descrierea impactului (SLO/SLA, clienți, cifra de afaceri), decizii luate, soluție.
Lanțul de custodie: cine și când a colectat/modificat dovezi (important pentru conformitate).

4) metode RCA: când care

1. 5 De ce - rapid dau seama lanțul cauzal pentru probleme înguste. Risc: „rola” un sistem complex la o linie.
2. Fishbone - Clasificarea factorilor ca Oameni/Proces/Platformă/Politică/Partener/Produs. Util la început.
3. Analiza arborelui de eroare (ALS) - deducerea de la seturi de evenimente la seturi de cauze (AND/OR). Pentru infrastructură și defecțiuni copaci.
4. Grafic cauzal/Lanț de evenimente - grafic de dependență cu probabilități și greutate de contribuție. Bun pentru microservicii și furnizori externi.
5. FMEA (Failure Modes & Effects Analysis) - Prevenire: moduri de eșec, severitate (S), frecvență (O), detectabilitate (D), RPN = S × O × D.
6. Analiza schimbării - comparație „așa cum a fost/cum a devenit” (config diff, schema, versiuni).
7. Human Factors Review - contextul deciziilor oamenilor (oboseală alertă, cărți de redare proaste, supraîncărcare).

Combinație recomandată: Analiza modificării → Fishbone → Graficul cauzal/ALS → 5 De ce pe ramuri cheie.

5) Procesul RCA pas cu pas

1. Inițiați: numiți un proprietar RCA, stabiliți termenul limită pentru emiterea unui raport (de exemplu, 5 zile lucrătoare), adunați o echipă (IC, TL, Scribe, reprezentanți ai furnizorului).
2. Colecta fapte: cronologie, grafice, versiuni, busteni, artefacte; Fixați versiunile și controlul sumei.
3. Impactul hărții: care SLI/SLO au fost afectate, care sunt cohortele (țări, furnizori, VIP-uri).
4. Construiește ipoteze: primar, alternativ; verifica care sunt verificabile acum.
5. Ipoteze de testare: redarea pe scenă/simulare/canar, analiza urmelor, injectarea defecțiunilor.
6. Determinați cauzele rădăcinii și contribuției: tehnologice, de proces, organizaționale.
7. Forma CAPA: corectivă (corectă) și preventivă (prevenire); valori de succes și termene.
8. Reconcilierea și publicarea raportului: baza internă de cunoștințe +, dacă este necesar, versiunea externă pentru clienți/regulator.
9. Verificați efectul: puncte de control după 14/30 zile; acțiuni de închidere.

6) Ceea ce contează ca „cauza rădăcină”

• teste slabe/steaguri de caracteristici, limite/alerte lipsă, documentație ambiguă, defaults incorecte, arhitectură fragilă.
• De multe ori aceasta este o combinație de factori (configurare × lipsa unei porți × încărcare × furnizor).

7) CAPA: măsuri corective și preventive

• cod/config fix, model rollback, schimbarea limitelor/timeouts, adăugarea de indici, replica/sharding, redistribuirea traficului, actualizarea certificatului.

• teste (contract, cazuri de haos), alerte (rata de ardere, cvorum de sintetice), politica de lansare (canar/albastru-verde), GitOps pentru configurații, instruire/liste de verificare, duplicarea furnizorului, exerciții DR.

Fiecare acțiune: proprietar, termen limită, efect așteptat, metrică de verificare (de exemplu, o scădere a ratei de modificare-eșec cu X%, fără repetări de 90 de zile).

8) Verificarea ipotezelor și efectelor

Experimente: injecție/haos de eroare, trafic de umbre, configurații A/B, încărcare cu profile reale.
Măsurători de succes: recuperare SLO, stabilizare p95/p99, fără vârfuri de rată de eroare, reducere MTTR, tendință de ardere și redeschidere zero timp de 30 de zile.
Puncte de control: D + 7, D + 30, D + 90 - revizuirea implementării și impactului CAPA.

9) Șablon de raport RCA (intern)

1. Scurt rezumat: ce sa întâmplat când, cine a afectat.
2. Impact: SLI/SLO, utilizatori, regiuni, cifra de afaceri/penalități (dacă există).
3. Linia de timp (UTC): evenimente principale (alerte, decizii, versiuni, remedieri).
4. Observații și date: grafice, jurnale, urme, configurații (diffs), statusuri furnizor.
5. Ipoteze și teste: acceptate/respinse, trimiteri la experimente.
6. Cauze principale: tehnologice, de proces, organizatorice.
7. Factori care contribuie: „de ce nu a observat/nu sa oprit”.
8. Planul CAPA: tabel de acțiuni cu proprietari/termene limită/metrici.
9. Riscuri și vulnerabilități reziduale: ce altceva trebuie monitorizat/testat.
10. Aplicații: artefacte, link-uri, grafice (listă).

10) Exemplu (scurt, generalizat)

Eveniment: succes de plată pe 35% la 19: 05-19: 26 (SEV-1).
Impact: 21 min e2e-SLO încălcat, 3 țări afectate, returnări/compensări.
Motivul 1 (acestea): Noua versiune a validatorului cardului a crescut latența la 1. 2 s → timeout la furnizor.
Motivul 2 (procent): nu a existat nici un canar pentru furnizorul „A”, eliberarea a fost imediat 100%.
Motivul 3 (org): pragul de alertă privind SLI-ul de afaceri nu a acoperit o anumită gamă BIN (cohortă VIP).
CAPA: returnați vechea versiune a validatorului; introduceți canarul 1/5/25%; adăugați SLI-uri de afaceri prin cohorte BIN; convin asupra unui eșec de 30% pentru furnizorul „B”; caz haos „încetini în amonte”.

11) Măsurători ale maturității proceselor RCA

Finalizarea CAPA la timp (% închis în 30 de zile).
Rata de redeschidere (incidente redeschise în 90 de zile).
Schimbarea ratei de eșec înainte/după.
Proporția incidentelor în care se găsesc cauze sistemice (nu doar „eroare umană”).
Acoperirea testelor de noi scenarii de la RCA.
Timpul de lansare a raportului (publicarea SLA).

12) Caracteristici ale domeniilor reglementate (fintech/iGaming, etc.)

Raportarea către exterior: versiunile client/reglementare ale raportului fără detalii sensibile, dar cu un plan de prevenire a repetărilor.
Jurnalul de audit și imutabilitatea: stocarea artefactelor, a rapoartelor semnate, conectarea la bilete, CMDB, jurnalele de lansare.
Date utilizator: depersonalizare/mascare în jurnalele de probă.
Perioade de preaviz: legate de contracte și reglementări (ex. N ore pe notificare inițială).

13) Anti-modele

„Vasya este de vină” - o oprire a factorului uman fără motive sistemice.
Lipsa testelor de ipoteză - concluzii prin intuiție.
Prea general RCA („serviciul a fost supraîncărcat”) - nici o modificare specifică.
Fără CAPA sau fără proprietari/termene limită - raport de dragul raportului.
Ascunderea informațiilor - pierderea încrederii, incapacitatea de a instrui organizația.
Suprasarcină cu valori SLI non-SLO/business.

14) Instrumente și practici

Depozit RCA (wiki/baza de cunoștințe) cu metadate: serviciu, SEV, motive, CAPA, stare.
Șabloane și roboți: generarea unui cadru de raport dintr-un incident (cronologie, grafice, versiuni).
Graficul cauzalității: construirea unei hărți eveniment-cauzal (de exemplu, pe baza jurnalelor/urmelor).
Catalog haos: scripturi pentru reproducerea incidentelor din trecut în scenă.
Tablouri de bord „după RCA”: widget-uri individuale, care confirmă efectul CAPA.

15) Lista de verificare „gata de publicare”

• Termenele și artefactele sunt complete și verificate.
• Cauze rădăcină identificate și dovedite prin teste/experimente.
• Rădăcina și cauzele care contribuie sunt separate.
• CAPA conține proprietari, termene limită, metrici de efect măsurabile.
• Există un plan de verificare în 14/30 zile.
• Versiunea pentru părțile interesate externe este pregătită (dacă este necesar).
• Raportul a trecut de revizuire tech/procent.

16) Linia de jos

RCA nu este o retrospectivă de dragul formalității, ci un mecanism de învățare pentru sistem. Când faptele sunt colectate, cauzalitatea este dovedită, iar CAPA-urile sunt blocate în valori și testate prin experimente, organizația devine mai stabilă de fiecare dată: SLO-urile sunt mai stabile, riscul de recidivă este mai mic, iar încrederea utilizatorilor și a reglementărilor este mai mare.