GH GambleHub

SLO, SLA және сенімділік мониторингі

(Бөлім: Технологиялар және Инфрақұрылым)

Қысқаша түйіндеме

SLO - сапаның ішкі мақсаты, SLA - клиент алдындағы сыртқы міндеттеме, SLI - біз сапаны қалай өлшейміз. iGaming-те негізгі SLI: API қолжетімділігі және төлемдер, критикалық маршруттардың жасырындылығы p95/p99, Time-to-Wallet (TTW), төлемдерді конверсиялау, ойындарды іске қосу, сондай-ақ кезектердің метрикасы. Сенімділікті басқару қателер бюджеті, multi-burn тәуекелдері, релиздердің нақты гейттері және аннотациялары бар көрнекі дашбордтар төңірегінде құрылады.

1) Терминдер мен айырмашылықтар

SLI (Service Level Indicator) - өлшенетін индикатор (мысалы, уақыт терезесі үшін табысты сұрау салу үлесі).
SLO (Service Level Objective) - SLI нысаналы мәні (мысалы, "қолжетімділік 99. 30 күнде 9%").
SLA (Service Level Agreement) - өтемақылары бар келісімшарт/міндеттеме; нақты SLO-ға негізделеді, бірақ заңдық ескертпелер мен ерекшеліктер терезелерін қамтиды (planned maintenance, форс-мажор).

Ереже: алдымен ішіндегі SLI/SLO-ны тұрақтандырыңыз, содан кейін ғана SLA-ны сыртқа шығарыңыз.

2) iGaming үшін SLI қаңқасы

TexSLO

Availability: сәтті 2xx/3xx/барлық сұраулар.
Latency: p95/p99 ('/deposit ', '/bet', '/game/init ').
Errors: 5хх/таймауттар үлесі.
Saturation/Queues: төлем/транзакция кезектерінің кешігуі.

Бизнес-SLI

Payment conversion: `success/attempt`.
TTW p95: шығару сұрауынан тіркеуге дейінгі уақыт.
Game start success: ойын сессиялары, провайдерді баптандыру.
KYC/AML flow success: жолдың сәтті аяқталуы.

3) Қателер бюджеті: қалай санау керек

Error Budget = 1 − SLO.
Мысалы: SLO қол жетімділігі 99. 9 %/30д ⇒ қателер бюджеті = 0. 1% уақыт ≈ 30 күндік терезеде 43мин 12с.

SLI-үлес үшін:

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO жылжымалы терезеде (30/7/1 күн) есептеледі және дашбордтарда көрінеді.

Пайдалану саясаты:
  • Бюджетті тез «жану» → freeze релиздері, канареяны тоқтатамыз, тұрақтылық үстінде жұмыс істейміз.
  • Бюджет қоры → жиі өзгерістерге жол береміз (бақыланады).

4) Негізгі ағындар үшін SLO мысалдары

Payments API:
  • Availability ≥ 99. 9 %/30д
  • Latency p95 `/deposit` ≤ 250 ms / 30д
  • Payment conversion ≥ baseline − 0. 3 %/24 сағ
  • TTW p95 (шығу) ≤ 3 мин/24 сағ
Games API/ойын провайдерлері:
  • Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д
Backoffice/есептер:
  • Job success ≥ 99 %/7д, лаг <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]))
p95 латенттілігі:
promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))
TTW p95 (оқиғалар гистограммасы):
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 алерта (multi-window)

Идея: бюджет шығысының ағымдағы жылдамдығын рұқсат етілген жылдамдықпен салыстырамыз.

SLO 99 үшін мысал. 9%:
  • Fast burn: 1 сағат үшін 14 бюджет × → пейдж 5-15 минуттан кейін.
  • Slow burn: 24 сағат ішінде 6 бюджет × → тикет, себептерін талдау.
Жалған ережелер:
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, түрі (canary/blue-green), ауыстыру уақыты.
Drill-down:
  • stable vs canary.
  • PSP/ойын провайдерлері бойынша тілік.
  • exemplars (trace_id) және байланысты логтарға өту.
  • Queue lag және saturation (USE-метриктер).

8) SLO-процестер: гейтс, freeze, эскалация

CD-дегі Gates: канареяны жарнамалауға SLO-прокси (availability, p95, conv) орындалғанда ғана рұқсат етіледі.
Freeze: fast-burn немесе бюджеттің нөлдік қалдығы кезінде - қалпына келтірілгенге дейін релиздерді тоқтату.
Эскалация: SEV-матрица (SEV1 төлемдер/депозиттер, SEV2 ойындар, SEV3 бэкофис).
RCA: айыптаусыз талдау, тестілерді/лимиттерді/фичефлагтарды жаңарту.

