Root Cause Analysis

1) RCA деген эмне жана эмне үчүн керек

Root Cause Analysis - кайталанууну болтурбоо үчүн окуянын негизги себептерин аныктоо үчүн структураланган процесс. Борбордо - фактылар, себептик байланыштар жана системалык жакшыртуулар (процесстер, архитектура, тесттер), күнөөлүүлөрдү издөө эмес.
Максаттары: кайталанууну алдын алуу, MTTR/инциденттердин жыштыгын азайтуу, SLOну жакшыртуу, жөнгө салуучулардын жана өнөктөштөрдүн ишенимин бекемдөө.

2) Принциптер (Just Culture)

Айыпсыз. Адамдарды эмес, тобокелдүү тажрыйбаларды жазалайбыз.
Фактология. Болгону текшерилүүчү маалыматтар жана экспонаттар.
E2E-көрүнүш. Кардардан баштап Backend жана провайдерлерге чейин.
Гипотезаларды текшерүү. Ар кандай билдирүү - тест/эксперимент менен.
CAPA-райондук. Ээлери жана мөөнөттөрү менен түзөтүү жана эскертүү чаралары.

3) кириш экспонаттар жана даярдоо

UTC боюнча убакыт: T0 аныктоо → T + аракет → T + калыбына келтирүү.
Байкоо маалыматтары: логи, метрика (анын ичинде когорттор боюнча), трейстер, синтетика, статус-бет.
Өзгөртүүлөр: релиздер, fich желектери, конфиги, провайдердик окуялар.
Айлана-чөйрө: версиялар, хеш экспонаттар, SBOM, инфраструктуралык белгилер.
Окуя базасы: импакт сүрөттөлүшү (SLO/SLA, кардарлар, жүгүртүү), кабыл алынган чечимдер, workaround 'ы.
Chain of custody: ким жана качан чогулткан/далилдерди өзгөрткөн (комплаенс үчүн маанилүү).

4) RCA ыкмалары: качан

1. 5 Why - тез тар маселелер үчүн себеп чынжыр аныктоо. Тобокелдик: татаал системаны линияга чейин "кыскартуу".
2. Isikawa диаграммасы (Fishbone) - категориялар боюнча факторлорду бөлүү: People/Process/Platform/Policy/Partner/Product. башында пайдалуу.
3. Fault Tree Analysis (FTA) - окуядан себептер топтомуна (AND/OR) чейин дедукция. Инфраструктура жана "жыгачтан" баш тартуу үчүн.
4. Causal Graph/Event Chain - ыктымалдуулук жана салым салмагы менен көз карандылыктын саны. Микросервистер жана тышкы провайдерлер үчүн жакшы.
5. FMEA (Failure Modes & Effects Analysis) - алдын алуу: бузулуу режимдери, оордугу (S), жыштыгы (O), аныктоо (D), RPN = S × O × D.
6. Change Analysis - салыштыруу "кандай болгон/кандай болгон" (дифф конфигурациялары, схемалар, версиялар).
7. Human Factors Review - адамдардын чечимдеринин контексти (Алерт чарчоо, начар ойнотмо, ашыкча жүк).

Сунушталган байланыш: Fishbone → Change Analysis → Causal Graph/FTA → 5 Why негизги бутактары боюнча.

5) RCA кадам

