რეაქცია ინციდენტებზე და უბედურ შემთხვევებზე

(განყოფილება: ოპერაციები და კონტროლი)

1) განსაზღვრა და მიზანი

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

ძირითადი პრინციპები

Safety first: ხალხის/მონაცემების/ფულის დაცვა ფუნქციებზე უფრო მნიშვნელოვანია.
ერთი რამ ჩაკეტვა: ერთი ინკლუზიური კომანდერი (IC) იღებს გადაწყვეტილებებს.
Actionable ახლა: თითოეულ ჰიპოთეზას თან ახლავს შემოწმება/მოქმედება.
Evidence matters: ყველაფერი კეთდება, არტეფაქტები იწერება, დრო დეტალურია.

2) კლასიფიკაცია (პრიორიტეტი)

ტრიგერი: SLO დარღვევა, ალერტის წესი, სახელმძღვანელო რეპორტაჟი, იურიდიული ინციდენტი (DPO/CCO).

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

Incident Commander (A) - ინციდენტის ლიდერი, დავალებების დაყენება, გადაწყვეტილების მიღება, IC- ის შეცვლა გრძელი ინციდენტებით.
Tech Lead (R) - ტექნიკური დიაგნოზი/ფიქსაცია, SRE/ინჟინერიის კოორდინაცია.
Comms Lead (R) - წერს სტატუსის განახლებებს (შიგნით/გარეგნულად), სტატუსის გვერდის მფლობელი.
Scribe (R) - პროტოკოლი, დრო, არტეფაქტების შეგროვება.
Security/Legal (C/A Security შემთხვევებისთვის) - რისკების შეფასება, სავალდებულო შეტყობინებები.
Customer Suport (C) - პასუხის შაბლონები, ტიკეტების მარშრუტიზაცია.
Partner Liaison (C) - კომუნიკაცია პროვაიდერთან/ტენანტებთან.
მენეჯმენტი (I) - ინფორმირება, ბიზნეს გადაწყვეტილებები (სესხები/ანაზღაურება).

4) პირველი 15 წუთი (შაბლონი)

1. დანიშნეთ IC და გახსნათ ინციდენტის ბარათი (chat არხი, ვიდეო ხიდი, Jira/Tracker).
2. მიანიჭეთ SEV და დააფიქსირეთ SLO სიმპტომი (რა არის დარღვეული).

• ჩართეთ runbooks/runs: circuit-breakers, trotling, მარშრუტის გადართვა, პრომო პაუზა;
• კომპრომისზე - მგრძნობიარე ფუნქციები.
• 4. ბრძანებები: Tech Lead - დიაგნოზი; Comms - „ტექნიკური ყინული“ (10-15 წუთის შემდეგ - პირველი განახლება).
• 5. განსაზღვრეთ ჰიპოთეზები (სამი მაქსიმალური), დანიშნეთ მფლობელები, შეამოწმეთ ტაიმერები (5-10 წუთი).
• 6. შეაგროვეთ არტეფაქტები: მეტრიკის სნაიპშოტები, კონფიგურაცია, გამოშვების ჰეში, logs 'trace _ id', ქვითრები.

5) პირველი საათი (შაბლონი)

კომუნიკაცია v1 (15-20 წუთი): ფაქტი, გაშუქება, სიმპტომები, რასაც ვაკეთებთ, შემდეგი განახლება. სპეკულაციების გარეშე.
ინციდენტის საზღვრები: რომელი რეგიონები/ტენანები/არხები/ვერსიები დაზარალებულია.
ზიანის კონტროლი: დროებითი ქუდი/შეზღუდვები, „ხმაურიანი“ ინტეგრაციის გათიშვა, დეგრადაციის რეჟიმის ჩართვა.
Forenzic: გაყინეთ ლოგოების როტაცია, დაიცავით არტეფაქტები (WORM/ხელმოწერები).
საგზაო რუკა: T + 30/T + 60 ჩეკებით.

6) კომუნიკაციები და სტატუსის გვერდი

ინტერვალები: P1 - ყოველ 15 წუთში, P2 - 30-60 მმ.
გარე: სტატუსის გვერდი/ტენანტი/SLA პარტნიორები.