9) Data/ML-SLO (ұсынушылар/LLM үшін)

Latency: модель жауабының p95 ≤ 300 ms (немесе tokens/s ≥ N).
Quality proxy: валидті жауаптар/төмен уыттылық үлесі, share of helpful.
Freshness: фич/деректер жасы ≤ X сағат.
Cost per 1k events: бюджет шығыстары.
SLO-гейттер модельдер релиздеріне (А/В/канареялық rollout) біріктіріледі.

10) SLO базасында SLA құрастыру

SLA негізі ретінде консервативті SLO таңдаңыз.
Ерекшеліктерді анықтаңыз (жоспарлы жұмыстар, сыртқы тәуелді провайдерлер, инциденттер регламенті).
Бұзушылықтар деңгейі бойынша өтемақыны (кредит/жеңілдік), есептілік және верификация тетіктерін енгізіңіз.

11) Жиі қателер және қарсы үлгілер

SLO жоқ, тек «uptime 100%» - шындыққа жанаспайды, тәуекелдерді демотивациялайды және жасырады.
Алерталар «әр метрика» бойынша burn-rate орнына - алерт-фэтиг және игнор.
SLO үшін метриктерде/логтарда PII араластыру - комплаенс тәуекелі.
Кардиналдық жарылады: 'user _ id/session _ id' лейблдер сияқты.
Релиздер аңдатпасының жоқтығы - деградацияны өзгерістермен байланыстыру қиын.
Қателер бюджеті ашық емес - команда қашан тәуекелге баруға болатынын түсінбейді.
SLO бизнеске байланыспаған - «жасыл» техметриктер, «қызыл» түсім.

12) Енгізу чек-парағы

1. Базалық SLI (Availability, p95/p99, Error-rate, TTW, Conversion) бекітіңіз.
2. 30/7/1 күндік терезелерде SLO орнатыңыз және Error Budget есептеңіз.
3. recording rules және burn-rate алаңдарын қосыңыз (fast/slow).
4. Релиздер аңдатпалары мен canary/stable салыстырулары бар SLO картасын жасаңыз.
5. CD-ге гейттерді қосыңыз: SLO-оксыз - промоушенсіз.
6. freeze-процедураларын және эскалация SEV-матрицасын енгізіңіз.
7. SLO-ны бизнес-метрикалармен (conv, TTW) және төлем маршруттарымен байланыстырыңыз.
8. Data/ML үшін latency/quality/freshness-SLO анықтаңыз.
9. Тұрақты RCA және SLO/шектерді қайта қарау (тоқсан сайын).
10. SLO тұрақтандырылғаннан кейін ғана SLA құжаттаңыз.

13) «Дайын» мақсаттар мысалдары (старт ретінде)

Жалпы API: Availability 99. 9 %/30д; p95 ≤ 250 ms/30д; Error-rate ≤ 0. 3 %/30д.
Payments: Conversion ≥ baseline − 0. 3 %/24 сағ; TTW p95 ≤ 3 мин/24 сағ.
Games init: Success ≥ 99. 5 %/7д; p95 ≤ 600 ms/7д.
Backoffice jobs: Success ≥ 99%/7д; лаг ≤ 5 мин/7д.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7д, freshness ≤ 6 сағ.

SLO/SLA тәсілі сенімділікті «кешегіден жақсырақ» өлшенетін пәнге айналдырады: мөлдір SLI, түсінікті қателер бюджеті, жану жылдамдығына алаңдар, түсінікті дашбордтар және релиздерге енгізілген сапа гейттері. Мұндай контур iGaming платформасына болжамды p95/p99, тұрақты төлемдер және TTW береді, демек - ең жақсы түсім және ең ыстық сағаттарда инциденттерді азайтады.

Contact

Бізбен байланысыңыз

Кез келген сұрақ немесе қолдау қажет болса, бізге жазыңыз.Біз әрдайым көмектесуге дайынбыз!

Telegram
@Gamble_GC
Интеграцияны бастау

Email — міндетті. Telegram немесе WhatsApp — қосымша.

Сіздің атыңыз міндетті емес
Email міндетті емес
Тақырып міндетті емес
Хабарлама міндетті емес
Telegram міндетті емес
@
Егер Telegram-ды көрсетсеңіз — Email-ге қоса, сол жерге де жауап береміз.
WhatsApp міндетті емес
Пішім: +ел коды және номер (мысалы, +7XXXXXXXXXX).

Батырманы басу арқылы деректерді өңдеуге келісім бересіз.