Root Cause Analysis

1) RCA nima va nima uchun kerak

Root Cause Analysis - takrorlanishni istisno qilish maqsadida hodisaning ildiz sabablarini aniqlashning tarkibiy jarayoni. Markazda aybdorlarni topish emas, balki faktlar, sabab-oqibat aloqalari va tizimli yaxshilanishlar (jarayonlar, arxitektura, testlar) mavjud.
Maqsadlar: retsidivning oldini olish, MTTR/hodisalar chastotasini kamaytirish, SLOni yaxshilash, tartibga soluvchilar va hamkorlarning ishonchini mustahkamlash.

2) Tamoyillar (Just Culture)

Ayblovsiz. Biz odamlarni emas, balki xavfli amaliyotlarni jazolaymiz.
Faktologik. Faqat tekshiriladigan ma’lumotlar va artefaktlar.
E2E-qarash. Mijozdan tortib, bekend va provayderlargacha.
Gipotezalarning tekshirilishi. Har qanday bayonot - test/eksperiment bilan.
CAPA-yopilish. Egalari va muddatlari bilan tuzatish va ogohlantirish choralari.

3) Kirish artefaktlari va tayyorlash

UTC orqali taymline: T0 topish → T + harakat → T + tiklash.
Kuzatish ma’lumotlari: loglar, metriklar (shu jumladan kogortlar bo’yicha), treyslar, sintetika, maqom-sahifa.
Oʻzgarishlar: relizlar, fich bayroqlar, konfiglar, provayder voqealari.
Atrof-muhit: versiyalar, xesh artefaktlar, SBOM, infratuzilma belgilari.
Hodisa bazasi: impakt tavsifi (SLO/SLA, mijozlar, aylanma), qabul qilingan qarorlar, workaround’lar.
Chain of custody: dalillarni kim va qachon to’plagan/o’zgartirgan (komplayens uchun muhim).

4) RCA metodikasi: qachon

1. 5 Why - tor muammolar uchun sabablar zanjirini tezda aniqlash. Xavf: murakkab tizimni liniyagacha «burish».
2. Ishikava diagrammasi (Fishbone) - omillarni quyidagi toifalarga bo’lish: People/Process/Platform/Policy/Partner/Product. Boshida foydali.
3. Fault Tree Analysis (FTA) - hodisadan sabablar toʻplamiga deduksiya (AND/OR). Infratuzilma va «yog’och» dan voz kechish uchun.
4. Causal Graph/Event Chain - ehtimollik va hissa og’irligi bilan bog’liqlik grafasi. Mikroservislar va tashqi provayderlar uchun yaxshi.
5. FMEA (Failure Modes & Effects Analysis) - profilaktika: nosozlik rejimlari, og’irlik (S), chastota (O), aniqlanish (D), RPN = S × O × D.
6. Change Analysis - «qanday bo’lgan/qanday bo’lgan» (diff konfiguratsiyalar, schema, versiyalar) taqqoslash.
7. Human Factors Review - odamlarning qarorlari konteksti (alert charchoq, yomon pleybuklar, ortiqcha yuk).

Tavsiya etilgan bog’lov: Fishbone → Change Analysis → Causal Graph/FTA → 5 Why.

5) RCA bosqichma-bosqich jarayoni

1. Tashabbus koʻrsatish: RCA egasini tayinlash, hisobot chiqarish muddatini belgilash (masalan, 5 ish kuni), jamoa yigʻish (IC, TL, Scribe, provayderlar vakillari).
2. Faktlarni to’plash: taymline, grafiklar, relizlar, loglar, artefaktlar; versiyalarni qayd etish va summalarni nazorat qilish.
3. Ta’sirni xaritalash: qaysi SLI/SLOlar zarar ko’rgan, qaysi kogortlar (mamlakatlar, provayderlar, VIP).
4. Farazlar qurish: birlamchi, muqobil; qaysi tekshirilayotganligini belgilash.
5. Gipotezalarni tekshirish: steyj/simulyatsiya/kanareykada takrorlash, treyslarni tahlil qilish, fault injection.
6. Ildiz va ko’maklashuvchi sabablarni aniqlash: texnologik, protsessual, tashkiliy.
7. CAPAni shakllantirish: tuzatuvchi (tuzatuvchi) va ogohlantiruvchi (oldini olish); muvaffaqiyat metrikasi va muddatlari.
8. Hisobotni kelishish va e’lon qilish: ichki bilim bazasi + zarurat bo’lganda mijozlar/regulyator uchun tashqi versiya.
9. Samarani tekshirish: nazorat nuqtalari 14/30 kunda; harakatlarni yopish.

