Monitorowanie SLO, SLA i niezawodności

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

SLO to wewnętrzny cel jakości, SLA to zewnętrzne zobowiązanie wobec klienta, SLI to sposób mierzenia jakości. W iGaming, kluczowe SLIs: API i dostępność płatności, p95/p99 opóźnienie tras krytycznych, Time-to-Wallet (TTW), konwersja płatności, uruchomienie gry, i metryki kolejki. Zarządzanie niezawodnością jest zbudowane wokół budżetu błędów, wielokrotnych wpisów, jasnych bram i wizualnych desek rozdzielczych z adnotacjami.

1) Terminy i różnice

SLI (Service Level Indicator) - mierzony wskaźnik (np. odsetek udanych wniosków w każdym oknie czasowym).
SLO (Cel poziomu usług) - docelowa wartość SLI (np. "dostępność 99. 9% w ciągu 30 dni").
SLA (umowa o poziomie usług) - umowa/odpowiedzialność z odszkodowaniem; jest oparty na prawdziwych SLO, ale zawiera klauzule prawne i planowane okna konserwacji.

Zasada: najpierw ustabilizować SLI/SLO wewnątrz, a dopiero potem naprawić SLA na zewnątrz.

2) Ramy SLI dla iGaming

TexSLO

Dostępność: udane 2xx/3xx/wszystkie żądania.
Opóźnienie: p95/p99 na kluczowych trasach ('/deposit ', '/bet', '/game/init').
Błędy: 5xx share/timeouts.
Nasycenie/kolejki: opóźnione kolejki wypłat/transakcji.

Business SLI

Konwersja płatności: „sukces/próba”.
TTW p95: Czas od żądania wypłaty do rejestracji.
Sukces początkowy gry: sesje gier, inicjalizacja dostawcy.
Sukces przepływu KYC/AML.

3) Budżet błędu: jak liczyć

Budżet błędu = 1 − SLO.
Przykład: Dostępność 99 SLO. 9 %/30d „budżet błędu” = 0. W 30-dniowym oknie 1% czasów43min 12s.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO liczy na przesuwane okno (30/7/1 dzień) i jest widoczne na deskach rozdzielczych.

• Szybkie „spalanie” budżetu → zamrożenie zwolnień, zatrzymujemy kanaryjskie, pracujemy nad stabilnością.
• Zasoby budżetowe → pozwalają na częstsze zmiany (kontrolowane).

4) przykłady SLO dla przepływów kluczowych

• Dostępność ≥ 99. 9 %/30d
• Opóźnienie p95 '/depozyt '≤ 250 ms/30
• Konwersja płatności ≥ wartość wyjściowa − 0. 3 %/24h
• TTW p95 (wyjście) ≤ 3 min/24h

• Sukces w grze init ≥ 99. 5 %/7 ° p95 init gry ≤ 600 ms/7

• Sukces pracy ≥ 99 %/7e, lag <5 min (okna szczytowe oddzielnie).

5) Pomiar: formuły i PromQL (pomysły)

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) Alerty spalania (wielopoziomowe)

Pomysł: porównujemy obecny wskaźnik konsumpcji budżetowej z dopuszczalnym.

• Szybkie oparzenie: 14 budżet × w 1 godzinę → strona w 5-15 minut.
• Powolne oparzenie: 6 budżet × w 24 godziny → bilet, analiza powodów.

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) Deski rozdzielcze „SLO-card” i system operacyjny

• Karty serwisowe: Dostępność, p95, wskaźnik błędów, wskaźnik oparzeń, saldo budżetu błędu.
• Filtry: 'na', 'region', 'lokator', 'wersja'.
• Adnotacje wydania: Git SHA, typ (kanaryjski/niebiesko-zielony), czas przełączania.

• Stabilne porównanie z kanarkami.
• Sekcja przez PSP/dostawców gier.
• Przejdź do przykładów (trace_id) i pokrewnych dzienników.
• Kolejka opóźnienia i nasycenia (metryki USE).

8) Procesy SLO: bramy, zamrożenie, eskalacje

