Root Cause Analysis

1) RCA дегеніміз не және ол не үшін қажет

Root Cause Analysis - қайталануды болдырмау мақсатында оқыс оқиғаның негізгі себептерін анықтаудың құрылымдалған процесі. Орталықта - кінәлілерді іздеу емес, фактілер, себеп-салдарлық байланыстар және жүйелі жақсартулар (процестер, сәулет, тестілер).
Мақсаттары: рецидивті болдырмау, инциденттердің MTTR/жиілігін төмендету, SLO-ны жақсарту, реттеушілер мен әріптестердің сенімін нығайту.

2) Қағидаттар (Just Culture)

Айыптаусыз. Адамдарды емес, тәуекелді практикаларды жазалаймыз.
Фактологиялық. Тек тексерілетін деректер мен артефактілер.
E2E-көзқарас. Клиенттен бэкенд пен провайдерлерге дейін.
Гипотезалардың тексерілуі. Кез келген бекіту - тестімен/экспериментімен.
CAPA-тұйықталу. Иелерімен және мерзімдерімен түзету және ескерту шаралары.

3) Кіру артефактілері және дайындау

UTC бойынша таймлайн: T0 анықтау → T + әрекет → T + қалпына келтіру.
Бақылау деректері: логи, метрика (оның ішінде когорталар бойынша), трейстер, синтетика, статус-бет.
Өзгерістер: релиздер, фич-жалаулар, конфигалар, провайдерлік оқиғалар.
Қоршау: нұсқалар, артефактілердің хэштері, SBOM, инфрақұрылымдық белгілер.
Инцидент базасы: импакт сипаттамасы (SLO/SLA, клиенттер, айналым), қабылданған шешімдер, workaround's.
Chain of custody: дәлелдемелерді кім және қашан жинаған/өзгерткен (комплаенс үшін маңызды).

4) RCA әдістемелері: қашан қандай

1. 5 Why - тар мәселелер үшін себеп тізбегін тез анықтау. Тәуекел: күрделі жүйені сызғышқа дейін «бұрау».
2. Исикава (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. Болжамдарды тексеру: стейждегі/симуляциядағы/канарейкадағы жаңғырту, трейстерді талдау, fault injection.
6. Түбірлік және ықпал ететін себептерді анықтау: технологиялық, процестік, ұйымдастырушылық.
7. CAPA қалыптастыру: түзету (түзету) және ескерту (жол бермеу); сәттілік өлшемдері мен мерзімдері.
8. Есепті келісу және жариялау: ішкі білім базасы + қажет болған жағдайда клиенттер/реттеуші үшін сыртқы нұсқасы.
9. Нәтижені верификациялау: бақылау нүктелері 14/30 күннен кейін; әрекетті жабу.

6) «Түпкі себеп» деп не саналады

• әлсіз тесттер/фич-жалаулар, жоқ лимиттер/алерттар, екі мағыналы құжаттама, қате дефолттар, осал сәулет.
• Көбінесе бұл факторлардың комбинациясы (конфигурация × гейттің болмауы × жүктеме × провайдер).

7) CAPA: түзету және ескерту шаралары

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

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

Әрбір әрекет: иесі, мерзімі, күтілетін әсері, тексеру метрикасы (мысалы, change-failure-rate X% -ға төмендеуі, 90 күн қайталанбауы).

8) Гипотезалар мен әсерлерді верификациялау

