Bugete de eroare și SLO Management

1) De ce SLO și bugetul de eroare

SLO (Service Level Obiectiv) - nivelul calității țintă perceput de utilizator; SLI - metrică măsurată; Eroare Buget - toleranță pentru abateri pe fereastră (de obicei 30/90 zile).
Bugetul de eroare transformă fiabilitatea dintr-o „abstracție” într-o resursă gestionată: când bugetul arde rapid, înghețăm caracteristici și chinim; atunci când bugetul este sănătos - puteți accelera eliberările.

2) SLI alege: Ceea ce contează ca „bun”

Criteriu: „succes din punctul de vedere al utilizatorului”.

2. 1 SLI-uri clasice

Disponibilitatea este procentul cererilor de succes (cu excepția celor anulate de client).
'suckess = http_status ∈ {2xx, 3xx, 404} și fără timeout' (404 poate fi considerat un succes API citit dacă este de așteptat semantică).
Latență: proporția cererilor este mai rapidă decât pragul (de exemplu, p95 ≤ 300 ms).
'good _ latency = duration_ms ≤ 300'.
Prospețime/rezistență: „date nu mai vechi de X minute” (cache, directoare, coeficienți).
Calitate: corectitudinea rezultatului (trecere validatori de afaceri/invarianți backend).

2. 2 Limite și segmente

SLI ar trebui să fie numărate prin felii importante: „rută”, „chiriaș/marcă”, „regiune/jurisdicție”, „payment _ provider”. Deci, nu va „frotiu” eșecul unui mâner critic în întregul sistem.

3) Formule și buget

3. 1 Cerere-based (preferat pentru API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Bazat pe timp (pentru servicii de fundal/streaming)

SLO_uptime = good_minutes / total_minutes

3. 3 Exemplu de obiective

API general: 99. 9% disponibilitate în 30 de zile → buget = 0. 1%.
Pixuri de plată critice: 99. 95%; cataloage/căutare: 99. 5%.
Latență: p95 ≤ 300 ms la "/v1/payments', p99 ≤ 800 ms.

4) SLI instrumentație

4. 1 Principii

Busteni/trasee → RED (Rata/Erori/Durata) metrici cu găleți explicite.
Asigurați-vă că puneți "chiriaș", "regiune", "route _ class' (fără PII).
Numărați două valori: „succes” și „total”, și pentru latență, „rapid” și „total”.

4. 2 Prometeu exemplu (rata pe 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alerte prin rata de ardere (multi-fereastră, multi-arde)

5. 1 Idee

Ne uităm la cât de repede bugetul arde în raport cu obiectivul. Dacă viteza este mare pe o fereastră scurtă și lungă, semnalizăm.

5. 2 Profile prag (pentru SLO 99. 9%)

Paginare: rata de ardere ≥ 14. 4 × (10% din buget timp de 1 oră și 5% timp de 6 ore).
Bilet: rata de ardere ≥ 6 × (2% în 6 ore și 1% în 24 de ore).

5. 3 Reguli de exemplu (Prometeu, pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Similar pentru 6h/24h pentru bilet.

6) Biroul de Buget: Procese

6. 1 Porti de eliberare

Dacă soldul bugetului este <25% și tendința este negativă - „cod-îngheț” pe caracteristici, prioritatea este SRE/stabilitate.
Lansările Canare trebuie să aibă o felie SLO separată ("implementare. mediu =” canar”).

6. 2 Prioritizarea restanțelor

Distribuiți capacitatea de comandă proporțională cu rata de ardere și impactul asupra veniturilor.
Justificați datoria tehnică cu valori: „fixați X va reduce rata de ardere cu Y%”.

6. 3 Post-incident

Fiecare incident - RCA și „fix care nu poate fi rulat înapoi” (acționabil), control „sa întors la SLO”.

7) SLO ca cod

7. 1 Exemplu manifest SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Generarea regulilor

Utilizați generatoare (slo-generator, pyrra, leneș) pentru a crea automat reguli, tablouri de bord și rapoarte.

8) SLO degradare și protecție

Load shedder: dă răspunsuri rapide fără dependențe „scumpe” la vârf.
Cache & vechi: „vechi-în timp ce-revalidate” для citit.
Rate/Limite de concurență: protejează backendurile; rute importante - prioritate.
Circuit/Timeout: temporizări rapide și ramuri „de rezervă”.
Caracteristică steaguri: dezactivarea caracteristici grele cu un singur buton.

9) Observabilitate pentru SLO

Tablouri de bord: SLO real vs țintă, soldul bugetar, rata de ardere, contribuția pe rute/furnizori.
Corelație: de la „gaura” SLO → la exemplar → o anumită urmă → bușteni/profile.
Rapoarte: săptămânal - tendințe, consum bugetar, motive de top pentru degradare.

10) Antipattern

Un SLO „global” pentru întreaga → măști probleme. Segment.
«99. 99% pe tot" excluzând costul și realitatea. Alegeți obiective din experiența utilizatorului.
CPU/heap alerte în loc de rata de ardere/SLO.
Ignorarea redirecționărilor 4xx/lungi care strică UX.
Fereastră opacă (laminare vs calendar) - comparații de „mere cu portocale”.

11) Specificul iGaming/Finanțe

Căi bănești (depozite/retrageri): SLO-uri individuale peste nivelul general (de ex. 99. 95% disponibilitate; p95 ≤ 250 ms).
Furnizori PSP/KYC: SLO pentru fiecare furnizor + alerte pentru contribuția lor la ardere; comutare automată a traseului (rutare inteligentă).
Jurisdicții/chiriași: SLO-uri și bugete după „regiune/jurisdicție/marcă”, astfel încât o problemă locală să nu „inunde” metrica globală.
Joc responsabil: SLO pentru perioada de aplicare a limitelor/autoexcluderii (formule de conformitate).
Audit/reglementare: păstrați rapoartele SLO și incidente; transparența auditurilor interne.

12) Lista de verificare Prod Readiness

• SLI-urile (disponibilitate/latență/calitate/prospețime) și segmentele (rută/chiriaș/regiune) sunt definite.
• Obiectivele (SLO) sunt realiste, aliniate la afaceri; există ferestre rulante 30/90 zile.
• Alerte prin rata de ardere cu mai multe ferestre (paginare/bilet).
• SLO ca cod (regula/generator tablou de bord); rapoarte bugetare.
• Porțile de eliberare sunt legate de restul bugetului; secțiuni canare.
• Mecanismele de degradare (vărsare, cache vechi, circuit, limite) sunt implementate și testate.
• Metrics ↔ trasee corelație, cărți clare.
• Căi financiare/jurisdicționale - SLO/alerte separate; PSP/KYC sunt dezagregate.
• Incident regulat retro și arde pe bază de investiții de fiabilitate.

13) TL; DR

Definiți SLI-urile după valoarea utilizatorului, setați SLO-uri realiste și gestionați prin bugetul de eroare și rata de inscripționare cu mai multe ferestre. Activați SLO-as-code, eliberați porțile și degradarea conform planului. Segment dupa traseu/chirias/regiune; pentru căile de bani să păstreze obiective mai stricte și alerte separate.