Bramki w CD: Promocja kanaryjska jest dozwolona tylko przy wykonywaniu serwera proxy SLO (dostępność, p95, conv).
Zamrożenie: z szybkim lub zerowym saldem budżetowym - wstrzymanie zwolnień do czasu odzyskania.
Eskalacja: matryca SEV (SEV1 płatności/depozyty, gry SEV2, SEV3 backhoe).
RCA: analiza bez opłat, testy aktualizacyjne/limity/ficheflagi.

9) Dane/ML-SLO (dla rekomendatorów/LLM)

Opóźnienie: model odpowiedzi p95 ≤ 300 ms (lub żetony/s ≥ N).
Proxy jakości: odsetek ważnych odpowiedzi/niska toksyczność, udział pomocny.
Świeżość: wiek funkcji/danych ≤ X godzin.
Koszt na 1k imprezy: wydatki w budżecie.
Bramki SLO są zintegrowane z wersjami modelowymi (A/B/rollout kanaryjski).

10) Projekt SLA oparty na SLO

Wybierz konserwatywne SLO jako podstawę dla SLA.
Określić wyjątki (planowane działania, zewnętrzni dostawcy zależni, procedury incydentów).
Wprowadź kompensaty według poziomów naruszenia (kredytu/rabatu), mechanizmów sprawozdawczości i weryfikacji.

11) Częste błędy i anty-wzory

Nie ma SLO, tylko „uptime 100%” jest nierealistyczne, demotywuje i ukrywa zagrożenia.
Wpisy dla „każdej metryki” zamiast spalania - alert-fatig i ignorować.
Mieszanie PII w metrykach/dziennikach dla SLO - ryzyko zgodności.
Kardynalność eksploduje: 'user _ id/session _ id' jako etykiety.
Brak adnotacji o uwolnieniu - trudno kojarzyć degradację ze zmianą.
Nieprzezroczysty budżet błędu - zespół nie rozumie, kiedy „można” podjąć ryzyko.
SLO nie jest związany z biznesem - metryki techniczne są „zielone”, dochody są „czerwone”.

12) Lista kontrolna wdrażania

1. Zatwierdza podstawowe SLIs (Dostępność, p95/p99, Wskaźnik błędów, TTW, Konwersja).
2. Ustaw SLO na oknach 30/7/1 dnia i policz budżet błędu.
3. Dodaj reguły nagrywania i alerty prędkości spalania (szybkie/wolne).
4. Zbuduj mapę SLO z adnotacjami wydania i kanaryjskimi/stabilnymi porównaniami.
5. Dodaj bramki w CD: bez SLO-ok - bez promocji.
6. Wprowadź procedury zamrażania i macierz SEV eskalacji.
7. Powiązanie SLO z metrykami biznesowymi (conv, TTW) i trasami płatniczymi.
8. Dla danych/ML należy zdefiniować opóźnienie/jakość/świeżość-SLO.
9. Regularne RCA i korekty SLO/progowe (kwartalne).
10. Dokumenty SLA dopiero po ustabilizowaniu SLO.

13) Przykłady „gotowych” celów (jako początek)

API ogólne: Dostępność 99. 9 %/30d; p95 ≤ 250 ms/30d; Wskaźnik błędu ≤ 0. 3 %/30d

Płatności: konwersja ≥ wartość wyjściowa − 0. 3 %/24h; TTW p95 ≤ 3 min/24h

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

Zaległe miejsca pracy: sukces ≥ 99 %/7 °; lag ≤ 5 min/7d

LLM/Reco: żetony/s ≥ N, toksyczność viol ≤ 0. 5 %/7d, świeżość ≤ 6h.

Podsumowanie

Podejście SLO/SLA zamienia niezawodność z „lepszej niż wczoraj” w mierzalną dyscyplinę: przejrzyste SLIs, zrozumiały budżet błędu, wpisy dotyczące prędkości spalania, zrozumiałe deski rozdzielcze i bramy jakości wbudowane w wydania. Ten kontur daje platformie iGaming przewidywalne p95/p99, stabilne płatności i TTW, co oznacza lepsze przychody i mniej incydentów w najgorętszych godzinach.