SLO, SLA și monitorizarea fiabilității

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

SLO este un obiectiv intern de calitate, SLA este un angajament extern față de client, SLI este modul în care măsurăm calitatea. În iGaming, SLI-urile cheie: API și disponibilitatea plăților, p95/p99 latența rutelor critice, Time-to-Wallet (TTW), conversia plăților, lansarea jocului și măsurătorile de coadă. Managementul fiabilității este construit în jurul unui buget de erori, alerte multi-burn, porți de eliberare clare și tablouri de bord vizuale cu adnotări.

1) Termeni și diferențe

SLI (Indicatorul nivelului serviciului) - indicator măsurat (de ex. proporția cererilor de succes pe fereastra de timp).
SLO (Service Level Obiectiv) - țintă valoare SLI (ex. "disponibilitate 99. 9% în 30 de zile").
SLA (Service Level Agreement) - contract/răspundere cu despăgubire; se bazează pe SLO-uri reale, dar include clauze legale și ferestre de întreținere planificate.

Regula: stabilizați mai întâi SLI/SLO în interior și numai apoi fixați SLA în exterior.

2) cadru SLI pentru iGaming

ExSLO

Disponibilitate: succes 2xx/3xx/toate cererile.
Latență: p95/p99 pe rute cheie ('/depunere ', '/pariu', '/joc/init ').
Erori: 5xx share/timeout.
Saturație/cozi: cozi de plată/tranzacție întârziate.

Afaceri SLI

Conversia plăților: 'succes/încercare'.
TTW p95: Timpul de la cererea de retragere la înscriere.
Jocul începe succesul: sesiuni de joc, inițializarea furnizorului.
Succesul fluxului KYC/AML.

3) Bugetul de eroare: cum se numără

Eroare buget = 1 − SLO.
Exemplu: Disponibilitate 99 SLO. 9 %/30d ⇒ buget de eroare = 0. 1% din timp ≈ 43min 12s într-o fereastră de 30 de zile.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO contează pe o fereastră glisantă (30/7/1 zi) și este vizibil pe tablouri de bord.

• „Arderea” rapidă a bugetului → înghețarea eliberărilor, oprim canarul, lucrăm la stabilitate.
• Stocul bugetar → permite modificări mai frecvente (controlate).

4) Exemple SLO pentru fluxurile cheie

• Disponibilitate ≥ 99. 9 %/30d
• Latenţă p95 '/depozit '≤ 250 ms/ 30д
• Conversia plăților ≥ − de bază 0. 3 %/24h
• TTW p95 (ieșire) ≤ 3 min/24h

• Joc de succes init ≥ 99. 5 %/ 7д joc p95 init ≤ 600 ms/ 7д

• Succesul postului ≥ 99 %/7e, lag <5 min (ferestre de vârf separat).

5) Măsurare: formule și PromQL (idei)

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) Alerte de burn-rate (multi-fereastră)

Ideea: comparăm rata actuală a consumului bugetar cu cea admisă.

• Ardere rapidă: bugetul 14 × într- 1 oră → pagină în 5-15 minute.
• Ardere lentă: 6 × bugetare în 24 de ore → bilet, analiza motivului.

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) Tablouri de bord "SLO-card' și sistemul de operare

• Carduri de serviciu: Disponibilitate, p95, Rata de eroare, Burn-rate, Soldul bugetului de eroare.
• Filtre: „env”, „regiune”, „chiriaș”, „versiune”.
• Adnotări de lansare: Git SHA, tip (canar/albastru-verde), timp de comutare.

• Comparație stabilă vs canar.
• Secțiunea de furnizori PSP/joc.
• Du-te la exemplare (trace_id) și jurnalele aferente.
• Coadă lag și saturație (UTILIZAȚI măsurători).

8) procese SLO: porți, îngheț, escaladări

