ინციდენტების სიმულაცია

1) რატომ უნდა ჩავატაროთ სიმულაციები?

• შეამცირეთ MTTD/MTTA/MTTR, გაზარდეთ დაბრუნების ნდობა და ფეილოვერები;
• გამოავლინეთ უფსკრული პროცესებში (ესკალაცია, კომუნიკაცია) და არქიტექტურული სისუსტეები;
• ისინი ემსახურებიან RCA-CAPA- ს შესასვლელს და აუმჯობესებენ დოკუმენტაციას (runbook/SOP);
• დადასტურებულია მზადყოფნა SLA/რეგულატორების/აუდიტის მოთხოვნებისთვის.

2) სიმულაციის ფორმატები

Tabletop (მაგიდა) - კოლოქური სცენარი დაფაზე/ჩეთში: იაფი, სწრაფი, შესანიშნავი როლებისა და კომუნიკაციების შესაქმნელად.
Game Day (სავარჯიშოები staje/გაყიდვაში შეზღუდვებით) - პრაქტიკული ნაბიჯები playbucks; გაყიდვაში - მხოლოდ უსაფრთხო, შექცევადი მოქმედებები მკაფიო კარიბჭეებით.
Chaos Engineering - კონტროლირებადი გაუმართაობა (დამოკიდებულების/ქსელის/კვანძების გათიშვა) სტაბილურობის შესამოწმებლად და SLO კარიბჭეების შესამოწმებლად.
DR წვრთნები (Disaster Recovery) - AZ/რეგიონის უკმარისობა, ზურგჩანთების აღდგენა, პროვაიდერების გადართვა.
Comms-drill არის წმინდა კომუნიკაცია: სტატუსის გვერდი, შეტყობინებების შაბლონები, PR/Legal.

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

Incident Commander (IC) - იღებს გადაწყვეტილებებს, აწარმოებს გეგმას, დეესკალაციას.
Tech Lead (TL) - დიაგნოზი, ტექნიკური „ინჟექტები“ და ჰიპოთეზები.
Comms Lead (CL) - შიდა/გარე აპდეიტები, სტატუსის გვერდი.
Scribe - პროტოკოლი (დრო, მოქმედებები, გადაწყვეტილებები, არტეფაქტები).
Observers/Assessors - ფიქსირდება მეტრიკა და პროცედურების შესაბამისობა.
წითელი გუნდი (სურვილისამებრ) - შემოაქვს გაუთვალისწინებელი „ინჟექტები“.

4) სიმულაციების წარმატების მეტრიკა

MTTD/MTTA/MTTR სინთეზური ინციდენტისთვის.
Comm SLA: Apdates- ის დროული და ხარისხი.
SLO-guardrails: სწორი რეაქცია burn-rate- ზე, გარე ნიმუშების კვორუმი.
Runbook fidelity:% ნაბიჯი გადადგა დოკუმენტის შესაბამისად, იმპროვიზაციის გარეშე.
Escalation latence: სწორი როლის/პროვაიდერის დაკავშირების სიჩქარე.
Checklists pass-rate: შესაბამისობა „მზად/მიღება/დახურვა“.
Noise & Fatigue: დამატებითი ალერტები, გადატვირთვა on-call.
CAPA completion: სიმულაციის შემდეგ შესრულებული მოქმედებების წილი.

5) მომზადება: რა არის საჭირო დაწყებამდე

მიზანი და ჰიპოთეზა: რას ვამოწმებთ (პროცესები, არქიტექტურა, ხალხი).
სცენარი და „ინჟექტები“: სიმპტომების/მოვლენების თანმიმდევრობა ტაიმინგებით.
უსაფრთხოების შეზღუდვები: შეუქცევადი ცვლილებების აკრძალვა; გაუქმების წერტილები.
მონაცემები და სტენდები: სინთეზური ტრაფიკი, დეგრადაციის დროშები, უსაფრთხო გასაღებები.
დოკუმენტები: ბმულები runbook/SOP, ესკალაცია, პროვაიდერების საკონტაქტო სია.
დაკვირვება: წინასწარ აღინიშნა დაშბორდები/ალერტები, ტესტის კანარები.
ლოჯისტიკა: დრო/ხანგრძლივობა, მონაწილეები, ომის ოთახი არხი, ჩანაწერი.

