SLO/SLA și Metrics

SLO/SLA și metrici

1) Termeni și ierarhie

SLI (Service Level Indicator) - un indicator măsurabil „așa cum ne vede utilizatorul”: ponderea cererilor de succes, latența p95, prospețimea datelor, ponderea loturilor prelucrate cu succes etc.

SLO (Service Level Obiectiv) - țintă valoare SLI la intervalul de observație (28/30/90 zile). Exemplu: "99. 9% din cereri/plata se încheie ≤ 400 ms'

Bugetul de eroare - 1 − SLO. La SLO 99. 9% buget de eroare = 0. 1% din timp/cereri.
SLA (Acord) - nivel de servicii semnificativ din punct de vedere juridic: include SLO, măsurare, excepții, compensații/amenzi.

2) Principii de proiectare

Simptome> valori interne. SLI-urile ar trebui să reflecte experiența reală a utilizatorilor.
Număr mic de SLI-uri cheie. Pentru service - 2-5 principale: succes, latență, debit/prospețime, corectitudine.
Acoperirea căilor critice. Fiecare scenariu de afaceri (checkout, login, webhook, ETL download) are propriul set de SLI/SLO.
Semantică strictă de succes. Nu „cod 200”, ci „utilizatorul a primit un răspuns la timp și rezultatul este valabil”.
Separarea SLO-urilor externe și interne. Interne - mai stricte; SLA extern ≤ 1-2 nouari mai mici.

3) SLI catalog (referință)

3. 1 API/Servicii Online

Succes: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Latență: p95/p99 'http _ server _ duration _ seconds' după traseu/metodă/chiriaș

Lățime de bandă: „RPS ”/limite/cote

Corectitudine: proporția răspunsurilor valide (semnături, scheme, invarianți)

3. 2 Webhooks/Livrări asincrone

Livrare: proporția evenimentelor confirmate în secunde T și retribuții ≤ N

Clienți: procent de abonați fără întârziere îndelungată (per chiriaș)

3. 3 Date/ETL/DWH

prospețime: "acum − last_successful_ingest_ts'

Completitudine: 'ingested _ rows/ expected_rows'

Corectitudine: proporția de înregistrări care au trecut controalele de calitate

Conducte: ponderea locurilor de muncă finalizate înainte de termen

3. 4 SDK-uri mobile/client

Succesul clientului: proporția de sesiuni fără erori fatale

Latență dus-întors: p95 de la cerere la randare

Cache hit-uri: procentaj servit din memoria cache (ca simptom al performanței)

4) Formule și exemple de obiective

• 'SLI _ req _ avail = 1 − (failed_requests/ total_requests)'
• 'SLO _ req _ avail = 99. 95% "pentru 30 de zile → buget de eroare = 0. 05% din cereri.

• 'uptime = (obs_window − downtime )/ obs_window'

• 'SLO _ latency = p95 (route = „/pay ”) ≤ 400 ms' pe felii de 7 zile, cu excepția warm-up-urilor cache (1%)

• 'SLO _ prospețime (set de date = „comenzi”) ≤ 10 min' p99 în 24 de ore.

5) Bugetul de eroare și gestionarea schimbărilor

Buget (B): „B = 1 − SLO”.
Burn - Raportul dintre erorile reale și erorile admisibile.

• Cheltuieli suplimentare (arde> 1) → caracteristică îngheață, se concentreze pe fiabilitate.
• La rata de ardere> X în fereastră scurtă - incident și capac. măsuri.
• Planificare: Partea de fiabilitate a sprintului se corelează cu arderea în ultima perioadă.

6) Alertare: rata de ardere și reguli multi-fereastră

Ideea: prindem scurgeri rapide și derivă lent.

• Critic: „2% buget într- 1 oră” (foc rapid).
• Avertisment: „5% din buget în 6 ore” (degradare târâtoare).

• Fereastră scurtă (minut-oră) pentru incidente rapide.
• Fereastră lungă (6-24 ore) pentru tendințe.
• Latență: alertă prin p99> prag ≥5 min, cu suprimarea flapping și comunicarea cu urme instanțe.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Multi-chiriaș și segmentare

SLI/SLO sunt numărate în funcție de chiriași/planuri/regiuni, în caz contrar mediana va „acoperi” eșecurile.
Numărul minim de evenimente cu semnificație statistică (șine de pază).
SLA poate varia în tarife (de exemplu, "Pro 99. 9%, Gratuit 99. 5%»).

8) Asocierea cu observabilitate și urme

Metrici SLI - de la histograme/contoare cu exemplare → tranziție la trasee „rele”.
Jurnalele sunt sursa motivelor: timeout-uri, coduri de eroare de afaceri, limite.
Pentru date - o legătură cu descendența: „care loc de muncă întârziat metric prospețime”.