Porți în CD: Promovarea Canare este permisă numai la efectuarea unui proxy SLO (disponibilitate, p95, suv).
Freeze: cu fast-burn sau soldul bugetar zero - se oprește eliberările până la recuperare.
Escaladare: Matricea SEV (plăți SEV1/depozite, jocuri SEV2, backhoe SEV3).
RCA: analiza fără taxe, actualizarea testelor/limitelor/phicheflags.

9) Date/ML-SLO (pentru recomandări/LLM)

Latență: model de răspuns p95 ≤ 300 ms (sau jetoane/s ≥ N).
Proxy de calitate: proporția de răspunsuri valide/toxicitate scăzută, cota de ajutor.
Prospețime: vârsta caracteristicilor/datelor ≤ ore X.
Cost pe 1k evenimente: cheltuieli în buget.
Porțile SLO sunt integrate în versiunile modelului (A/B/canar rollout).

10) SLA design bazat pe SLO

Alegeți SLO-uri conservatoare ca bază pentru SLA.
Definirea excepțiilor (activități planificate, furnizori externi dependenți, proceduri incidente).
Introduceți compensări prin niveluri de încălcare (credit/reducere), mecanisme de raportare și verificare.

11) Erori frecvente și anti-modele

Nu există SLO, doar „uptime 100%” este nerealist, demotivează și ascunde riscurile.
Alerte pentru „fiecare metrică” în loc de burn-rate - alertă-fatig și ignora.
Amestecarea PII în valori/jurnale pentru SLO - riscuri de conformitate.
Cardinalitatea explodează: 'user _ id/session _ id' ca etichete.
Lipsa adnotărilor de eliberare - este dificil să se asocieze degradarea cu schimbarea.
Buget de eroare opac - echipa nu înțelege când „puteți” să vă asumați riscuri.
SLO nu este legat de afaceri - măsurătorile tehnice sunt „verzi”, veniturile sunt „roșii”.

12) Lista de verificare a implementării

1. Aprobați SLI-urile de bază (disponibilitate, p95/p99, rata de eroare, TTW, conversie).
2. Setați SLO pe ferestrele de 30/7/1 zi și numărați bugetul de eroare.
3. Adăugați reguli de înregistrare și alerte arde (rapid/lent).
4. Construiți o hartă SLO cu adnotări de lansare și comparații canare/stabile.
5. Includeți porțile în CD: fără SLO-ok - fără promovare.
6. Introduceți procedurile de congelare și o matrice SEV de escaladare.
7. Link SLO-uri la metrici de afaceri (cont, TTW) și rute de plată.
8. Pentru Data/ML, definiți latența/calitatea/prospețimea-SLO.
9. Revizuiri regulate ale RCA și SLO/prag (trimestrial).
10. Documentul SLAs numai după SLO a stabilizat.

13) Exemple de obiective „gata” (ca început)

API general: Disponibilitate 99. 9 %/30d; p95 ≤ 250 ms/30d; Rata de eroare ≤ 0. 3 %/30d

Plăți: Conversia ≥ de referință − 0. 3 %/24h; TTW p95 ≤ 3 min/24h

Jocuri init: Succes ≥ 99. 5 %/7d; p95 ≤ 600 ms/7e

Backoffice jobs: Succes ≥ 99 %/ 7д; lag ≤ 5 min/7d

LLM/Reco: jetoane/s ≥ N, toxicitate viol. ≤ 0. 5 %/7d, prospeţime ≤ 6h.

Rezumat

Abordarea SLO/SLA transformă fiabilitatea din „mai bună decât ieri” într-o disciplină măsurabilă: SLI-uri transparente, un buget de eroare ușor de înțeles, alerte pentru viteza de ardere, tablouri de bord ușor de înțeles și porți de calitate încorporate în versiuni. Acest contur oferă platformei iGaming un previzibil p95/p99, plăți stabile și TTW, ceea ce înseamnă venituri mai bune și mai puține incidente în timpul celor mai fierbinți ore.