SLO, SLA და საიმედოობის მონიტორინგი

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

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

SLO არის ხარისხის შიდა მიზანი, SLA არის კლიენტის გარე ვალდებულება, SLI - როგორც ჩვენ ვზომავთ ხარისხს. IGaming- ს აქვს ძირითადი SLI: API ხელმისაწვდომობა და გადახდა, კრიტიკული მარშრუტების p95/p99 ლატენტობა, Time-to-Wallet (TTW), გადახდის კონვერტაცია, თამაშების დაწყება და ხაზების მეტრიკა. საიმედოობის მენეჯმენტი აგებულია შეცდომების ბიუჯეტის, მრავალჯერადი-ბურნის ალერტების, მკაფიო გამოცემების კარიბჭეების და ვიზუალური დაშბორდის გარშემო, რომელსაც აქვს პრეზენტაციები.

1) ტერმინები და განსხვავებები

SLI (Service Level Indicator) - გაზომილი ინდიკატორი (მაგ., დროის ფანჯრის წარმატებული მოთხოვნების წილი).
SLO (Service Level Objective) - SLI მიზნობრივი მნიშვნელობა (მაგ., "წვდომა 99. 9% 30 დღეში").
SLA (Service Level Agreement) - კომპენსაციის ხელშეკრულება/ვალდებულება; დაფუძნებულია რეალურ SLO- ზე, მაგრამ მოიცავს იურიდიულ დათქმებსა და გამონაკლისების ფანჯრებს (პლატფორმა, ფორსმაჟორი).

წესი: პირველ რიგში, სტაბილიზაცია მოახდინეთ შიგნით SLI/SLO და მხოლოდ ამის შემდეგ ჩაწერეთ SLA გარეთ.

2) SLI ჩარჩო iGaming- ისთვის

TexSLO

Availability: წარმატებული 2xx/3xx/ყველა მოთხოვნა.
Latency: p95/p99 საკვანძო როუტებზე ('/deposit ', '/bet', '/game/init ').
Errors: 5xx/Taimauts- ის წილი.
Saturation/Queues: შეფერხება გადახდის/გარიგების რიგებში.

ბიზნეს SLI

Payment conversion: `success/attempt`.
TTW p95: დრო მოთხოვნიდან მიღებამდე.
Game start success: თამაშების სესიები, პროვაიდერის ინიციალიზაცია.
KYC/AML flow success: ბილიკის წარმატებით დასრულება.

3) შეცდომების ბიუჯეტი

Error Budget = 1 − SLO.
მაგალითი: SLO წვდომა 99. 9 %/30d - შეცდომების ბიუჯეტი = 0. დროის 1% - 43min 12s 30-დღიან ფანჯარაში.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO ითვლება მოცურების ფანჯარაში (30/7/1 დღე) და ჩანს დაშბორდებზე.

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

4) ძირითადი ნაკადების SLO მაგალითები

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (გამომავალი) 3 წთ/24სთ

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job success - 99 %/7d, lag <5 წთ (პიკის ფანჯრები ცალკე).

5) გაზომვა: ფორმულები და PromQL (იდეები)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Burn-rate alerta (multi-window)

იდეა: ჩვენ ვადარებთ ბიუჯეტის მოხმარების ამჟამინდელ სიჩქარეს დასაშვებად.

• Fast burn: 14 × ბიუჯეტი 1 საათში პეიჯი 5-15 წუთის შემდეგ.
• Slow burn: 6 × ბიუჯეტი 24 საათში - თიკეტი, მიზეზების ანალიზი.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) დაშბორდები „SLO ბარათი“ და ოპერაცია

• სერვისების ბარათები: Availability, p95, Error-rate, Burn-rate, დანარჩენი Error Budget.
• ფილტრები: 'env', 'region', 'tenant', 'version'.
• გამოშვების სურათები: Git SHA, ტიპი (ცისფერი/ცისფერი-მწვანე), გადართვის დრო.

• შედარება stable vs canary.
• ჭრა PSP/თამაშების პროვაიდერები.
• გადასვლა exemplars (trace _ id) და დაკავშირებული ლოგები.
• Queue lag და saturation (USE მეტრიკა).

8) SLO პროცესები: კარიბჭეები, freeze, ესკალაცია

