Root Cause Analysis

1) RCA nədir və niyə lazımdır

Root Cause Analysis - hadisənin təkrarlanmasını istisna etmək üçün hadisənin kök səbəblərini müəyyən etmək üçün strukturlaşdırılmış proses. Mərkəzdə - faktlar, səbəb-nəticə əlaqələri və sistem təkmilləşdirmələri (proseslər, memarlıq, testlər), günahkarların axtarışı deyil.
Məqsədlər: təkrar hadisələrin qarşısını almaq, MTTR/hadisə tezliyini azaltmaq, SLO-nu yaxşılaşdırmaq, tənzimləyicilərin və tərəfdaşların etibarını gücləndirmək.

2) Prinsiplər (Just Culture)

Heç bir ittiham. Biz insanları deyil, riskli təcrübələri cəzalandırırıq.
Faktoloji. Yalnız yoxlanılan məlumatlar və artefaktlar.
E2E-baxış. Müştəridən backend və provayderlərə qədər.
Hipotezlərin yoxlanılması. Hər hansı bir iddia - test/təcrübə ilə.
CAPA-qapanma. Sahibləri və şərtləri ilə düzəliş və xəbərdarlıq tədbirləri.

3) Giriş artefaktları və hazırlanması

UTC Time Line: T0 aşkar → T + fəaliyyət → T + bərpa.
Müşahidə məlumatları: loqlar, metriklər (o cümlədən kohortlar üzrə), treyslər, sintetika, status-səhifə.
Dəyişikliklər: buraxılışlar, fiç bayraqlar, konfiqlər, provayder hadisələri.
Mühit: versiyalar, hash artefaktları, SBOM, infrastruktur işarələri.
Hadisə bazası: impakt təsviri (SLO/SLA, müştərilər, dövriyyə), qəbul edilmiş qərarlar, workaround 'lar.
Chain of custody: dəlilləri kim və nə vaxt topladı/dəyişdirdi (uyğunluq üçün vacibdir).

4) RCA metodları: nə zaman

1. 5 Why - dar problemlər üçün səbəb zəncirini tez bir zamanda tapın. Risk: mürəkkəb sistemi cetveldən əvvəl «sıxmaq».
2. İşikava diaqramı (Fishbone) - faktorları kateqoriyalara ayırmaq: People/Process/Platform/Policy/Partner/Product. Başlanğıcda faydalıdır.
3. Fault Tree Analysis (FTA) - hadisədən səbəblər dəstinə (AND/OR) qədər deduksiya. Infrastruktur və «ağac üzərində» uğursuzluqlar üçün.
4. Causal Graph/Event Chain - ehtimal və töhfə çəkisi ilə asılılıq qrafiki. Mikroservislər və xarici provayderlər üçün yaxşıdır.
5. FMEA (Failure Modes & Effects Analysis) - profilaktika: nasazlıq rejimləri, ağırlıq (S), tezlik (O), aşkarlanma (D), RPN = S × O × D.
6. Change Analysis - «olduğu kimi/olduğu kimi» müqayisə (diff konfiqurasiyalar, sxema, versiyalar).
7. Human Factors Review - insanların qərarlarının kontekstidir (alert yorğunluq, pis playbook, həddindən artıq yükləmə).

Tövsiyə olunan ligament: Fishbone → Change Analysis → Causal Graph/FTA → 5 Əsas filiallarda nə.

5) RCA addım-addım prosesi

