Root Cause Analysis

1) რა არის RCA და რატომ არის ეს საჭირო

Root Cause Analysis არის სტრუქტურირებული პროცესი ინციდენტის ფესვების იდენტიფიცირებისთვის, განმეორების აღმოფხვრის მიზნით. ცენტრში - ფაქტები, მიზეზობრივი კავშირები და სისტემური გაუმჯობესება (პროცესები, არქიტექტურა, ტესტები), და არა დამნაშავეების ძებნა.
მიზნები: რეციდივის თავიდან აცილება, MTTR/ინციდენტების სიხშირის შემცირება, SLO- ს გაუმჯობესება, რეგულატორებისა და პარტნიორების ნდობის გაძლიერება.

2) პრინციპები

ბრალდების გარეშე. ჩვენ ვსჯით არა ხალხს, არამედ სარისკო პრაქტიკას.
ტექსტოლოგიური კეთილდღეობა. მხოლოდ შემოწმებული მონაცემები და ნივთები.
E2E სახე. კლიენტიდან ზურგჩანთამდე და პროვაიდერებამდე.
ჰიპოთეზის შემოწმება. ნებისმიერი განცხადება - ტესტით/ექსპერიმენტით.
CAPA დახურვა. მაკორექტირებელი და გამაფრთხილებელი ზომები მფლობელებთან და ვადებთან.

3) შესასვლელი ნივთები და მომზადება

Timline UTC: T0 გამოავლინა T + მოქმედება T + აღდგენა.
დაკვირვების მონაცემები: ლოგოები, მეტრიკები (მათ შორის კოჰორტების ჩათვლით), ტრეისი, სინთეზური, სტატუსის გვერდი.
ცვლილებები: გამოშვებები, ფიგურების დროშები, კონფიგურაცია, პროვაიდერის მოვლენები.
გარემო: ვერსიები, არტეფაქტების ჰაში, SBOM, ინფრასტრუქტურული ეტიკეტები.
ინციდენტის ბაზა: იმპაქტის აღწერა (SLO/SLA, კლიენტები, ბრუნვა), მიღებული გადაწყვეტილებები, სამუშაო შეხვედრები.
ადრეულ ასაკში: ვინ და როდის შეაგროვა/შეცვალა მტკიცებულებები (კომპლენსისთვის მნიშვნელოვანია).

4) RCA ტექნიკა: როდის

1. 5 რატომ უნდა გავარკვიოთ ვიწრო პრობლემების გამომწვევი ჯაჭვი. რისკი: რთული სისტემის „შემცირება“ ხაზამდე.
2. Ishikawa დიაგრამა (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 რატომ საკვანძო ფილიალებში.

5) RCA ეტაპობრივი პროცესი

1. წამოიწყეთ: დანიშნეთ RCA მეპატრონე, განსაზღვრეთ ანგარიშის გამოშვების თარიღი (მაგალითად, 5 სამუშაო დღე), შეაგროვეთ გუნდი (IC, TL, Scribe, პროვაიდერების წარმომადგენლები).
2. შეაგროვეთ ფაქტები: დრო, გრაფიკა, გამოშვებები, ლოგოები, არტეფაქტები; ჩაწერეთ ვერსიები და თანხების კონტროლი.
3. მოქმედებების კარნახით: რა SLI/SLO დაზარალდა რომელი კოჰორტები (ქვეყნები, პროვაიდერები, VIP).
4. ჰიპოთეზების შექმნა: პირველადი, ალტერნატიული; რა შემოწმებულია ახლა.
5. ჰიპოთეზების გადამოწმება: stage/simulation/canareike რეპროდუქცია, ტრეისების ანალიზი, fault injection.
6. განსაზღვრეთ ფესვი და წახალისების მიზეზები: ტექნოლოგიური, პროცესორი, ორგანიზაციული.
7. CAPA- ს შექმნა: კორექტირება (გამოსწორება) და გამაფრთხილებელი (თავიდან აცილება); წარმატების მეტრიკა და დრო.
8. ანგარიშის კოორდინაცია და გამოქვეყნება: ცოდნის შიდა ბაზა +, საჭიროების შემთხვევაში, მომხმარებლების/რეგულატორის გარე ვერსია.
9. ეფექტის გადამოწმება: საკონტროლო წერტილები 14/30 დღეში; მოქმედების დახურვა.

