SLA, SLO și KPI de fiabilitate

1) Termeni și diferențe

SLI (Service Level Indicator) - un indicator măsurabil al calității (de exemplu, proporția de solicitări de succes, latență p95).
SLO (Service Level Obiectiv) - țintă valoare SLI pe fereastră de timp (de exemplu, "succes ≥ 99. 9% în 28 de zile").
Bugetul de eroare - Rata de eșec SLO permisă este „1 − SLO”.
SLA (Service Level Agreement) - obligatii contractuale cu amenzi/credite (externe).
KPI-uri de fiabilitate - metrici de proces operaționale (MTTD/MTTA/MTTR/MTBF,% atenuare automată, acoperire de alertă etc.).

2) Cum de a alege SLI (bazat pe semnale de aur)

1. Latenţă - p95/p99 pentru criteriile finale cheie.
2. Trafic - RPS/RPM/fluxul de mesaje.
3. Erori - cota de erori 5xx/de afaceri (de exemplu, exclude plata "declin din cauza defectului PSP).
4. Saturație - saturație de resurse (CPU/RAM/IO/lag).

• Se corelează cu experiența percepută de utilizator.
• Tehnic disponibil și stabil în măsurare.
• Noi controlăm (sunt posibile acțiuni de îmbunătățire).
• Cost redus de colectare.

3) Formule și exemple

3. 1 Disponibilitate

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Exemplu: SLO 99. 9% în 30 de zile → buget de eroare = 0. 1%, echivalentul a 43 min 12 sec de indisponibilitate.

3. 2 Latenţă

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Plăți (nivel de afaceri)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Buget defectuos și rata de ardere

Eroare de buget - „rezervorul de combustibil” pentru inovare (versiuni, experimente).

• canal rapid (detectare în ~ 1 h),
• canal lent (tendință pe ~ 6-12 h/24 h).

• Dacă rata de ardere> 14. 4 într-o oră - SEV-1 (vom mânca bugetul zilnic în ~ 100 de minute).
• Dacă rata de ardere> 6 în 6 ore - SEV-2 (degradare rapidă).

5) Alertarea prin SLO (multi-fereastră, multi-arde)

Indicator de eroare: proporția de încălcări 5xx sau latență.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) SLI/SLO Exemple de domeniu

6. 1 API Gateway/Edge

Erori SLI: rata de răspuns 5xx <0. 1% (28d).
SLI-Latenta: p95 ≤ 250 ms (zi).
SLO: Disponibilitate ≥ 99. 95% (trimestru).

6. 2 Plăți

SLI-Succes: plata pentru succes (cu excepția eșecurilor clienților) ≥ 99. 8% (28d).
SLI-Latency: autorizație ≤ 2 secunde pentru 99% (zi).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Baze de date (PostgreSQL)

SLI-Lag: replicare lag p95 ≤ 1 sec (zi).
Erori SLI: Rata de eroare de interogare ≤ 0. 05% (28d).
Disponibilitate cluster SLO ≥ 99. 95%.

6. 4 Cozi/Streaming (Kafka)

SLI-Lag: consumator lag p95 ≤ N mesaje (oră).
SLI-Durabilitate - Confirmați intrarea ≥ 99. 99% (28d).
SLO: disponibilitatea brokerilor ≥ 99. 9%.

7) Procesul de fiabilitate KPI

MTTD (Timpul mediu de detectare)

MTTA (... Pentru a recunoaște)

MTTR (... Pentru a restabili)

MTBF (... Între eșecuri)

% din incidentele cu atenuare automată

Acoperirea SLO/alertă a căilor de trafic de top (țintă ≥ 95%)

Cota de versiuni cu stadiul canar

Consumul de buget eronat pe echipe/caracteristici

8) Cum de a pune SLO realist

1. Măsuraţi fiabilitatea iniţială curentă (3-4 săptămâni).
2. Definiți căile de utilizator „sensibile” (conectare, depunere, joc).
3. Luați în considerare costul fiecărei abateri (timp, bani, reputație).
4. Alegeți un obiectiv ambițios, dar realizabil (îmbunătățirea cu 10-30% a scenariului de referință).
5. Revizuire trimestrială.