1. Təşəbbüs etmək: RCA sahibini təyin etmək, hesabatın buraxılış müddətini müəyyən etmək (məsələn, 5 iş günü), komanda toplamaq (IC, TL, Scribe, provayderlərin nümayəndələri).
2. Faktları toplayın: taymline, qrafiklər, buraxılışlar, qeydlər, artefaktlar; versiyaları qeyd və məbləğləri nəzarət.
3. Təsirin xəritəsi: hansı SLI/SLO-lar, hansı kohortlar (ölkələr, provayderlər, VIP).
4. Hipotezlər qurmaq: ilkin, alternativ; indi yoxlanılan qeyd edin.
5. Hipotezləri yoxlayın: steyj/simulyasiya/kanareyka, treys analizi, fault injection.
6. Kök və asanlaşdırıcı səbəbləri müəyyənləşdirin: texnoloji, proses, təşkilati.
7. CAPA formalaşdırmaq: düzəliş (düzəliş) və xəbərdarlıq (qarşısını almaq); uğur metrik və vaxt.
8. Razılaşdırın və hesabatı dərc edin: daxili bilik bazası + lazım olduqda, müştərilər/tənzimləyici üçün xarici versiya.
9. Effektin təsdiqlənməsi: 14/30 gün sonra nəzarət nöqtələri; hərəkətlərin bağlanması.

6) «kök səbəb» hesab olunur

• zəif testlər/fiç bayraqları, çatışmayan limitlər/alertlər, qeyri-müəyyən sənədlər, səhv defoltlar, kövrək memarlıq.
• Çox vaxt bu amillərin birləşməsidir (konfiqurasiya × geyt olmaması × yük × provayder).

7) CAPA: düzəliş və xəbərdarlıq tədbirləri

• kod/konfiqurasiya fiksi, nümunənin geri qaytarılması, limitlərin/vaxtların dəyişdirilməsi, indekslərin əlavə edilməsi, replika/şərdinq, trafikin yenidən paylanması, sertifikatların yenilənməsi.

• testlər (müqavilə, xaos-cases), alertlər (burn rate, sintetik kvorum), reliz siyasəti (canary/blue-green), konfiqlər üçün GitOps, təlim/çek vərəqələri, provayder təkrarlanması, DR təlimləri.

Hər bir hərəkət: sahibi, son tarix, gözlənilən effekt, yoxlama metrikası (məsələn, change-failure-rate-in X% azalması, 90 gün təkrarlanmaması).

8) Hipotez və effektlərin təsdiqi

Təcrübələr: fault injection/chaos, shadow-trafik, A/B konfiqurasiyaları, real profilləri ilə yükləmə.
Uğur göstəriciləri: SLO-nun bərpası, p95/p99 sabitləşdirilməsi, error-rate sıçrayışlarının olmaması, MTTR-in azaldılması, burn-rate trendi və 30 gün ərzində zero-reopen.
Nəzarət nöqtələri: D + 7, D + 30, D + 90 - CAPA və təsirin icrasına yenidən baxılması.

9) RCA hesabat şablonu (daxili)

1. Qısa xülasə: nə oldu, kimə təsir etdi.
2. İmpakt: SLI/SLO, istifadəçilər, regionlar, dövriyyə/cərimələr (varsa).
3. Timline (UTC): əsas hadisələr (qərarlar, həllər, buraxılışlar, fikslər).
4. Müşahidələr və məlumatlar: qrafiklər, qeydlər, izlər, konfiqlər (difflər), provayder statusları.
5. Hipotezlər və yoxlamalar: qəbul/rədd, eksperimentlərə istinadlar.
6. Kök səbəbləri: texnoloji, proses, təşkilati.
7. Kömək edən amillər: «Niyə hiss etmədilər/dayandırmadılar».
8. CAPA planı: sahibləri/şərtləri/metrikləri ilə hərəkət cədvəli.
9. Risklər və qalıq zəifliklər: daha nə izləmək/sınaqdan keçirmək lazımdır.
10. Proqramlar: artefaktlar, linklər, qrafiklər (siyahı).

10) Nümunə (qısa, ümumiləşdirilmiş)