Gates in CD: კანაფის პოპულარიზაცია ნებადართულია მხოლოდ SLO მარიონეტული შესრულებისას (availability, p95, conv).
Freeze: სწრაფი ბურნით ან ნულოვანი ბიუჯეტის ნარჩენებით - გამოჯანმრთელების შეჩერება.
ესკალაცია: SEV მატრიცა (SEV1 გადახდა/ანაბრები, SEV2 თამაშები, SEV3 ბეკოფისი).
RCA: ანალიზი ბრალდების გარეშე, ტესტების განახლება/ლიმიტები/ფიჩეფლაგები.

9) Data/ML-SLO (რეკომენდატორებისთვის/LLM)

Latency: p95 პასუხი მოდელზე 300 ms (ან tokens/s).
Quality proxy: აქტიური პასუხების წილი/დაბალი ტოქსიკურობა, helpful წილი.
Freshness: იხვები/მონაცემები ასაკი X საათი.
Cost per 1k events: ხარჯები ბიუჯეტში.
SLO კარიბჭეები ინტეგრირდება მოდელების გამოშვებებში (A/B/კანარის რულეტი).

10) SLA- ს დიზაინი SLO- ს საფუძველზე

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

11) ხშირი შეცდომები და საწინააღმდეგო ნიმუშები

არა SLO, მხოლოდ „uptime 100%“ - არარეალისტური, დემოტივაცია და რისკების დამალვა.
„ყველა მეტრიკის“ ალერტები, ნაცვლად burn-rate - ალერტ-ფეტიგი და უგულებელყოფა.
PII- ის შერევა მეტრიკებში/ლოგოებში SLO- სთვის არის კომპლექსის რისკი.
კარდინალობა აფეთქდა: 'user _ id/session _ id', როგორც ეტიკეტები.
გამოშვებების პრეზენტაციების არარსებობა რთულია დეგრადაციის დაკავშირება ცვლილებებთან.
შეცდომების გაუმჭვირვალე ბიუჯეტი - გუნდს არ ესმის როდის შეიძლება „რისკის“ გაკეთება.
SLO არ არის დაკავშირებული ბიზნესთან - „მწვანე“ ტექნიკოსები, „წითელი“ შემოსავალი.

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

1. დაამტკიცეთ ძირითადი SLI (Availability, p95/p99, Error-rate, TTW, Conversion).
2. დაუსვით SLO 30/7/1-დღიანი ფანჯრებით და გაითვალისწინეთ Error Budget.
3. დაამატეთ ჩანაწერები rules და burn-rate alerta (სწრაფი/slow).
4. თქვენ ააშენებთ SLO ბარათს გამოშვებების ვიდეოჩანაწერებით და კანი/შედარების შედარებებით.
5. ჩართეთ კარიბჭეები CD- ში: SLO- ს გარეშე - დაწინაურების გარეშე.
6. შეიყვანეთ freeze პროცედურები და SEV ესკალაციის მატრიცა.
7. დააკავშირეთ SLO ბიზნეს მეტრებთან (conv, TTW) და გადახდის მარშრუტებთან.
8. Data/ML- სთვის განსაზღვრულია ლატენტი/quality/freshness-SLO.
9. რეგულარული RCA და SLO/რეიდების მიმოხილვა (კვარტალურად).
10. SLA დოკუმენტაცია მხოლოდ SLO სტაბილიზაციის შემდეგ.

13) „მზა“ მიზნების მაგალითები (როგორც დასაწყისი)

API არის ზოგადი: Availability 99. 9 %/30d; p95-250 ms/30d; Error-rate ≤ 0. 3 %/30d.
Payments: Conversion ≥ baseline − 0. 3 %/24ch; TTW p95-3 წთ/24სთ.
Games init: Success ≥ 99. 5 %/7d; p95-600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; ლაგი - 5 წთ/7 დ.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness - 6h.

შედეგები

SLO/SLA მიდგომა საიმედოობას „უკეთესად, ვიდრე გუშინ“ აქცევს გაზომილ დისციპლინად: გამჭვირვალე SLI, გასაგები შეცდომების ბიუჯეტი, წვის სიჩქარის ალერტები, გასაგები დაშბორდები და ჩასმული ხარისხის კარიბჭეები. ასეთი წრე იძლევა iGaming პლატფორმას პროგნოზირებადი p95/p99, სტაბილური გადახდები და TTW, რაც ნიშნავს საუკეთესო შემოსავალს და ყველაზე ნაკლებ ინციდენტებს ყველაზე ცხელ საათებში.