• Imediat „cinci nouari” fără justificare.
• SLO prin măsurători care nu sunt vizibile pentru utilizator (de exemplu, CPU fără comunicare cu UX).
• Prea mult SLO → focalizare spray.

9) SLO și raportarea bugetară

• Finalizarea per SLO: țintă reală vs, tendințe, încredere.
• Rezumatul consumului de erori: cât buget este "ars' decât de către cine (eliberare/incident).
• Top cinci cauze de degradare, planul CAPA și starea sarcinii.
• Impactul afacerii: conversie, ND, retenție, LTV.

10) Comunicare cu politica de lansare

Buget de eroare <50% → versiuni gratuite.
50-80% → „mod precaut”: numai calcule cu risc scăzut/canar.

11) SLA (contractual) - șabloane de elemente

Obligația de disponibilitate: de exemplu, 99. 9 %/lună.
Forță majoră: DDoS dincolo de un control rezonabil, furnizori terți.
Fereastra de măsurare și aria de responsabilitate: surse de valori, metoda de calcul.
Credite/penalități: un tabel de niveluri (de exemplu, indisponibilitatea 60-120 minute → credit X%).
Proceduri de escaladare și notificare: termene limită, canale.
Date și confidențialitate: mascare, stocare, Legal Hold.
Planul de prevenire a repetării (CAPA) în caz de încălcare.

12) Instrumente de măsurare

Valori pasive: Prometheus/Mimir/Thanos, exportatori.
Jurnale: Loki/ELK pentru numărarea succeselor/erorilor la nivel de afaceri.
Sintetice: mostre active (login/depunere/joc) de cron.
Urmărire: Tempo/Jaeger pentru blocaje p99.
Plată/Finanțe: surse de adevăr la sol pentru plata SLI.

13) Exemple de interogare (șabloane)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

cheie> Rafinați filtrele pentru a exclude „declinul de către client”.

14) FinOps și fiabilitate

Costul per 9: Costul adăugării unui nouă crește exponențial.
Curba beneficiilor: optimă în cazul în care creșterea veniturilor/scăderea pierderilor ≥ costul suplimentar „9”.
Portofoliul SLO: niveluri diferite pentru diferite căi (plățile critice sunt „mai scumpe”, raportarea este „mai ieftină”).

15) SLO/Alert Quality - Lista de verificare

• SLI se corelează cu valorile UX și de afaceri.
• Fereastra și agregarea sunt consecvente (rulare 28d/trimestru).
• Alerte multi-fereastră, fără flapping, rutare pe bază de rol.
• Documentație: proprietar, formulă, surse, runbook.
• SLO panou demo cu buget eronat și indicatori de ardere.
• Revizuirea regulată a obiectivelor (trimestrial).
• Teste sintetice pe scenarii cheie.

16) Planul de implementare (4 iterații)

1. Săptămâna 1: inventarul căilor de utilizare, schițe SLI, tablouri de bord de bază.
2. Săptămâna 2: formalizare SLO, bugetare, alerte (ardere rapidă/lentă).
3. Săptămâna 3: integrarea cu procesul de incident/eliberare, înghețarea regulilor.

4. Săptămâna 4 +: SLA contractuale, Revizuiri trimestriale, „costul pe 9” Modelul Finops

17) Mini-Întrebări frecvente

Trebuie să am un SLO pentru fiecare serviciu?
Mai bine 2-3 cele cheie (succes + latență) în loc de zeci de cele secundare.

Dacă bugetul este epuizat?
Eliberări de congelare, concentrându-se pe stabilizare și CAPA, eliminarea caracteristicilor experimentale.

Cum să evitați un conflict între viteza de eliberare și fiabilitate?
Planul lansează „la buget”, implementează calcule canare și caracteristici-steaguri.

Rezultat

Fiabilitatea nu este controlată de un set de valori disparate, ci de sistem: SLI SLO eroare bugetară arde procesul de alertare incidente CAPA SLA. Standardizați definițiile, sursele de date și raportarea, legați obiectivele de experiența utilizatorului și economie și revizuiți periodic nouăsprezece bazate pe ROI din lumea reală.