1. Демилгелөө: RCA ээсин дайындоо, отчетту чыгаруу мөөнөтүн аныктоо (мисалы, 5 жумушчу күн), команда чогултуу (IC, TL, Scribe, провайдерлердин өкүлдөрү).
2. Фактыларды чогултуу: таймлайн, графиктер, релиздер, логилер, экспонаттар; версияларды жана суммаларды көзөмөлдөөнү бекитүү.
3. Картага таасир: кандай SLI/SLO жапа чеккен, кайсы когорттор (өлкөлөр, провайдерлер, VIP).
4. гипотезаларды куруу: баштапкы, башка; азыр кандай текшерилерин белгилеш керек.
5. гипотезаларды текшерүү: Stage/Simulation/канарейка ойнотуу, Tracks талдоо, fault injection.
6. Негизги жана өбөлгө түзгөн себептерди аныктоо: технологиялык, процесстик, уюштуруучулук.
7. CAPA түзүү: түзөтүү (туура) жана эскертүү (жол бербөө); Ийгиликтин көрсөткүчтөрү жана мөөнөттөрү.
8. макулдашуу жана отчет жарыялоо: ички билим базасы + зарыл болсо, кардарлар/жөнгө салуучу үчүн тышкы версия.
9. Эффектти текшерүү: 14/30 күндүн ичинде көзөмөл пункттары; иш-аракеттерди жабуу.

6) "негизги себеби" болуп эсептелет

• алсыз тесттер/fich желектери, жок лимиттер/алерттер, түшүнүксүз документтер, туура эмес дефолттар, морт архитектура.
• Көбүнчө бул факторлордун айкалышы (конфигурация × гейт жоктугу × жүк × провайдер).

7) CAPA: түзөтүү жана алдын алуу чаралары

• коддун/конфигурациялардын фикси, үлгүнүн кайтарылышы, лимиттердин/таймдардын өзгөрүшү, индекстерди кошуу, реплика/шардинг, трафикти кайра бөлүштүрүү, сертификаттарды жаңыртуу.

• тесттер (келишимдик, башаламандык учурларда), алерталар (burn rate, синтетикалык кворум), релиздер саясаты (canary/blue-green), GitOps боюнча config, окутуу/чек баракчалары, провайдерди кайталоо, DR-машыгуулар.

Ар бир иш-аракет: ээси, мөөнөтү, күтүлгөн таасири, текшерүү метрикасы (мисалы, X% га төмөндөшү change-failure-rate, 90 күн кайталоо жок).

8) Гипотезаларды жана таасирлерди текшерүү

Эксперименттер: fault injection/chaos, shadow-трафик, A/B конфигурациялары, реалдуу профилдер менен жүктөө.
Ийгиликтин көрсөткүчтөрү: SLO калыбына келтирүү, p95/p99 турукташтыруу, эч кандай error-rate, MTTR кыскартуу, бурн-rate жана zero-reopen тенденциясы 30 күн.
Контролдук пункттары: D + 7, D + 30, D + 90 - CAPA аткаруу жана таасир кайра карап чыгуу.

9) RCA отчет үлгүсү (ички)

1. Кыскача резюме: качан болгон, ким таасир эткен.
2. Импакт: SLI/SLO, колдонуучулар, региондор, жүгүртүү/айып (бар болсо).
3. Таймлайн (UTC): негизги окуялар (алерт, чечимдер, релиздер, фикстер).
4. Байкоолор жана маалыматтар: графиктер, логилер, трассировкалар, конфигалар (диффалар), провайдердик статустар.
5. Гипотезалар жана текшерүүлөр: кабыл алынган/четке кагылган, эксперименттерге шилтемелер.
6. Тамыр себептери: технологиялык, процесстик, уюштуруучулук.
7. Көмөктөшкөн факторлор: "эмне үчүн байкаган жокмун/токтоткон жокмун".
8. CAPA-план: ээлери/мөөнөттөр/метриктер менен иш-аракеттер таблицасы.
9. Тобокелдиктер жана калдык алсыздыктар: дагы эмне мониторинг/тестирлөө керек.
10. Тиркемелер: экспонаттар, шилтемелер, сүрөттөр (тизмеси).

10) Мисал (кыска, жалпыланган)

