პოსტ-ინციდენტის ანალიზი

1) რატომ გვჭირდება პოსტ-ინციდენტის ანალიზი

პოსტ-ინციდენტის ანალიზი (post-mortem/AAR) არის ორგანიზაციის სტრუქტურირებული სასწავლო პროცესი მარცხის შემდეგ. მიზანია არა დამნაშავეების ძებნა, არამედ ფესვთა და წახალისების მიზეზების დადგენა და გაზომილი მოქმედებების (CAPA) კონსოლიდაცია, რაც ამცირებს ინციდენტების განმეორების რისკს და ღირებულებას, SLO, MTTR და მომხმარებელთა/რეგულატორების ნდობას.

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

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

3) როდის დაიწყეთ ანალიზი და რა ფორმატებია

სავალდებულო: SEV-0/1; SLA/მარეგულირებელი მოთხოვნების დარღვევა; მონაცემთა გაჟონვა; მნიშვნელოვანი PR რისკი.
დაჩქარებული (მსუბუქი): SEV-2 შესამჩნევი გავლენით ან განმეორებითი სიმპტომებით.
საკომუნიკაციო AAR: თუ მარცხი შეეხო სტატუსის გვერდს/მხარდაჭერას, ჩვენ ვამოწმებთ SLAS აფთიაქებს და შეტყობინებების ხარისხს.

ვადები: პროექტი 48-72 საათში, საბოლოო ვერსია - 5 სამუშაო დღემდე (თუ სხვაგვარად არ არის შეთანხმებული).

4) როლები და პასუხისმგებლობა

ანალიზის მფლობელი (RCA Lead): ორგანიზებას უწევს პროცესს, ატარებს შეხვედრას, პასუხისმგებელია მოხსენების ხარისხზე და CAPA.
Incident Commander (IC): უზრუნველყოფს ინციდენტისა და გადაწყვეტილების ფაქტოლოგიას.
Tech Leads (სისტემების მიხედვით): არტეფაქტების დამადასტურებელი მიზეზების ანალიზი.
Comms/Suport/Legal: კომუნიკაციების შეფასება და შესაბამისობის მოთხოვნები.
Scribe: ოქმი, მტკიცებულებების შეგროვება, სტრუქტურების დაცვა.
პროდუქტის/ბიზნესის Steikholders: გავლენა მომხმარებლებზე/ბრუნვაზე, CAPA- ს პრიორიტეტი.

5) მომზადება: რა უნდა შევიკრიბოთ შეხვედრამდე

Timline (UTC): T0 გამოვლენა Tn- ის აღდგენისთვის; გამოშვებები/ფიგურების დროშები/კონფისკაციები, პროვაიდერების სტატუსი.
დაკვირვების მონაცემები: SLI/SLO გრაფიკა, error-rate, დაფასდა, ლოგოები, ტრეკები, ეკრანის კადრები.
ცვლილებების კონტექსტი: ბმულები PR/deple, BD- ის მიგრაცია, წინა დროშები, სამუშაო გეგმები.
იმპორტი: დაზარალებული კოჰორტები/რეგიონები/პროვაიდერები, წუთიერი დგომა, სესხები SLA- სთვის.
კომუნიკაციები: მონახაზები/შეტყობინებები სტატუსის გვერდზე, საპორტო პასუხები, შიდა განცხადებები.
პოლიტიკოსები/ფლეიბუკები: რა უნდა მომხდარიყო იმ პროცესში, სადაც გადახრები იყო.

6) ანალიზის მეთოდები (შეარჩიეთ კომბინაცია)

5 რატომ: მიზეზობრივი ჯაჭვის სწრაფი გახსნა (რისკი - გადაჭარბებული გამარტივება).
Ishikawa დიაგრამა: People/Process/Platform/Policy/Partner/Product.
Fault Tree Analysis (FTA): ბაბუა მოვლენიდან მრავალი მიზეზის გამო (AND/OR).
Change Analysis: რა შეიცვალა სტაბილური მდგომარეობა ინციდენტის დროს.
Causal Graph: მიზეზობრივი კავშირების გრაფიკი რთული მიკრო სერვისებისა და გარე დამოკიდებულებისთვის.
Human Factors Review: დაღლილობა, ინფორმაციის ხმაური, არააქტიური runbook '.

7) ანგარიშის სტრუქტურა (შაბლონი)

1. რეზიუმე: რა, როდის, ვისზე იმოქმედა საბოლოო სტატუსმა.
2. იმპორტი: SLI/SLO, მომხმარებლები, რეგიონები/პროვაიდერები, წუთები, ფინანსური/მარეგულირებელი ეფექტები.
3. Timline (UTC): ძირითადი მოვლენები, გამოშვებები, IC გადაწყვეტილებები, კომუნიკაციები.
4. დაკვირვებები და მონაცემები: გრაფიკა, ლოგოები, ტრეისი, კონფიგურაციის/სქემების დიფები.
5. ჰიპოთეზები და შემოწმებები: მიღებული/უარყოფა, ექსპერიმენტების/სიმულაციების ბმულები.
6. ფესვის მიზეზები: სისტემური/პროცესორი/ტექნიკური (მკაფიო ფორმულირება).
7. წახალისების ფაქტორები: რატომ არ შეამჩნია/ადრე არ შეჩერებულა.
8. რა მუშაობდა/რა არ მუშაობდა: პროცესები, ინსტრუმენტები, ხალხი.
9. CAPA: მაკორექტირებელი და გამაფრთხილებელი ზომები წარმატების მფლობელებთან/ვადებთან/მეტრიკებთან.
10. გადამოწმების გეგმა: საკონტროლო წერტილები D + 14/D + 30, დახურვის კრიტერიუმები.
11. ვერსიები გარე მხარისთვის: კლიენტი/მარეგულირებელი (მგრძნობიარე მონაცემების გარეშე).
12. პროგრამები: არტეფაქტები, ბმულები თიკეტებზე/PR, დაშბორდის ეკრანის კადრები.