6) რა არის „ფესვის მიზეზი“

• სუსტი ტესტები/ფიგურების დროშები, დაკარგული ლიმიტები/ალერტები, ორაზროვანი დოკუმენტაცია, არასწორი ნაგულისხმევი, მყიფე არქიტექტურა.
• ხშირად ეს არის ფაქტორების ერთობლიობა (კონფიგურაცია × კარიბჭის არარსებობა × პროვაიდერი).

7) CAPA: მაკორექტირებელი და გამაფრთხილებელი ზომები

• კოდის/ჩამორთმევის ფიქსი, ნიმუშის დაბრუნება, ლიმიტის/ტაიმაუტის შეცვლა, ინდექსების დამატება, რეპლიკა/შარდინგი, ტრეფიკის ხელახალი გადაცემა, სერთიფიკატების განახლება.

• ტესტები (საკონტრაქტო, ქაოსი-შემთხვევები), ალერტები (ბურნი, სინთეზური კვორუმი), განთავისუფლების პოლიტიკა (canary/blue-green), GitOps კონფისკაციისთვის, ტრენინგი/ჩეკების სიები, პროვაიდერის დუბლირება, DR სწავლებები.

თითოეული მოქმედება: მეპატრონე, ვადა, მოსალოდნელი ეფექტი, გადამოწმების მეტრიკა (მაგალითად, change-failure-rate- ის შემცირება X% -ით, განმეორების არარსებობა 90 დღის განმავლობაში).

8) ჰიპოთეზებისა და ეფექტების გადამოწმება

ექსპერიმენტები: fult injection/chaos, shadow ტრაფიკი, A/B ჩამორთმევა, დატვირთვა რეალურ პროფილებთან.
წარმატების მეტრიკა: SLO- ს აღდგენა, p95/p99 სტაბილიზაცია, error-rate- ის ადიდების არარსებობა, MTTR- ის აბრევიატურა, burn-rate ტენდენცია და zero-reopen 30 დღის განმავლობაში.
საკონტროლო წერტილები: D + 7, D + 30, D + 90 - CAPA და გავლენის გადახედვა.

9) RCA ანგარიშის შაბლონი (შიდა)

1. მოკლე რეზიუმე: რა მოხდა, როდესაც დაზარალდა.
2. იმპორტი: SLI/SLO, მომხმარებლები, რეგიონები, ბრუნვა/ჯარიმები (თუ არსებობს).
3. Timline (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 (პროცენტი): პროვაიდერი „A“ - სთვის არ არსებობდა, გამოშვება დაუყოვნებლივ მოხდა 100% -ით.
მიზეზი 3 (org): ალერტის ბარიერი ბიზნეს SLI- ში არ მოიცავდა კონკრეტულ BIN დიაპაზონს (VIP კოჰორტს).
CAPA: დაუბრუნეთ მოქმედი ძველი ვერსია; შემოიღეთ canary 1/5/25%; დაამატეთ ბიზნეს SLI BIN კოჰორტებზე; შეთანხმდნენ 30% failover- ზე პროვაიდერზე „B“; ქაოსის შემთხვევა „slow upstream“.

11) RCA პროცესის სიმწიფის მეტრიკა

CAPA- ს განხორციელება დროულად (% დახურულია 30 დღეში).
Reopen rate (ინციდენტები, რომლებიც ხელახლა გაიხსნა 90 დღეში).
Change-failure-rate მდე/შემდეგ.
ინციდენტების წილი, სადაც ნაპოვნია სისტემური მიზეზები (და არა მხოლოდ „ადამიანის შეცდომა“).
RCA- ს ახალი სკრიპტების ტესტების დაფარვა.
ანგარიშის გამოშვების დრო (SLA პუბლიკაცია).

