ინციდენტების მენეჯმენტი

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

ინციდენტების მართვა არის მომხმარებლის ღირებულების სწრაფი აღდგენის და ბიზნესის ზიანის შემცირების განმეორებითი პროცესი. მხარდაჭერა - მკაფიო როლები (Incident Manager, Tech Lead, Comms), SLO კარიბჭეები, ესკალაცია, ChatOps პროცესები, მომზადებული რუნები და „უვარგისი“ პოსტ-ინციდენტის ანალიზები გაზომილი მოქმედებებით.

1) მიზნები და პრინციპები

სიჩქარე და უსაფრთხოება: სწრაფი დიაგნოზი, უსაფრთხო სტაბილიზაცია და სტაბილური აღდგენა.
ერთადერთი მფლობელი: დანიშნული Incident Manager (IM) იღებს პროცესის გადაწყვეტილებებს.
კომუნიკაციები, როგორც პროდუქტი: პროგნოზირებადი განახლება სტეიკჰოლდერებისა და მომხმარებლებისთვის.
მონაცემები> მოსაზრებები: SLO/მეტრიკა/ტრეისი/ლოგოები სიმართლის წყაროა.
Blameless: მიზეზების ანალიზი პირადი ბრალდების გარეშე; ფოკუსი სისტემურ გაუმჯობესებაზე.

2) ინციდენტების კლასიფიკაცია (Severity/Impact/Urgency)

• SEV1 (კრიტიკული): შემოსავლის სერიოზული ზიანი/TTW/გადახდები,> მომხმარებელთა 20% ან მთელი რეგიონები; SLA ირღვევა/საფრთხე PII.
• SEV2 (მაღალი): საკვანძო ნაკადების ნაწილობრივი დეგრადაცია (ანაბარი/განაკვეთი/თამაშების გაშვება), 5-20% -ის გავლენა.
• SEV3 (საშუალო): მეორადი სერვისების შესამჩნევი დეგრადაცია, არსებობს შემოვლითი.
• SEV4 (დაბალი): მცირე, შეზღუდული ეფექტი, SLO/SLA- ზე გავლენის გარეშე.

Impact: ვინ იმოქმედებს (ყველა/რეგიონი/ტენანტი/არხი). Urgency: დეგრადაციის სიჩქარე (fast-burn/slow-burn შეცდომების ბიუჯეტის შესახებ).

3) ინციდენტის სასიცოცხლო ციკლი

1. Detect არის სიგნალი ალერტებისგან/SLO/სინთეზური/რეპორტი.
2. Acknowledge - on-call ადასტურებს მიღებას, დანიშნავს IM.
3. Triage - SEV/Impact- ის შეფასება, ჰიპოთეზების შეგროვება, ომის ოთახის გახსნა.
4. Mitigate - სტაბილიზაცია (მარშრუტის დაბრუნება/გადართვა/ფიჩეფლაგები/სკალირება).
5. Communicate - რეგულარული სტატუსის განახლება (შიგნით/გარეთ).
6. Recover არის SLO/ბიზნეს მეტრიკის სრული აღდგენა.
7. Close - ქრონოლოგიის დაფიქსირება, არტეფაქტების შეგროვება, PIR (RCA + მოქმედება items).

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

Incident Manager (IM) - პროცესის მფლობელი, დანიშნავს როლებს, აკონტროლებს დროს, იღებს პროცესის გადაწყვეტილებებს (R).
ტექნიკური Lead (TL) - აწარმოებს დიაგნოზირებას/ჰიპოთეზებს/ფიქსიებს, კოორდინაციას უწევს ინჟინრებს (A/R).
კომუნიკაციები (Comms) - სტატუსის გაფართოება, მხარდაჭერა/ბიზნესი/PR, სტატუსის გვერდი (R).
Scribe - პროტოკოლი (მიღებული გადაწყვეტილებები, ბმულები, არტეფაქტები) (R).
Stakeholders - პროდუქტი/გადახდა/თამაშის პროვაიდერები/უსაფრთხოება (C/I).

მინიმუმ SEV1: IM + TL + Comms + Scribe. SEV2- ზე ნებადართულია როლების კომბინაცია.

5) War-Room и ChatOps

ცალკეული არხები: '# incident-warroom- <id>' (სამუშაო), '# incident-status' (მხოლოდ აფთიაქები).
შაბლონის ბრძანებები: '/incident start ', '/status განახლება', '/call <owner> ', '/rollback', '/freeze ', '/scale + N'.
Bot ზრდის კონტექსტს: უახლესი გამოშვებები, დაშბორდები, რომლებიც დაკავშირებულია ალერტებთან, trace exemplars, დამოკიდებულების სქემები.
კომუნიკაციის წესები: მოკლედ, ფაქტების თანახმად, ერთი სპიკერი (TL), IM ქმნის.

