SLO, SLA жана ишенимдүүлүк мониторинг

(Бөлүк: Технология жана инфраструктура)

Кыскача резюме

SLO - сапаттын ички максаты, SLA - кардарга тышкы милдеттенме, SLI - биз сапатын өлчөө катары. iGaming негизги SLI: API жана төлөмдөрдүн жеткиликтүүлүгү, p95/p99 маанилүү каттамдардын жашыруун, Убакыт-Кошелек (TTW), төлөмдөрдү которуу, оюндарды баштоо, ошондой эле кезек метрика. Ишенимдүүлүктү башкаруу каталар бюджетинин айланасында курулат, multi-burn алерт, так гейт релиздер жана аннотациялар менен визуалдык дашборддор.

1) Терминдер жана айырмачылыктар

SLI (Service Level Indicator) - өлчөнүүчү индикатор (мисалы, убакыт терезеси үчүн ийгиликтүү суроо-талаптардын үлүшү).
SLO (Service Level Objective) - SLI максаттуу мааниси (мисалы, "жеткиликтүүлүк 99. 9% 30 күн").
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 %/30d ⇒ бюджет каталар = 0. 1% убакыт ≈ 43мин 12с 30 күндүк терезеде.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

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

• Тез "күйүү" бюджети → freeze релиздер, канарея туруктуулук боюнча иштеп, токтоп турат.
• Бюджеттин запасы → тез-тез өзгөрүүлөргө жол (көзөмөлдөнөт).

4) негизги агымдар үчүн SLO мисалдар

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (чыгаруу) ≤ 3 мин/24h

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

• Job success ≥ 99 %/7d, лаг <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 Алерт (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) Dashbord "SLO-карта" жана иштетүү

• Кызмат карталары: Availability, p95, Error-rate, Burn-rate, Error Budget калдыгы.
• Filters: 'env', 'region', 'tenant', 'version'.
• Релиздин аннотациялары: Git SHA, түрү (canary/blue-green), которуу убактысы.

• 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) Маалымат/ML-SLO (сунуш/LLM үчүн)

Latency: p95 жооп модели ≤ 300 ms (же tokens/s ≥ N).
Quality proxy: валиддик жооптордун/төмөн уулуулуктун үлүшү, helpful бөлүшүү.
Freshness: Fich/маалыматтар жашы ≤ X саат.
Cost per 1k events: бюджеттик чыгымдар.
SLO-Гейтс моделдер релиздери менен бириктирилген (A/B/канарейка rollout).

10) SLO негизинде SLA долбоорлоо

SLA негизи катары эскичил SLO тандоо.
Өзгөчөлүктөрдү аныктаңыз (пландуу иштер, тышкы көз каранды провайдерлер, инциденттердин регламенти).
Мыйзам бузуулардын деңгээли (кредит/жеңилдик), отчеттуулук жана верификация механизмдери боюнча компенсацияларды киргизиңиз.

11) Тез-тез каталар жана анти-үлгүлөрү

SLO жок, бир гана "uptime 100%" - реалдуу эмес, демотивация жана тобокелдиктерди жашырат.
Alerty "ар бир метрика" ордуна burn-rate - alert-fetig жана ignor.
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 alert (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 %/30d; p95 ≤ 250 мс/30д; Error-rate ≤ 0. 3 %/30d.
Payments: Conversion ≥ baseline − 0. 3 %/24h; TTW p95 ≤ 3 мин/24 саат.
Games init: Success ≥ 99. 5 %/7d; p95 ≤ 600 мс/7д.
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, демек - эң жакшы киреше жана эң ысык сааттарда азыраак инциденттерди берет.