9) Contracte și SLA-uri

• SLI/metoda de măsurare/definițiile ferestrei.
• Excepții (muncă planificată, forță majoră).
• Procedura de incident și comunicare (pagina de stare, RFO/RCA).
• Credite de serviciu și comanda de cerere.
• Jurisdicție, perioadă de valabilitate, termeni de revizuire.

• Nu promiteți niciodată public SLO-uri mai stricte decât arhitectura și practicile operaționale permit.
• SLO-uri interne separate și SLA-uri externe.

10) Costuri și prioritizare

Prețul de nouari nu crește liniar. «99. 9% → 99. 99%" = clasă de arhitectură diferită (N + 1, multi-zonă, activ-activ).
Puneți SLO-urile pe cele mai valoroase acțiuni ale utilizatorilor.
Controlați costul telemetriei - sub-eșantionare, cote, replica, și de stocare pe clasă.

11) Proceduri și raportare

Rapoarte săptămânale: executarea SLO de către serviciu/chiriaș, cheltuieli bugetare, motive de top, planuri de îmbunătățire.
Post-incident RCA: ne asociem cu bucăți din buget; stabilim sarcini pentru a elimina cauzele profunde.
Fichfriz: criterii de includere/retragere.

12) Șabloane (pentru un început rapid)

12. 1 card SLO (exemplu)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. Tabelul de maturitate 2 SLO

13) Exemple de reguli (fragmente)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO pentru date și ML (caracteristici)

SLO-uri de date end-to-end: p99 prospețime, p99 completitudine, post-crash „reprocesare” timp.
Contracte de date: scheme preconizate, volume, termene limită; încălcarea datelor → incident.
ML: SLO pentru latența de deducție, SLA pentru disponibilitatea storului de caracteristici, monitorizarea derivei (calitatea modelului este un subiect separat, în afara SLA).

15) Integrarea cu securitatea și confidențialitatea

jurnale SLI fără PII/secrete; tokenizare/mascare.
Modificări de audit la SLO/SLA și publicații de raport în jurnale imuabile.
Pentru căile de reglementare (plăți/PII) - SLO-uri separate și mai stricte.

16) Liste de verificare

Înainte de a începe serviciul/caracteristicile

• SLI-uri de succes/latență/debit/prospețime definite.
• SLO și ferestre definite; se calculează un buget de eroare.
• Setați alerte burn-rate (scurt + lung).
• Tablouri de bord RED + exemplare → rute; runibooks incident.
• Secțiuni multi-leasing și praguri de semnificație.
• Fichfreeze și procedura de raportare.

Funcționare

• SLO/arde raportul săptămânal, planuri de întărire.
• Reevaluați SLO atunci când se schimbă arhitectura/sarcina.
• Periodice „incidente de foraj” și actualizări runibook.
• Monitorizați costul telemetriei și numărul SLI.

17) Runbook'и

Runbook: Creștere rapidă p99/pay

1. Alertă p99> prag → deschide un tablou de bord → du-te prin exemplar pentru a urmări.
2. Găsiți o perioadă îngustă CLIENT/SERVER, comparați regiuni/versiuni.
3. Activați degradarea (cache/limit/rezervă), notificați comanda de dependență.
4. După stabilizare - RCA, sarcini de optimizare, actualizarea măsurătorilor SLO.

Runbook: cheltuieli bugetare> 50% pentru săptămână

1. Înghețați caracteristicile, ridicați prioritatea de fiabilitate.
2. Gruparea erorilor: pe rute/chiriași/dependențe.
3. Introduceți corecții → confirmați recuperarea tendinței.
4. Ajustare retrospectivă și de alertă/prag.

18) ÎNTREBĂRI FRECVENTE

Î: De câte SLO-uri ai nevoie?
R: Minim pe scenariile critice ale utilizatorilor: succes + latență. Orice altceva nu este necesar.

Î: Care este mai bună - disponibilitate la timp sau la cerere?
R: La cerere - mai multă metrică pentru utilizatori. Timpul este convenabil pentru componentele de rețea/infra.

Î: De ce p95, nu medie?
R: Cel mijlociu ascunde coada; utilizatorul se simte p95/p99.

Î: Cum să nu „strângeți șuruburile” prea mult?
R: Începeți cu obiective realiste (date istorice), apoi strângeți pe măsură ce vă maturizați.

• „Observabilitate: busteni, metrici, urme”
• „Urme distribuite”
• „Audit și jurnale imuabile”
• „Garanții de livrare prin broșură web”
• „În tranzit/În repaus criptare”
• „Originea datelor (Lineage)”