Root cause analysis — muammo yoki incidentning faqat ko‘rinadigan simptomini emas, uning yuzaga kelishiga va kengayishiga imkon bergan asosiy texnik hamda tashkiliy omillarni aniqlash jarayonidir. Maqsad aybdor shaxs topish emas, bir xil turdagi buzilishning qaytalanish ehtimolini kamaytiradigan tizimli o‘zgarishlarni belgilashdir.
Simptom, trigger va sabab
Simptom foydalanuvchi yoki monitoring ko‘rgan natija, masalan yuqori latency. Trigger muammoni ayni paytda boshlagan hodisa, masalan konfiguratsiya deployi. Root cause esa shu deployning nega xavfli bo‘lib productionga yetib kelgani va nega tizim uni cheklamaganini tushuntiradi. Bitta incidentda bir nechta contributing factor bo‘lishi mumkin.
“Muhandis noto‘g‘ri qiymat kiritdi” odatda yetarli tahlil emas. Validatsiya nega bo‘lmagan, review nega xatoni ko‘rmagan, blast radius nega katta bo‘lgan va rollback nega kechikkan savollari tizim chegarasini ochadi.
Dalil va timeline
Tahlil monitoring, log, trace, deployment record, audit yozuvi va ishtirokchi intervyusiga tayanadi. Avval faktik timeline tuziladi: qachon o‘zgarish bo‘ldi, birinchi simptom qachon ko‘rindi, qaysi qarorlar qabul qilindi va xizmat qachon tiklandi. Vaqt zonasi bir xil qilinadi, taxminlar alohida belgilanadi.
Correlation causation emas. Incident vaqtida CPU ko‘tarilgani uning sababchi ekanini isbotlamaydi. Gipoteza reproduksiya, controlled experiment, code path yoki qo‘shimcha telemetry bilan tekshiriladi. Yetarli dalil bo‘lmasa noaniqlik hujjatda saqlanadi.
Tahlil usullari
Five Whys bir javobdan keyin “nega” savolini davom ettirib chuqurroq nazorat yetishmovchiligini topadi. U qat’iy besh bosqich talab qilmaydi va faqat bitta chiziqli sababga majburlanmasligi kerak. Fishbone diagram odam, jarayon, texnologiya, muhit va dependency omillarini guruhlaydi.
Fault tree analysis yuqori darajadagi nosozlikni AND va OR shartlari orqali pastki hodisalarga ajratadi. Murakkab distributed tizimda sabablar tarmoq shaklida bo‘lishi tabiiy. Usul tanlashdan ko‘ra dalilga sodiq qolish muhim.
Tuzatish chorasi
Har action item aniq egasi, muddati va tekshiriladigan yakun mezoniga ega bo‘ladi. “Ehtiyotkor bo‘lish” kuchsiz chora; schema validation, canary, rate limit, avtomatik rollback yoki runbook kabi nazorat aniqroq. Chora prevention, detection, mitigation va recoveryni yaxshilashi mumkin.
Eng qimmat qayta arxitektura har doim birinchi tanlov emas. Incident ehtimoli, ta’siri va amalga oshirish narxi bo‘yicha ustuvorlik beriladi. Vaqtinchalik mitigation doimiy yechim o‘rnida muddatsiz qolmasligi uchun kuzatiladi.
Blameless yondashuv
Blameless review mas’uliyat yo‘q degani emas. U qaror qabul qilingan paytdagi ma’lumot, bosim va tizim sharoitini o‘rganadi. Qo‘rqituvchi muhit xodimni xatoni yashirishga undaydi; ochiq muhit esa weak signal va near miss haqida ertaroq ma’lumot beradi.
Hisobot tegishli jamoalar bilan ulashiladi, lekin maxfiy ma’lumot va shaxsiy tafsilotlar minimumda saqlanadi. Keyingi review actionlar haqiqatan bajarilganini va metrikada yaxshilanish berganini tekshiradi.
Tahlil sifati
Yaxshi RCA “nima bo‘ldi”dan tashqari “nega himoya qatlamlari uni to‘xtatmadi” savoliga javob beradi. Unda detection, response va recovery nega shu tezlikda ishlagani ham ko‘riladi. Birinchi texnik nuqsonni topib tahlilni tugatish latent organizational factorlarni yashiradi.
Hisobotga shartli qarama-qarshi savol foydali: shu trigger takrorlansa, yangi nazorat ta’sirni haqiqatan cheklaydimi? Action faqat hujjat yangilash bo‘lsa, avtomatlashtirish yoki design guardrail mumkinligi tekshiriladi. Shu bilan birga, har incidentdan haddan ortiq umumiy platforma qurish shart emas; chora dalilga mutanosib bo‘ladi. RCA natijasi keyingi incidentlarda qayta ishlatiladigan bilim bazasiga kiritiladi.
Bog‘liq tushunchalar
Incident, Postmortem, Five Whys, Fault tree analysis, Contributing factor, Corrective action, Blameless culture