Hadisə: ödənişlərin uğurunun 35% azalması 19: 05-19: 26-da (SEV-1).
İmpakt: e2e-SLO 21 dəqiqə pozuldu, 3 ölkəyə təsir etdi, geri qaytarma/kompensasiya.
Səbəb 1 (tech): kart validatorunun yeni versiyası gecikməni 1-ə qədər artırdı. 2 s → provayder üçün vaxt.
Səbəb 2 (faiz): «A» provayderi üçün canary yox idi, buraxılış dərhal 100% keçdi.
Səbəb 3 (org): Biznes SLI-nin alert həddi konkret BIN-diapazonu (VIP-kogorta) əhatə etməmişdir.
CAPA: validatorun köhnə versiyasını geri qaytarmaq; canary daxil edin 1/5/25%; BIN kohortlarına biznes SLI əlavə edin; «B» provayderinə failover 30% razılaşmaq; «slow upstream» xaos case.

11) RCA prosesinin yetkinlik metrikası

CAPA-nın vaxtında yerinə yetirilməsi (30 gün ərzində bağlanmış%).
Reopen rate (90 gün ərzində yenidən kəşf edilən hadisələr).
Change-failure-rate əvvəl/sonra.
Sistemli səbəblərin tapıldığı hadisələrin payı (yalnız «insan səhvi» deyil).
RCA-dan yeni ssenarilərin testlərini əhatə edir.
Hesabatın buraxılış vaxtı (SLA nəşrləri).

12) Tənzimlənən domenlərin xüsusiyyətləri (fintech/iGaming və s.)

Hesabat: həssas detalları olmadan, lakin təkrarların qarşısını almaq planı ilə hesabatın müştəri/tənzimləyici versiyaları.
Audit-log və dəyişməzlik: artefaktların saxlanması, imzalanmış hesabatlar, biletlərə, CMDB-lərə, buraxılış loqlarına bağlanması.
İstifadəçi məlumatları: giriş nümunələrində depersonalizasiya/maskalanma.
Bildiriş müddətləri: müqavilələrə və normalara bağlamaq (məsələn, ilkin bildiriş üçün N saat).

13) Anti-nümunələr

«Vasya günahkardır» - sistemli səbəblər olmadan insan amilində dayanmaq.
Hipotez yoxlamalarının olmaması intuisiya nəticələridir.
Çox ümumi RCA («xidmət həddindən artıq yükləndi») - konkret dəyişiklik olmadan.
CAPA yoxdur və ya sahibləri/şərtləri yoxdur - hesabat üçün hesabat.
Məlumatların gizlədilməsi - etimadın itirilməsi, təşkilatın öyrənilməsinin mümkünsüzlüyü.
SLO/Business SLI ilə əlaqə olmadan metrik həddindən artıq yükləmə.

14) Alətlər və təcrübələr

Metadata ilə RCA (wiki/knowledge base) saxlama: xidmət, SEV, səbəblər, CAPA, status.
Şablonlar və botlar: hadisədən hesabat çərçivəsinin yaradılması (timline, qrafiklər, buraxılışlar).
Səbəb qrafiki: hadisə-səbəb xəritəsinin qurulması (məsələn, log/treys əsasında).
Chaos kataloq: Steyj keçmiş hadisələri oynamaq üçün ssenarilər.
Dashboards «RCA sonra»: CAPA təsiri təsdiq ayrı-ayrı widget.

15) Çek siyahısı «nəşrə hazırdır»

• Time line və artefaktlar tam və yoxlanılır.
• Kök səbəbləri testlər/təcrübələr tərəfindən müəyyən edilmiş və sübut edilmişdir.
• Kök və kömək səbəbləri bölünür.
• CAPA sahibləri, vaxt, ölçülə bilən effekt metrikləri ehtiva edir.
• 14/30 gün sonra bir yoxlama planı var.
• Xarici steykholderlər üçün versiya hazırlanmışdır (lazım olduqda).
• Hesabat/faiz review keçdi.

16) Yekun

RCA formalizm üçün retrospektiv deyil, sistemin öyrənilməsi mexanizmidir. Faktlar toplandıqda, səbəblər sübuta yetirildikdə və CAPA metriklərə qapandıqda və təcrübələrlə yoxlanıldıqda, təşkilat hər dəfə daha sabit olur: SLO daha sabitdir, residiv riski daha azdır və istifadəçilərin və tənzimləyicilərin etimadı daha yüksəkdir.