• როგორც ჩანს: „X: YY UTC- დან, EU- ს რეგიონში შემოწმების უკმარისობის ზრდა (p95> 250 ms)“
• ვინ მოქმედებს: „ოპერატორები A/B/C, ~ ტრაფიკის 40%“
• რას ვაკეთებთ: "მათ ჩართეს ალტერნატიული მარშრუტი, პრომო trottling; ჩვენ ვმუშაობთ PSP-1 პროვაიდერთან"
• მონაცემები/ვადები: „შემდეგი განახლება 15 წუთში“
• ანაზღაურება: „გამოიყენეთ საკრედიტო ნოტები SLA- ს მიხედვით ინციდენტის დახურვის შემდეგ“

7) ფლეიბუკი (რეფერენდუმები iGaming/fintech)

PriceMismatch (ვიტრინა): ქეში ინვალიდობა, 'fx _ version/tax _ rule _ version' შერწყმა, დინამიური პრომო გაყინვა, პოლიტიკის განსხვავებების ანაზღაურება.
WebhookLag (პარტნიორები/აფილიატები): ვორკერების მასშტაბები, batch- ის ზრდა, რეაგირების პრიორიტეტი, ახალი გამოწერის დროებითი ჩეკა.
Payments Outage/PSP დეგრადაცია: სარეზერვო PSP- ზე გადასვლა, მომხმარებელთა ტაიმაუტების შემცირება, სახელმძღვანელო კლირინგი, „ნაცრისფერი“ საკარანტინო გარიგებები.
RTP Drift: ბონუსის პაუზა, გადახდის/ვერსიების ცხრილების შემოწმება, სათვალთვალო ფანჯრის გაფართოება, RTP პროფილის გამოტოვება.
Fraud Spike: გამკაცრდეს velocity/limites, ჩართოთ დამატებითი KYC შემოწმება, საეჭვო კოჰორტების იზოლაცია, მაღალი მოგების სახელმძღვანელო ჭრა.
Data/PII Exposure: სისტემის იზოლაცია, DPO/Legal შეტყობინება, დაზარალებული ჩანაწერების ინვენტარიზაცია, მარეგულირებელი ვადების შეტყობინებები.

8) ინსტრუმენტები და რუნები (auto-actions)

Кнопки: Pause Promo, Re-Route, Raise Limit, Rollback, Flush Cache, Disable Webhooks, Enable Safe Mode.
Gward Rails: დაცვა „საცვლებისგან“ - გამოტოვება შეზღუდულია, ჟურნალები გაფორმებულია, ყველა მოქმედება არის IC/Scribe.
დადასტურება: DSSE ხელმოწერები, Snapshots heshes, Merkle ლოგოების მოჭრა.

9) ინციდენტის დასრულება

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

10) Post-mortem (ბრალდების გარეშე)

ვადა: P1 - 3 სამუშაო დღის განმავლობაში; P2 - 5 სამუშაო დღე.
შინაარსი: ფაქტები/დრო, ძირითადი მიზეზები (5 Whys/FRAM), გავლენა (SLO, ფინანსები, კლიენტები), რომლებიც მუშაობდნენ/არა, მოქმედება items (owner, ვადა, გაზომვის ეფექტი).
ეფექტურობის შემოწმება: 30-60 დღის შემდეგ - შესრულების შურისძიება და მეტრიკა (განმეორება, MTTR, ალერტის ხმაური).

11) მეტრიკი და SLO ინციდენტის მენეჯმენტი

MTTD/MTTA/MTTR, Change Failure Rate, Time to Comms v1,% ნებადართული მანქანები (რუნები).
Alert Noise: შეუსაბამო სიგნალების წილი, pages on-call shift.
Repeat Incidents: გამეორებების წილი 90 დღეში.
Post-mortem SLA: გატარებული/დახურული წილი დროულად.
SLO რეაქცია: P1 - პირველი კომუნიკაცია 15 წუთზე; MTTR - 60 წთ; არტეფაქტების სისრულე = 100%.

12) კანონი/შესაბამისობა/კონფიდენციალურობა