6) «asosiy sabab» nima hisoblanadi

• zaif testlar/fich-bayroqlar, mavjud bo’lmagan limitlar/alertlar, noaniq hujjatlar, noto’g "ri defoltlar, mo’rt arxitektura.
• Ko’pincha bu omillarning kombinatsiyasi (konfiguratsiya × geyt yo’qligi × yuk × provayder).

7) CAPA: tuzatish va ogohlantirish choralari

• kod/konfiguratsiyalar fiksi, pattern qaytishi, limitlar/taymautlar o’zgarishi, indekslar qo’shilishi, replik/sharding, trafikni qayta taqsimlash, sertifikatlarni yangilash.

• testlar (kontrakt, xaos-keyslar), alertlar (burn rate, sintetika kvorumi), relizlar siyosati (canary/blue-green), konfigiga GitOps, o’qitish/chek-varaqlar, provayderni takrorlash, DR-mashqlar.

Har bir harakat: egasi, muddati, kutilayotgan effekti, tekshirish metrikasi (masalan, change-failure-rate ning X% ga pasayishi, 90 kun takrorlanmasligi).

8) Gipotezalar va effektlarni verifikatsiya qilish

Tajribalar: fault injection/chaos, shadow-trafik, A/B konfiguratsiyalari, haqiqiy profillar bilan yuklash.
Muvaffaqiyat metrikasi: SLOni tiklash, p95/p99 barqarorlashtirish, error-rate portlashlarining yo’qligi, MTTRni qisqartirish, burn-rate va zero-reopen bo’yicha 30 kunlik trend.
Nazorat nuqtalari: D + 7, D + 30, D + 90 - CAPA bajarilishi va ta’sirini qayta ko’rib chiqish.

9) RCA hisoboti namunasi (ichki)

1. Qisqacha xulosa: nima yuz berdi, kimga tegdi.
2. Impakt: SLI/SLO, foydalanuvchilar, hududlar, aylanma/jarimalar (agar mavjud bo’lsa).
3. Timline (UTC): asosiy voqealar (alertlar, qarorlar, relizlar, fikslar).
4. Kuzatuv va ma’lumotlar: grafiklar, loglar, trassirovkalar, konfiglar (difflar), provayder maqomlari.
5. Gipotezalar va tekshirishlar: qabul qilingan/rad etilgan, tajribalarga havolalar.
6. Ildiz sabablari: texnologik, protsessual, tashkiliy.
7. Ko’maklashuvchi omillar: «nega sezmadingiz/to’xtatmadingiz».
8. CAPA-reja: egalari/muddatlari/metriklari bilan harakatlar jadvali.
9. Xavf-xatarlar va qoldiq zaifliklar: yana nimani kuzatish/sinash kerak.
10. Ilovalar: artefaktlar, havolalar, grafiklar (ro’yxat).

10) Misol (qisqa, umumlashtirilgan)