6) სიმულაციის ჩატარება: ეტაპები

1. Brief (5-10 წუთი): IC ჰგავს მიზნებს, როლებს, უსაფრთხოების წესებს, დასრულების კრიტერიუმებს.
2. T0 - სიმპტომების ინჟექტორი: ალერტი (y), ბიზნეს SLI ვარდნა, პროვაიდერის გარე სტატუსი.
3. სამჯერ და ესკალაცია: SEV მითვისება, გამოშვებების უფასო, სწორი როლების დაკავშირება.
4. დიაგნოზი: ჰიპოთეზები, DNS/TLS/CDN/BD/Cash/Bashines, გამოშვების მენიუ.
5. მიტინგების მოქმედებები: გამოტოვება/კანარი, დეგრადაციის ფიკა-დროშები, მომწოდებლის მომწოდებელი, შეზღუდვები/რეტრაილები.
6. კომუნიკაციები: რეგულარული აპდეიტები (ფორმატი: იმპორტი - დიაგნოზი - მოქმედებები - კვალი. აპდეიტი).
7. აღდგენა და გადამოწმება: გარე სინთეტიკა + SLI ინტერვალების მწვანე ზონაში N.
8. Debrief (AAR): 15-30 წუთი - ფაქტები, დასკვნები, CAPA.

7) სკრიპტის მაგალითები (კატალოგი)

გადახდის წარმატების ვარდნა: პროვაიდერი A ამცირებს ერთ ქვეყანაში; მოსალოდნელი მოქმედებები - ტრაფიკის გადანაწილება, გამარტივებული UX ჩართვა, კომუნიკაცია.
DNS გაუმართაობა: ჩაწერის შეცდომა/TTL, ზოგი მომხმარებელი არ იჭერს დომენს; მოსალოდნელი ნაბიჯებია fixis/folbeck, CDN გაწმენდა, სტატუსის განახლება.
ვადაგასული TLS სერთიფიკატი: ხელსახოცი იშლება ძველი მომხმარებლებისთვის; მოსალოდნელია გადაუდებელი გაფართოება და ჯაჭვის შემოწმება.
Kafka lag: KYC/AML მოვლენების შეფერხების ზრდა; მოლოდინები - კონსიუმერების მასშტაბები, მწარმოებლების შეზღუდვა.
BD p99 და ზრდა 5xx: ვიწრო ინდექსები, კონექტორების ლიმიტი; მოლოდინები - fich დროშები, limites, hotfix/გამოტოვება.
რეგიონალური უარყოფა: AZ/PoP გამორთვა; მოლოდინი - GSLB/Anycast გადართვა, მონაცემთა შემოწმება და SLO.
საკომუნიკაციო დრილი: ყველაფერი „მწვანეა“, მაგრამ ჩვენ ვამოწმებთ შაბლონებს, ინტერვალებსა და კოორდინაციას ლეგალთან/PR- სთან.

8) ინჟექტის შაბლონი (ბარათი)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) უსაფრთხოება და შესაბამისობა

Prod Simulations - მხოლოდ შექცევადი: fick დროშები, მცირე ზომის აქციებით ტრაფიკის გადართვა, კითხვის შენიშვნები, „shadow traffic“.
წვდომის/აუდიტის კონტროლი: ყველა მოქმედება ChatOps/pypline- ის საშუალებით; ჟურნალები უცვლელი საცავში.
PII/საიდუმლოებები - არ გამოიყენება საგანმანათლებლო არტეფაქტებში; მონაცემები დეპერსონალიზებულია.
მარეგულირებელი: თუ სიმულაცია გავლენას ახდენს კლიენტურ კომუნიკაციებზე - აღნიშვნა „მოძღვრება“ კერძო არხებში; საჯარო შეტყობინებები არ არის მიბაძული.

10) შეფასება და AAR - RCA - CAPA