8) CAPA: როგორ მოვიქცეთ მუშები

თითოეულ მოქმედებას აქვს მეპატრონე, ვადა და KPI ეფექტი (მაგალითად, change-failure-rate- ის შემცირება X% -ით, ნულოვანი გამეორება 90 დღის განმავლობაში, მწვერვალების შემცირება).
გამოყავით Corrective (გამოსწორება) და Preventive (თავიდან აიცილეთ) ზომები.
მიბმული პოლიცია-as-code: ალერტები, SLO კარიბჭეები, skate/limites, GitOps.
CAPA შედის საჯარო დისკზე მიმოხილვებით ყოველკვირეულ ოპერაციულ შეხვედრებზე.

9) ეფექტის შემოწმება და დახურვა

საკონტროლო წერტილები: D + 7 (შუალედური), D + 14/D + 30 (ძირითადი), D + 90 (შედეგი).
გადამოწმება: ტესტები/სიმულაციები, shadow ტრაფიკი, დაკვირვება (სტაბილური SLI მწვანე ზონაში), რეციდივების არარსებობა.
დახურვა შესაძლებელია მხოლოდ CAPA- ს მიერ შესრულებული და დადასტურებული მეტრიკებით.

10) კომუნიკაციები და შესაბამისობა

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

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

ანგარიშის გამოქვეყნების დრო: vs SLA ფაქტი (მაგალითად, 5 სამუშაო დღე).
CAPA Completion: დროულად დახურული მოქმედებების%.
Reopen rate: განმეორებითი ინციდენტების წილი 90 დღეში.
სისტემური მიზეზების წილი არის „ადამიანის შეცდომა“.
ალერტის ჰიგიენა: ყალბი პეიჯების დაქვეითება, ალერტების მიერ დაფარული runbook- ის ზრდა.
DORA მეტრიკის ცვლილება: MTTR, change-failure-rate დაწყებამდე.

12) ჩეკის ფურცლები

ანალიზის დაწყებამდე

• განსაზღვრულია RCA- ს მფლობელი და მონაწილეთა შემადგენლობა.
• შეგროვდა დრო და ნივთები (ლოგოები/გრაფიკები/გამოშვებები/დროშები).
• შეაფასეს გავლენა კოჰორტების/რეგიონის/პროვაიდერების შესახებ.
• მომზადებულია Impact და Timline სექციების პროექტი.
• შესაბამისი პოლიტიკოსები/ფლეიბუკები შედარებულია ფაქტობრივ ქმედებებთან.

დროს

• დაფიქსირდა მიღებული/უარყოფითი ჰიპოთეზები და საფუძვლები.
• განისაზღვრება ფესვთა და წახალისების მიზეზები.
• შეიქმნა CAPA გეგმა KPI- ით და ვადებით.
• შეთანხმებულია გარე მხარეების მოხსენების ვერსიები (საჭიროების შემთხვევაში).

შემდეგ

• ანგარიში ქვეყნდება დროულად, როლებზე წვდომა.
• CAPA ჩამოთვლილია baclog- ში, მეპატრონეები დადასტურებულია.
• დაგეგმილია საკონტროლო წერტილები და მინი სიმულაცია გადამოწმებისთვის.
• განახლებულია runbook/SOP/ალერტები/დოკუმენტაცია.

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

„X კაცი დამნაშავეა“ - სისტემური მიზეზების გარეშე - განმეორება.
ანგარიში CAPA- ს გარეშე ან მფლობელების/ვადების გარეშე - ქაღალდი ქაღალდისთვის.
არ არსებობს ფაქტები/არტეფაქტები - დასკვნები გრძნობებზე.
ძალიან ზოგადი ენა („BD გადატვირთვა“) კონკრეტული ცვლილებების გარეშე.
კომუნიკაციებისა და შესაბამისობის უგულებელყოფა რეპუტაციის რისკია.
ეფექტების შემოწმების გარეშე დახურვა - რეციდივები ერთი კვირის შემდეგ.

14) მინი შაბლონები

მოხსენების ქუდი

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

ფესვის მიზეზის ფორმულირება (მაგალითი)

CAPA (ფრაგმენტი)

ჩართეთ canary მარშრუტიზაცია PSP-A- სთვის (1%, 5%, 25%), მფლობელი: @ payments-tl, მდე: 2025-11-07, KPI: ნულოვანი P1 ინციდენტები პროვაიდერების გამოშვებისას 30 დღის განმავლობაში.
ხელახლა შეაკეთეთ Taimauts/retrai საერთო დროით SLA 800 ms, მფლობელი: @ platform-sre, მდე: 2025-11-05, KPI: p99 <600 ms N- ის დატვირთვის ქვეშ.
დაამატეთ ბიზნეს SLI BIN კოჰორტებზე, მეპატრონე: @ data-lead, მდე: 2025-11-10, KPI: დეგრადაციის გამოვლენა <5 წთ.

15) ყოველდღიური პრაქტიკა

ყოველკვირეული RCA მიმოხილვა: CAPA სტატუსი, ახალი გაკვეთილები, პროცესების განახლება.
პოსტ-mortems კატალოგი wiki- ში ჭდეებით (მომსახურება, SEV, მიზეზები) და ძებნა.
2-4 კვირის შემდეგ მომხდარი ინციდენტის საფუძველზე მიღებული სიმულაციები ზომების შესამოწმებლად.
გაკვეთილების ჩართვა ონბორდინგში და სასწავლო სცენარების განახლება.

16) შედეგი

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