12) რეგულირებული დომენების მახასიათებლები (fintech/iGaming და ა.შ.)

მოხსენებები გარედან: ანგარიშის კლიენტის/მარეგულირებელი ვერსიები მგრძნობიარე დეტალების გარეშე, მაგრამ გამეორების თავიდან აცილების გეგმით.
აუდიტის ჟურნალი და უცვლელი: არტეფაქტების შენახვა, ხელმოწერილი მოხსენებები, თიკეტებთან დაკავშირება, CMDB, გამოშვებული ლოგოები.
მომხმარებლის მონაცემები: დეპერსონალიზაცია/შენიღბვა ლოგოების მაგალითებში.
შეტყობინებების დრო: დააკავშიროთ ხელშეკრულებები და სტანდარტები (მაგალითად, N საათი პირველადი შეტყობინებისთვის).

13) ანტი შაბლონები

„ვასია დამნაშავეა“ - გაჩერება ადამიანის ფაქტორზე სისტემური მიზეზების გარეშე.
ჰიპოთეზის შემოწმების არარსებობა არის დასკვნები ინტუიციაზე.
ძალიან ზოგადი RCA („მომსახურება გადატვირთული იყო“) - კონკრეტული ცვლილებების გარეშე.
არ არსებობს CAPA ან არ არსებობს მფლობელები/ვადები - მოხსენება მოხსენებისთვის.
ინფორმაციის დამალვა - ნდობის დაკარგვა, ორგანიზაციის სწავლების შეუძლებლობა.
გადატვირთულია მეტრიკებით SLO/business SLI- სთან ერთად.

14) ინსტრუმენტები და პრაქტიკა

RCA საცავი (wiki/knowledge base) მეტამონაცემებით: მომსახურება, SEV, მიზეზები, CAPA, სტატუსი.
შაბლონები და ბოტები: ინციდენტიდან მოხსენების ჩარჩოს წარმოქმნა (დრო, გრაფიკა, გამოშვებები).
მიზეზის გრაფიკი: ღონისძიების მიზეზობრივი რუქის მშენებლობა (მაგალითად, ლოგოების/ტრეისების საფუძველზე).
Chaos კატალოგი: სკრიპტები წარსული ინციდენტების რეპროდუქციისთვის.
Dashboards „RCA- ს შემდეგ“: ცალკეული ვიჯეტები, რაც დასტურდება CAPA- ს ეფექტით.

15) ჩეკის სია „მზად არის გამოსაცემად“

• დრო და ნივთები სავსეა და გადამოწმებულია.
• ფესვის მიზეზები განისაზღვრება და დადასტურებულია ტესტებით/ექსპერიმენტებით.

ფესვთა და წახალისების მიზეზები იყოფა.

• CAPA შეიცავს მფლობელებს, ვადებს, ეფექტის გაზომილ მეტრებს.
• გადამოწმების გეგმა არსებობს 14/30 დღეში.
• გარე სტეიკჰოლდერების ვერსია მომზადებულია (საჭიროების შემთხვევაში).
• ანგარიში გაიარა ამ/პროცენტით.

16) შედეგი

RCA არ არის რეტროსპექტივა ფორმალობის გულისთვის, არამედ სისტემის სწავლების მექანიზმი. როდესაც ფაქტები შეგროვებულია, დადასტურებულია მიზეზი, ხოლო CAPA დახურულია მეტრიკებით და ექსპერიმენტებით არის შემოწმებული, ორგანიზაცია ყოველ ჯერზე სტაბილური ხდება: SLO უფრო სტაბილურია, რეციდივების რისკი უფრო დაბალია, ხოლო მომხმარებლებისა და რეგულატორების ნდობა უფრო მაღალია.