6) ტრიგერები და კარიბჭეები

SLO კარიბჭეები: fast/slow burn, გადახდის კონვერტაციის ვარდნა, TTW p95> ბარიერი, p99 API, გადახდების ხაზები „იწვის“.
ავტომობილების მოქმედება: stop canary, rollback, degrade რეჟიმში ჩართვა (ფუნქციების შეზღუდვა), მაღალი სიხშირის სინთეზის ჩართვა.
უფასო: გაჩერებების ყველა გამოშვება/მიგრაცია სტაბილიზაციამდე და PIR.

7) ტიპიური სკრიპტები (რუნაბუკის ნიმუშები)

ა) გადახდა: PSP- ის ტაიმაუტის/წარუმატებლობის ზრდა

1. Stop promote და გადახდის მიკროსქემის გამოშვებების გაყინვა.
2. გადართეთ PSP მარშრუტი სარეზერვო, გაზარდეთ ტაიმუთი/რეტრაი პოლიტიკაში.
3. დაუმთავრებელი გარიგების შერწყმა, გამეორება იდემპოტენტური კლავიშებით.
4. კომუნიკაცია Comms - sapport: მუშაობთ რეზერვი? ETA.

B) API p99 და 5xx გამოშვების შემდეგ

1. გამოტოვება (ცისფერი-მწვანე/ბანაკი).
2. შეამოწმეთ ქეშის ჰიტები, რიგების სიღრმე, BD/თამაშების პროვაიდერების ცხელი წერტილები.
3. დროებითი სკალირება, მძიმე შეცდომების შეზღუდვა feature flags- ის საშუალებით.

C) თამაშების მიმწოდებელი მიუწვდომელია

1. გადაიტანეთ ტრეფიკი ხელმისაწვდომი სტუდიებში/თამაშებში, აჩვენეთ სტატუსის ბანერი.
2. ჩართეთ სინთეზური შემოწმებები ყოველ 30-60s.
3. კომპენსაციის/პრემიების (პოლიტიკის) კოორდინაცია - PIR- ის წარდგენა.

დ) გაჟონვა/PII ეჭვი

1. კომპონენტების იზოლაცია, გასაღების/ტოქსინების გადაკეთება, ლოგების შეგროვება (WORM).
2. იურიდიული კომუნიკაციის კოორდინაცია/მარეგულირებლები.
3. პოსტ-ინციდენტის მოქმედებები: საიდუმლო როტაცია, შენიღბვა, წვდომა.

8) კომუნიკაციები (შიდა/გარე)

Apdates- ის სიხშირე: SEV1 - ყოველ 15-30 წუთში, SEV2 - 30-60 წთ.

• რა არის გატეხილი: „დეპოზიტები PSP-X- ით: ტაიმუთის ზრდა.“
• ვის შეეხო: „TR/BR, ნაკადის მომხმარებელთა 18%.“
• როდესაც დაიწყო: „12:07 EET, SEV1.“
• რას ვაკეთებთ: „ჩვენ გადავხედავთ მარშრუტს PSP-Y- ზე, ჩართულია რელეები/განაკვეთის შეზღუდვა.“
• შემდეგი განახლება: „20 წუთის შემდეგ.“
• კონტაქტი: „IM @ duty-im, TL @ oncall-გადახდა.“

საჯარო სტატუსი (გვერდი/სოციალური ქსელები) - შემცირებული, PII და დამატებითი დეტალების გარეშე, ETA- სთან და შემდგომი განახლებების მითითებით.

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

მოვლენების დრო (წუთიერი სიზუსტე), სერვისების ვერსიები, წინა დროშები, კონფიგურაციის ცვლილებები.
დაშბორდის სურათები, სავარაუდო მარშრუტები (trace _ id), ლოგოები „დროზე/მის შემდეგ“.
ბმულები ტიკეტებზე, PR, გამოშვებები, რუნები.
კომუნიკაციების ანგარიში (როდის/კომა/რა).
ყველაფერი ხდება ინციდენტის ბარათში.

10) დახურვა და PIR (Post-Incident Review)

• რეზიუმე: რა მოხდა, მასშტაბები, ხანგრძლივობა, SEV.
• გავლენა: მომხმარებლები/რეგიონები, SLO/SLA, ფინი. ეფექტი.
• დრო: დეტალურად, წუთში.
• Root Cause: ტექნიკური + ორგანიზაციული (რატომ ადრე არ იყო გამოყენებული).
• Detections & Defenses: რამაც ხელი შეუწყო/ვერ შეძლო (ალერტები, სინთეზური, ფიჩეფლაგები).
• Action Items: კონკრეტული დავალებები, მფლობელები, ვადები (და როგორ შევამოწმოთ ეფექტი).
• Lessons Learned: რა ვცვლით პროცესს/არქიტექტურას/დაკვირვებას.

