ოპერაციები და მენეჯმენტი - ინციდენტების პრევენცია

ინციდენტების თავიდან აცილება

1) რატომ არის ეს აუცილებელი?

ინციდენტზე საუკეთესო რეაქცია მისი არყოფნაა. iGaming/fintech- ისთვის თითოეული წუთი მარტივია - დაკარგული განაკვეთები/ანაბრები, პროვაიდერების ჯარიმები, რეპუტაციის რისკები. სისტემის პრევენცია ამცირებს Change Failure Rate- ს, სტაბილიზაციას უწევს SLO- ს და ათავისუფლებს გუნდების დროს განვითარებისთვის და არა ხანძრის ჩაქრობის მიზნით.

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

2) პროფილაქტიკის ძირითადი პრინციპები

1. SLO-first და error budget: ცვლილებები არ გაიცემა, თუ ისინი რისკავს SLO- ს დაშლას და ბიუჯეტის დაწვას.
2. Defence in depth: თავდაცვის ფენები - მონაცემთა სქემებიდან და კონფიგურაციიდან დაწყებული ქსელური პოლიტიკოსი და შუამდგომლობები.
3. დიზაინი მომავლისთვის: ბრეიკერები, ტაიმაუტები, ჯიტერის რეტრაები, იდემპოტენტობა, დეგრადაცია.
4. Small & reversible changes: მცირე ნიშნები + სწრაფი დაბრუნება (feature flags/კანარი).
5. Observability by Design: მეტრიკა/logs/traces თითოეული კრიტიკული ნაბიჯისა და კავშირისთვის.

3) რისკებისა და კრიტიკული გზების რუკა

შეადგინეთ „ტკივილის რუკა“ დომენებისთვის: Payments, Bets, Games, KYC, Promotions, Jackpots, Content.

• ბიზნეს მეტრიკა (კონვერტაცია, GGR, საშუალო შემოწმება).
• ტექნიკური SLO (latency p95/p99, uptime, success rate).
• დამოკიდებულება (შიდა/გარე), შეზღუდვები/კვოტები.
• „Safe mode“ ქცევა (რაც გამორთეთ/გამარტივდება).
• მეპატრონის Runbook.

4) Guardrails (დამცავი ბარიერები)

ტაიმაუტები და ბრეიკერები: გამომწვევი სერვისის ტაიმუთი უფრო მოკლეა, ვიდრე შინაგანი თანხა; ბრეიკერი იხსნება შეცდომების/ლატენტობის გაზრდით.
Bulkhead იზოლაცია: ნაერთების/ვორკერების ცალკეული აუზები downstrimes.
Rate limit & backpressure: დაცვა ზვავისა და ჭიდაობისგან.
დეგრადაციის ficheflages: „მინიმალური რეჟიმი“ - მსუბუქი პასუხები, ქეშის რეპლეი, მძიმე დარტყმის გათიშვა.
მრავალ გამყიდველი და ფეილოვერი: ალტერნატიული PSP/KYC, მარშრუტების გადართვა.
კონფიგურაციის შესაბამისობა: სქემები/ლინერები/პოლიტიკოსები, რომ უსაფრთხო შეცვალონ ფიჩები და ლიმიტები.

5) ცვლილების მენეჯმენტი

Pre-release gates: ტესტები, უსაფრთხოება, CDC (consumer-driven contracts), სქემების თავსებადობა.
კანარის გამოშვება + ავტო კარიბჭე: 1% - 10% - 100%; მანქანის გაჩერება p99/error rate/წვის ბიუჯეტით.
Feature flags: მყისიერი გამოტოვება/ქცევის შეცვლა ზეპირი გარეშე.
Release calendar: თავიდან ავიცილოთ სპორტის/ტურნირების პიკის ფანჯრები და პროვაიდერები.
Post-deploy checks: მანქანის მანქანა, მეტრიკის შედარება „წინ/მის შემდეგ“ რეიდებთან.

6) ტესტირება, როგორც პრევენციული ღონისძიება

Unit/contract/integration: OpenAPI/AsyncAPI კონტრაქტები, CDC პროვაიდერის/შოკის წინააღმდეგ.
Load & stress: პრემიერ ტაიმის ტრაფიკის პროფილები; ტესტები კონექტირების ლიმიტებზე/IOPS/კვოტაზე.
Soak/long-haul: რესურსების გაჟონვა, საათების/დღის ჰორიზონტზე შეფერხებების ზრდა.
Chaos/game-days: ბროკერის/PSP/KYC ვარდნა, რეგიონის რღვევა, „ნელი პროვაიდერი“.
Disaster Recovery Drills: რეგულარული ტრენინგი რეგიონების გადართვისა და მონაცემთა ბაზის აღდგენის მიზნით.

7) დეგრადაციის ადრეული გამოვლენა

Capacity-alerts: headroom, რიგების ლაქები, BD კონექტორები, ქეშებში გამოჩენა.
SLO-burn-rate: სიგნალი ბიუჯეტის „დაწვის“ საშიში სიჩქარით.
ადაპტური ბარიერები: სეზონური/ყოველდღიური შაბლონები ყალბი შემცირების მიზნით.
კომპოზიციური ალერტები: "lag" + HPA at max + Open circuit "მაღალი რისკია.
Vendor health: კვოტები/Timauts/შეცდომები თითოეული პროვაიდერისთვის + ზარის ღირებულება.

8) გარე პროვაიდერთან მუშაობა

OLA/SLA - SLO: შეთანხმებების დაკავშირება ჩვენს მიზნებთან.
Playbooks faylover: მარშრუტები PSP-X - PSP-Y, tockens ქეში, grace დეპოზიტების რეჟიმები.
სენდბოქსი და კონტრაქტები: სატესტო flow ყოველი ძირითადი ცვლილების წინ.
პროვაიდერების ფანჯრები: dashboards- ის ვიდეოები და ავტომატური suppress წესები.