Hodisa: to’lovlar muvaffaqiyatining 35% ga pasayishi 19: 05-19: 26 (SEV-1).
Impakt: e2e-SLO 21 daqiqa buzilgan, 3 mamlakatga taʼsir koʻrsatilgan, qaytarish/kompensatsiya.
Sababi 1 (tech): karta validatorining yangi versiyasi latentligini 1 ga oshirdi. 2 s → taymautlar provayderga.
Sababi 2 (foiz): «A» provayderi uchun canary yo’q edi, chiqarish birdaniga 100% o’tdi.
Sababi 3 (org): biznes-SLI bo’yicha alert-chegara aniq BIN-diapazonni (VIP-kogorta) qamrab olmagan.
CAPA: validatorning eski versiyasini qaytarish; canary 1/5/25% kiritilsin; BIN-kogortlar bo’yicha biznes-SLI qo’shish; "B" provayderiga 30% failover to’g "risida kelishib olish; «slow upstream» xaos-keysi.

11) RCA-jarayonning etuklik metrikasi

CAPAni muddatida bajarish (30 kun ichida yopilganlarning%).
Reopen rate (90 kunda qayta ochilgan hodisalar).
Change-failure-rate to/keyin.
Tizimli sabablar aniqlangan hodisalar ulushi (nafaqat «inson xatosi»).
Yangi RCA stsenariylarini testlar bilan qamrab olish.
Hisobot chiqarish vaqti (SLA nashr).

12) Tartibga solinadigan domenlarning xususiyatlari (fintex/iGaming va h.k.)

Hisobot tashqariga: hisobotning mijoz/tartibga soluvchi versiyalari sezgir detallarsiz, lekin takrorlanishlarning oldini olish rejasi bilan.
Audit-log va o’zgarmasligi: artefaktlarni saqlash, imzolangan hisobotlar, tiketlarga, CMDBlarga, reliz loglariga bog’lash.
Foydalanuvchi maʼlumotlari: log namunalarida depersonalizatsiya/maskalash.
Xabardor qilish muddatlari: kontraktlar va normalarga bog’lash (masalan, birlamchi xabardor qilish uchun soat N).

13) Anti-patternlar

«Vasya aybdor» - inson omiliga tizimli sabablarsiz to’xtash.
Farazlarni tekshirishning yo’qligi - sezgi bo’yicha xulosalar.
Ortiqcha umumiy RCA («xizmat ortiqcha yuklangan») - aniq o’zgarishlarsiz.
CAPA mavjud emas yoki mavjud emas - hisobot uchun hisobot.
Axborotni yashirish - ishonchni yo’qotish, tashkilotni o’qitishning imkoni yo’qligi.
SLO/biznes-SLI bilan bog’lamagan metriklar bilan qayta yuklash.

14) Asboblar va amaliyotlar

RCA (wiki/knowledge base) ombori: xizmat, SEV, sabablar, CAPA, maqom.
Shablonlar va botlar: hodisadan hisobot ramkasini yaratish (taymline, grafiklar, relizlar).
Sabablar grafigi: hodisa-sabablar xaritasini tuzish (masalan, loglar/treyslar asosida).
Chaos katalogi: steyjdagi oʻtmishdagi hodisalarni takrorlash uchun skriptlar.
Dashboards «RCA dan keyin»: CAPA ta’sirini tasdiqlovchi alohida vidjetlar.

15) «Chop etishga tayyor» chek-varag’i

• Taymline va artefaktlar to’liq va tekshirilgan.
• Ildiz sabablari test/eksperimentlar orqali aniqlangan va isbotlangan.
• Ildiz va yordam beruvchi sabablar ikkiga boʻlingan.
• CAPA’da egalari, muddatlari, o’lchanadigan effekt metrikasi mavjud.
• 14/30 kun ichida tekshirish rejasi mavjud.
• Tashqi steykholderlar uchun versiya tayyorlangan (agar kerak boʻlsa).
• Hisobot shu/foiz revyudan oʻtdi.

16) Jami

RCA - rasmiyatchilik uchun retrospektiv emas, balki tizimni o’rganish mexanizmi. Ma’lumotlar yig’ilganda, sabablar isbotlanganda, CAPA esa metriklarga yopiq bo’lib, eksperimentlar bilan tekshirilganda, tashkilot har safar barqarorlashadi: SLO barqarorroq, retsidiv xavfi past, foydalanuvchilar va regulyatorlarning ishonchi yuqori bo’ladi.