იურიდიული შეტყობინებები: ადგილობრივი გაჟონვის რეგულატორების/ინციდენტების ვადები.
PII მინიმიზაცია: პირველადი წვდომა მხოლოდ დამტკიცებული ჯობის საშუალებით; ტოქსიკაცია/შენიღბვა.
არტეფაქტების შენახვა: WORM ჟურნალები, შენახვის პერიოდი იურისდიქციებით; წვდომის კონტროლი (RBAC/ABAC, JIT).
კონტრარგუმენტები: SLA ხელშეკრულებები, ესკალაციის პროცესი, სასამართლო ქვითრები.

13) მოვალეობების და ესკალაციების ორგანიზაცია

24 × 7 on-call: როტაცია (SRE, App, Data, Security, Payments).
ესკალაციის მატრიცა: ვინ არის რეგიონები/პროდუქტები/პროვაიდერები; კონტაქტების დუბლირება (chat/ხმა/SMS).
წვრთნები (GameDays): სიმულაციები - PSP ვარდნა, რეცესიის ზვავი, ფასების რასინქრონი, გასაღების კომპრომისი, რეგიონის უკმარისობა.

14) დაშბორდები

სიცხე (ახლა): SLO სტატუსი, p95/p99, რეგიონების/ტენანტების რუკა, დავალებების ხაზი, არტეფაქტები შეგროვდა/არა.
ისტორია: ინციდენტების ტიპის ტენდენციები, რუნების ეფექტურობა, მიზეზების განმეორება.
ხარისხის კონტროლი: დროის სისრულე, პოსტ-mortem- ის „შეკრება“, SLA კომუნიკაციები.

15) განხორციელების სია

• დაამტკიცეთ SEV მასშტაბი და SLO გამომწვევები.
• დანიშნეთ როლები (IC/Tech/Comms/Scribe/Sec/Legal) და როტაცია 24 × 7.
• დაიწყეთ ინციდენტის ბარათის ერთი შაბლონი და სტატუსის გვერდი.
• აღწერეთ PriceMismatch/WebhocLag/Payments/RTP/Fraud/PII).
• განახორციელეთ რუნები აუდიტით და „წითელი ღილაკით“.
• ჩართეთ ფორენსიკის პოლიტიკა: WORM/ხელმოწერები/არტეფაქტების შეგროვება.
• კომუნიკაციების წესები (შიდა/გარეგანი) , SLA განახლებები.
• პოსტ-mortem პროცესი და შაბლონები; KPI მოქმედების items.
• GameDays ყოველთვიურად; ინციდენტების ტენდენციების კვარტალური მიმოხილვა.
• IR მეტრიკა დაშბორდზე (MTTA/MTTR/ხმაური/Repeat/Comms SLA).

16) FAQ

რატომ არის IC მარტო?
გადაწყვეტილების მიღების ერთი წერტილი ასუფთავებს ქაოსს და აჩქარებს რეაქციას.

როდის უნდა გამოცხადდეს საჯაროდ?
როგორც კი დადასტურებული ფაქტი და სტაბილიზაციის გეგმა არსებობს. შეაფასეთ მარეგულირებელი ვადები.

რა არის უფრო მნიშვნელოვანი - ფიქსი თუ ანგარიში?
პირველი - აღდგენა და უსაფრთხოება. პარალელურად - არტეფაქტების შეგროვება. ანგარიში სტაბილიზაციის შემდეგ.

შესაძლებელია თუ არა ყველაფრის ავტომატიზაცია?
არა, მაგრამ რუნები ხურავს „ხშირი და მარტივი“ ნაბიჯებს. დანარჩენი - მკაფიო ფლეიბუკებითა და ვარჯიშებით.

რეზიუმე: ძლიერი Incident Response არ არის მხოლოდ PagerDuty და chat არხი. ეს არის როლების დისციპლინა, სწრაფი პირველი 15 წუთი, კონტროლირებადი რუნები, გამჭვირვალე კომუნიკაციები, საყრდენი მტკიცებულებებით და სავალდებულო პოსტ-შურისძიება. ასეთი კონტურით, თქვენ ამცირებთ MTTR- ს, იცავთ ფულს და მონაცემებს და ზრდის მომხმარებლებისა და რეგულატორების ნდობას.