Окуя: төлөмдөрдүн ийгилигинин 35% га төмөндөшү 19: 05-19: 26 (SEV-1).
Impact: e2e-SLO бузулган 21 мин, таасир 3 өлкө, кайтаруу/ордун толтуруу.
Себеби 1 (тех): карта валидаторунун жаңы версиясы латенттүүлүктү 1 чейин көбөйттү. 2 с → провайдерге убакыт.
Себеби 2 (пайыз): "А" провайдери үчүн канары жок, релиз дароо 100% өттү.
Себеби 3 (орг): бизнес-SLI боюнча алерт босогосу конкреттүү BIN диапазонун (VIP-когорта) камтыган эмес.
CAPA: validator эски нускасын кайтаруу; canary киргизүү 1/5/25%; BIN коддору боюнча бизнес-SLI кошуу; "В" провайдерине 30% failover жөнүндө макулдашуу; башаламандык "slow upstream".

11) Жетилүү Метрика RCA-жараяны

CAPA аткаруу (30 күндүн ичинде жабылган%).
Reopen rate (90 күндүн ичинде кайра ачылган окуялар).
Change-failure-rate чейин/кийин.
Системалуу себептер табылган окуялардын үлүшү ("адамдын катасы" гана эмес).
RCA жаңы жагдайлар сыноолорду камтыйт.
Отчет чыгаруу убактысы (SLA жарыялоо).

12) жөнгө домендердин өзгөчөлүктөрү (fintech/iGaming ж.б.)

Отчеттуулук сыртка: кардарлардын/жөнгө салуучу отчеттун версиялары сезимтал деталдары жок, бирок кайталоону алдын алуу планы менен.
Аудит-журнал жана өзгөрүлбөстүк: артефакттарды сактоо, кол коюлган отчеттор, тикеттерге, CMDB, релиздик логдорго шилтеме.
Колдонуучунун маалыматтары: Логдордун мисалдарында деперсонализация/маскировка.
Билдирүүлөрдүн мөөнөттөрү: контракттарга жана нормаларга байланыштыруу (мисалы, баштапкы билдирүүгө саат N).

13) Анти-үлгүлөрү

"Күнөөлүү Вася" - системалуу себептерсиз адам факторуна токтоо.
Гипотезаларды текшерүүнүн жоктугу - интуиция боюнча корутундулар.
Өтө жалпы RCA ("кызмат ашыкча жүктөлгөн") - эч кандай конкреттүү өзгөрүүлөр.
эч кандай CAPA же эч кандай ээлери/мөөнөттөрү - отчет үчүн отчет.
Маалыматты жашыруу - ишенимди жоготуу, уюмду окута албоо.
SLO/бизнес-SLI менен байланышсыз метриктер менен ашыкча жүктөө.

14) Инструменттер жана практикалар

RCA сактоо (wiki/knowledge base) метадерилери менен: кызматы, SEV, себептери, CAPA, абалы.
Шаблондор жана боттор: окуядан отчеттун алкагын түзүү (таймлайн, графиктер, релиздер).
Себептик графа: окуя-себептик картаны куруу (мисалы, логдордун/трейстердин негизинде).
Chaos каталогу: Stage өткөн окуяларды ойнотуу үчүн жагдайлар.
Dashboards "RCA кийин": CAPA таасирин тастыктаган өзүнчө виджеттер.

15) Чек-тизмеси "жарыялоого даяр"

• Таймлайн жана экспонаттар толук жана текшерилген.
• тамыр себептери аныкталган жана тесттер/эксперименттер менен далилденген.
• тамыр жана салым себептер бөлүнгөн.
• CAPA кожоюндары, убакыт, өлчөнүүчү метрикалык таасир камтыйт.
• 14/30 күндүн ичинде текшерүү планы бар.
• Тышкы Stakholders үчүн версия даярдалган (керек болсо).
• Отчет/пайыз-ревю өттү.

16) Жыйынтык

RCA - бул формалдуулук үчүн ретроспективалык эмес, системаны окутуу механизми. Фактылар чогултулганда, себептүүлүк далилденсе, ал эми CAPA метрикага жабылып, эксперименттер менен текшерилгенде, уюм ар дайым туруктуураак болуп калат: SLO туруктуураак, рецидивдердин коркунучу төмөн, колдонуучулардын жана жөнгө салуучулардын ишеними жогору болот.