9) მონაცემები, კონფისკაცია და საიდუმლოებები

ცვლილებების პოლიტიკოსები: ორი წყვილი თვალის კოდირება, სქემების ამოცნობა/JSON/YAML.
საიდუმლოებები: KMS/Secrets მენეჯერი, როტაცია, დაყოფა წრეებში/როლებზე.
დროშები/ლიმიტები: ცვლილებები API- ს საშუალებით აუდიტით და მყისიერი გამოტოვებით.
მიგრაცია: „ორსაფეხურიანი“ (ექსპედიცია - migrate - contract), მთლიანი საპირისპირო თავსებადობა.

10) გუნდების მომზადება და მზადყოფნა

On-call ტრენინგი: ინციდენტების სიმულაცია, Shadow მოვალეობა, ცენტრალიზებული runbook '.
ერთიანი საკომუნიკაციო ფორმატები: სტატუსის/ქუდების შაბლონები/ინციდენტი.
უსაფრთხო კულტურა: პოსტპორტი ბრალდების გარეშე, მექანიკური მიზეზები და პრევენციული ქმედებები.

11) დაშბორდი პროფილაქტიკა (მინიმალური)

Risk & Readiness: SLO/ბიუჯეტი, ფენების headroom, „დაუცველი კავშირები“.
Change Safety: კანარის, გამოტოვების, ალერტების პროცენტი „გამოშვების შემდეგ“, CTR Autogates.
Vendor Panel: p95/error/კვოტები/ღირებულება თითოეული პროვაიდერისთვის, გამყიდველის საპასუხო პასუხის დრო.
Chaos/DR Readiness: სავარჯიშოების სიხშირე, რეგიონის გადართვის დრო, აღდგენის წარმატება.
Config/SecOps: დროშების/ლიმიტების/საიდუმლოებების ცვლილებები, ანომალიები.

12) პროფილაქტიკური ალერტების მაგალითები

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) პრევენციის შემოწმების სია (ყოველდღიურად/მწვერვალებამდე)

• მიმდინარე მწვერვალების კალენდარი (მატჩები, ტურნირები, კამპანიები, პროვაიდერების ფანჯრები).
• Headroom API/BD/ქეშები/ხაზები, HPA/VPA- ს მზადყოფნა, გაათბეთ ქეში.
• პროვაიდერების მდგომარეობა (კვოტები, ლიმიტები, დეგრადაცია 24ch), ყალბია.
• კანარის კარიბჭეები ჩართულია, უკან დაბრუნება შესაძლებელია მფლობელებისთვის.
• Alerty SLO/Capacity აქტიურია, suppression ასახულია დაგეგმილი სამუშაოსთვის.
• Runbook 'და განახლებულია, დადასტურებულია, ესკალაციის არხები მუშაობს.

14) ანტი-შაბლონები (რა უნდა ავიცილოთ)

„დიდი ღამის გამოშვებები“ კანალიზაციის და დროშების გარეშე.
ნაკადების მთლიანი აუზები ყველა დაბალ მონაკვეთზე (head-of-line blocking).
Retrais idempotent ოპერაციებისთვის და ვიწრო ადგილების ტაიმაუტებისთვის.
ალერტებში ჰისტერეზის არარსებობა არის ხერხი ზღურბლზე.
ბრმა რწმენა SDK გამყიდველის გარეშე დაკვირვებისა და ტაიმაუტის კონტროლის გარეშე.
„მოდით გავაკეთოთ გაყიდვაში“ stage/sandbox და CDC გარეშე.

15) KPI პროფილაქტიკა

Change Failure Rate (მიზანი 10-15% ან თქვენი სამიზნე).
Pre-Incident Detect: ინციდენტების წილი დეგრადაციის ეტაპზე.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage დაცვა: კრიტიკული ბილიკების% დროშებით/ბრეიკერებით/ტაიმაუტებით/კანარით.
Chaos/DR cadence: ვარჯიშების სიხშირე და წარმატება.
Vendor readiness: სარეზერვო პროვაიდერზე გადასვლის საშუალო დრო.

16) სწრაფი დაწყება (30 დღე)

კვირა 1: კრიტიკული ბილიკების რუკა, SLO და მფლობელები; ჩართეთ SLO-burn-alerts და capacity-alerts.
კვირა 2: კანარის კარიბჭეები + ფიჩეფლაგები; ძირითადი ქაოსის სცენარები (პროვაიდერი/ხაზი).
კვირა 3: Dashboards „Change Safety“ და „Vendor Panel“, Faylover Playbooks.
კვირა 4: DR სწავლება (ნაწილობრივი), რეტროსპექტივა და კვარტალი გეგმა.

17) შაბლონები (ფრაგმენტები)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

Q: რა უნდა განხორციელდეს პირველ რიგში, თუ საკმარისი რესურსები არ არის?
A: SLO-burn-alertes კრიტიკულ გზებზე, კანარის კარიბჭეები და დაბრუნების ფიჩეფლაგები; შემდეგ - რისკების რუკა და პროვაიდერების ყალბი.

Q: როგორ გავიგოთ, რომ პრევენცია „მუშაობს“?
A: Change Failure Rate მცირდება, პრევენციული ინციდენტების პროპორცია იზრდება, MTTR და ალერტების ხმაური ეცემა, მცირდება „ღამის“ პეიჯების რაოდენობა.

Q: საჭიროა რეგულარული ქაოსის სწავლებები?
ა: დიახ. ვარჯიშის გარეშე, ფეილოვერი და DR თითქმის ყოველთვის უფრო გრძელი და მტკივნეულია, ვიდრე ქაღალდზე ჩანს.