წესები: ბრალდების გარეშე, მაქსიმალური ფაქტები, სავალდებულო follow-up შესრულებული პუნქტების გადამოწმების 2-4 კვირის შემდეგ.

11) პროცესის საიმედოობის მეტრიკა

MTTD (Mean Time To Detect) - საშუალო აღმოჩენის დრო.
MTTA (… Acknowledge) - სანამ დადასტურდება on-call.
MTTR (… Restore) - SLO- ს აღდგენამდე.
Change Failure Rate - ინციდენტამდე მიმავალი გამოშვების%.
Incident Rate of SEV, განაწილება დომენებზე (Payments/Games/Infra).
Alert Quality: ხმაურიანი/ყალბი წილი, ალერტის შემდეგ მოქმედების დრო.
Comm-SLA: სტატუს აფდიტების სიხშირის დაცვა.

12) ინტეგრაცია SLO- სთან და გამოშვებებით

კარიბჭეები CD- ში: კანარის დამზადება მხოლოდ მწვანე SLO მარიონეტებით (availability, p95, conv, TTW).
უფასო პროცედურები: სწრაფი ბურნი/SEV1 - გაჩერება PIR- მდე.
ავტო-სურათები გრაფიკებში: გამოშვებები/დროშები/მიგრაცია ჩანს დაშბორდში.

13) მარეგულირებელი და შესაბამისობა

PII: შენიღბვა/ფსევდონიმი ლოგებში/ტრეისებში, WORM აუდიტის საცავებში, წვდომის კონტროლი.
რეგიონალურობა: არ გადაიტანოთ მომხმარებლის მონაცემები ნებადართული იურისდიქციების მიღმა.
მოხსენებები: რეგულატორებისთვის ოფიციალური წერილები/შეტყობინებები - შაბლონები და ესკალაციის პროცესი.

14) მომზადება და მზადყოფნა (თამაშის დღე)

კვარტალური სავარჯიშოები: „PSP დაცემა“, „თამაშების პროვაიდერი მიუწვდომელია“, „p99 სიჩქარე“, „გასაღების გაჟონვა“.
ტაიმერები MTTA/MTTR- ზე, რეტრო ვარჯიშებში.
რუნაბუკებისა და კონტაქტების განახლება, ChatOps გუნდების შემოწმება.

15) მზადყოფნის სია (ინციდენტამდე)

1. შეთანხმებულია SEV წესები და ესკალაციის მატრიცა.
2. დანიშნულია rotation, IM/TL/Comms/Scribe.
3. მთავარი სცენარების რუნები (გადასახადები, თამაშები, BD, ქეში, რიგები).
4. SLO ბარათი და burn-rate ალერტა, სტატუსის გვერდი.
5. ChatOps bot: გუნდები, ავტო კონტექსტი, სტატუსის შაბლონები.
6. PIR შაბლონები და ინციდენტის ბარათები.
7. რეგულარული თამაშის დღე და კონტაქტების/უფლებების გადასინჯვა.
8. უფასო პოლიტიკა და „წითელი ღილაკი“ (rollback/kill-switch).

16) ანტიპატერები

არ არსებობს ერთი IM, „ხალხი ლიდერობს“ ქაოსი და შეფერხებები.
SLO კარიბჭეების არარსებობა - გვიან გამოვლენა, ხმაურიანი ალერტები.
გამოშვება ინციდენტის დროს freeze გარეშე არის კასკადის გაუმართაობა.
ლოგოები და ტრეისი საკმარისი არ არის, არ არსებობს არტეფაქტები, სუსტი PIR.
საბრალდებო კულტურა - ფარული შეცდომები, ესკალაციის შიში.
კომუნიკაციები „შთაგონებით“ არის ბიზნესის/მომხმარებლების ნდობის დაკარგვა.

17) შაბლონები (კოპირება თქვენს ვიკში)

ა) ინციდენტის ბარათი (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) სტატუსის განახლება (შიდა)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (ქუდი)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

შედეგები

ინციდენტების ძლიერი მართვა არის + დისციპლინის სტრუქტურა: წინასწარ შეთანხმებული როლები, SLO კარიბჭეები, შემუშავებული რუნები, გამჭვირვალე კომუნიკაციები და „უვარგისი“ PIR. ასეთი წრე ამცირებს MTTA/MTTR- ს, ამცირებს ხარჯების ღირებულებას, აძლიერებს მომხმარებელთა ნდობას და საშუალებას გაძლევთ გაათავისუფლოთ უფრო გაბედული - მაგრამ უსაფრთხოდ.