AAR (სხვა მოქმედების მიმოხილვა) - სავარჯიშოების შემდეგ დაუყოვნებლივ: რა ელოდა/დაინახა, რაც მუშაობდა/არა.
RCA - მნიშვნელოვანი წარუმატებლობისთვის (მაგალითად, ესკალაცია არ მუშაობდა) RCA შაბლონის მიხედვით.
CAPA - მოქმედების ჩამონათვალი მფლობელებთან/ვადებთან/ეფექტის მეტრიკებთან (ცვლილებები პლეიბუკებში, ალერტებში, არქიტექტურაში).
საკონტროლო წერტილები - D + 14/D + 30: შესრულების შემოწმება, დაუცველი ადგილების განმეორებითი მინი დრილი.

11) დოკუმენტაცია და არტეფაქტები

სიმულაციის გეგმა: მიზნები, სცენარი, ინჟექტები, მონაწილეები, ფანჯრები, წარმატების კრიტერიუმები.
Timline (UTC): T0... Tn, IC გადაწყვეტილებები, ტექნიკური ნაბიჯები, განახლება.
დაშბორდების/ლოგების სურათები, ალერტებისა და სტატუსის ჩამკეტები.
საბოლოო ანგარიში: მეტრიკა, განსხვავებები პლეიბუკებთან, CAPA.
დოკუმენტაციის განახლებები: runbook/SOP/კონტაქტების რედაქტირება, ახალი დაშბორდის ბმულები.

12) სიხშირე და გაშუქება

Tabletop: თვეში 2-4 ჯერ (საკვანძო ნაკადებზე და როლებზე).
თამაშის დღეები სტეჯში: 1-2 ჯერ თვეში.
Chaos შემთხვევები (prod light): კვარტალურად, მკაცრად gates.
DR სწავლებები: წელიწადში 1-2 ჯერ რეალური გადართვით.
Comms-drill: ყოველთვიურად შაბლონების და SLA აპდიტების მომზადებისთვის.

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

სიმულაციამდე

• სცენარი, „ინჟექტები“, წარმატების კრიტერიუმები, უსაფრთხოების ფანჯრები.
• შეთანხმებულია როლები, არხები, შაბლონების სტატუსი.
• შემოწმებულია სტენდების/დროშების/დაშბორდის ხელმისაწვდომობა.

დაფიქსირებულია გაუქმებისა და შექცევადობის გეგმა.
შეფასებულია რისკები და გავლენა SLO/მომხმარებლებზე.

დროს

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

უსაფრთხოება: შეინიშნება აკრძალვები/შეზღუდვები.

შემდეგ

• AAR ჩატარდა, ანგარიში შენარჩუნებულია.
• RCA (წარუმატებლობის დროს) ინიცირებულია.
• CAPA გაფორმებულია მფლობელებთან/ვადებთან.
• განახლებულია runbook/SOP/კონტაქტები.
• დაგეგმილია დაუცველი ადგილების განმეორება.

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

„იმპროვიზაცია გეგმის ნაცვლად“ - არ არსებობს სცენარი და წარმატების კრიტერიუმები.
რისკები კარიბჭეების გარეშე და გაუქმების გეგმა - სავარჯიშოები ინციდენტად იქცევა.
მხოლოდ აღჭურვილობის შემუშავება კომუნიკაციისა და ესკალაციის გარეშე.
AAR/RCA- ს არარსებობა - გუნდი არ სწავლობს.
პროდ-ქაოსი დაკვირვების გარეშე და SLO გარდერობები.
გაუმჭვირვალე უფლებები: საიდუმლო სახელმძღვანელო კორექტირება გაყიდვაში.

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

თამაშის დღის წესრიგი (60-90 წუთი)

1. Brief (5 წთ) - მიზნები, როლები, უსაფრთხოება.
2. სცენარი T0 (5 წთ) - სიმპტომების შესრულება.
3. სამჯერ/ესკალაცია (10 წუთი).
4. დიაგნოზი + მოქმედება (30-45 წთ) - 1-2 „ინჟექცია“.
5. აღდგენა და გადამოწმება (10 წუთი).
6. AAR (15 წუთი) - დასკვნები, CAPA.

AAR შაბლონი (მოკლე)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) შედეგი

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