Эксперименттер: fault injection/chaos, shadow-трафик, A/B пішіндері, нақты профильдері бар жүктеме.
Сәттілік өлшемдері: SLO қалпына келтіру, p95/p99 тұрақтандыру, error-rate жарылыстарының болмауы, MTTR қысқаруы, burn-rate тренді және 30 күнге zero-reopen.
Бақылау нүктелері: 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).
Импакт: e2e-SLO 21 минут бұзылды, 3 ел қозғалды, қайтарулар/өтемақылар.
Себебі 1 (тех): карта валидаторының жаңа нұсқасы жасырындылығын 1-ге дейін ұлғайтты. 2 с → провайдерге арналған таймауттар.
2 (проц) себебі: «А» провайдері үшін canary болмады, шығарылым бірден 100% өтті.
Себебі 3 (орг): бизнес-SLI бойынша алерт-шегі нақты BIN-диапазонды (VIP-когорта) қамтымаған.
CAPA: валидатордың ескі нұсқасын қайтару; canary 1/5/25% енгізіңіз; BIN-когорттар бойынша бизнес-SLI қосу; failover туралы «B» провайдеріне 30% келісуге; «slow upstream» хаос-кейсі.

11) RCA-процестің жетілу өлшемдері

CAPA мерзімінде орындау (30 күнде жабылғандар%).
Reopen rate (90 күнде қайта ашылған оқиғалар).
Change-failure-rate дейін/кейін.
Жүйелік себептер табылған оқыс оқиғалардың үлесі (тек «адами қателік» емес).
RCA жаңа сценарийлерін тесттермен қамту.
Есепті шығару уақыты (SLA жарияланым).

12) Реттелетін домендердің ерекшеліктері (финтех/iGaming және т.б.)

Есептілік сыртқа: сезімтал бөлшектерсіз, бірақ қайталауды болдырмау жоспарымен есептің клиенттік/реттегіш нұсқалары.
Аудит-журнал және өзгермейтіндігі: артефактілерді сақтау, қол қойылған есептер, тикеттерге, CMDB, релиздік логтарға байланыстыру.
Пайдаланушылардың деректері: логтардың мысалдарында деперсоналдандыру/бүркемелеу.
Хабарлау мерзiмдерi: келiсiм-шарттар мен нормаларға байланыстыру (мысалы, бастапқы хабарламаға N сағат).

13) Қарсы үлгілер

«Вася кінәлі» - жүйелі себептерсіз адам факторына тоқтау.
Гипотезаларды тексерудің жоқтығы - интуиция бойынша қорытындылар.
Тым ортақ RCA («сервис шамадан тыс жүктелген») - нақты өзгерістерсіз.
CAPA жоқ немесе иесі/мерзімі жоқ - есеп беру үшін есеп.
Ақпаратты жасыру - сенімнің жоғалуы, ұйымды оқытудың мүмкін еместігі.
SLO/бизнес-SLI байланыссыз метриктермен қайта тиеу.

14) Құралдар мен практикалар

Метадеректері бар RCA (wiki/knowledge base) сақтау орны: сервис, SEV, себептер, CAPA, мәртебе.
Шаблондар мен боттар: оқыс оқиғадан есептің қаңқасын генерациялау (таймлайн, графиктер, релиздер).
Себеп бағаны: оқиға-себеп картасын құру (мысалы, логтар/трестер базасында).
Chaos каталогы: стейдждегі өткен оқиғаларды ойнатуға арналған сценарийлер.
Dashboards «RCA кейін»: CAPA әсерін растайтын жеке виджеттер.

15) «Жариялауға дайын» чек-парағы

• Таймлайн және артефактілер толық және тексерілді.
• Тамыр себептері тесттермен/эксперименттермен анықталған және дәлелденген.
• Түбірлі және ықпал ететін себептер бөлінген.
• CAPA иелері, мерзімдері, өлшенетін әсер өлшемдерін қамтиды.
• 14/30 күннен кейін тексеру жоспары бар.
• Сыртқы стейкхолдерлердің нұсқасы дайын (қажет болса).
• Есеп техникалық/пайыздық тексеруден өтті.

16) Жиынтық

RCA - формальдылық үшін ретроспектива емес, жүйені оқыту тетігі. Фактілер жиналған, себептері дәлелденген, ал CAPA метрикаларға тұйықталған және эксперименттермен тексерілген кезде ұйым әр жолы тұрақтырақ болады: SLO тұрақтырақ, қайталану қаупі төмен, ал пайдаланушылар мен реттеушілердің сенімі жоғары болады.