Practici SRE: implementarea unor SLO-uri care chiar funcționează

Service Level Objectives (SLO-urile) sunt în inima Site Reliability Engineering. Dar prea multe echipe le implementează greșit — fie le fac prea stricte (omorând viteza de livrare), fie prea laxe (fără sens). Iată cum le faci corect.

Ce sunt SLO-urile?

Să lămurim terminologia:

• SLI (Service Level Indicator) — O măsură cantitativă a calității serviciului (de ex. latență, rată de erori)
• SLO (Service Level Objective) — O valoare-țintă pentru un SLI (de ex. 99.9% din cereri < 200ms)
• SLA (Service Level Agreement) — Un contract cu consecințe dacă SLO-urile nu sunt atinse
• Error Budget — Cantitatea acceptabilă de nefiabilitate (1 - SLO)

Alegerea SLI-urilor potrivite

Cel mai important pas e să alegi ce măsori. Concentrează-te pe ce experimentează utilizatorii în realitate:

Pentru servicii API

Availability:  successful requests / total requests
Latency:       requests served < threshold / total requests
Throughput:    requests per second within normal range

Pentru pipeline-uri de procesare a datelor

Freshness:     time since last successful processing < threshold
Correctness:   valid outputs / total outputs
Coverage:      records processed / records expected

Stabilirea unor ținte SLO realiste

Iată un test de realitate pentru „nouari”:

SLO	Downtime/lună	Downtime/an
99%	7.3 ore	3.65 zile
99.9%	43.8 minute	8.76 ore
99.99%	4.38 minute	52.6 minute

Sfat practic: Începe cu un SLO mai mic decât crezi că ai nevoie. Poți oricând să-l faci mai strict, dar relaxarea unui SLO se simte ca un eșec.

Error budget-ul în practică

Error budget-ul e ceea ce face SLO-urile acționabile. Iată cum le folosim noi:

1. Buget rămas > 50% — Viteză maximă pe funcționalități
2. Buget rămas 20-50% — Crește rigoarea review-ului, încetinește schimbările riscante
3. Buget rămas < 20% — Concentrare pe îmbunătățiri de fiabilitate
4. Buget epuizat — Feature freeze până când bugetul se regenerează

Monitorizarea SLO-urilor

Folosim o combinație de Prometheus și Grafana pentru a urmări respectarea SLO-urilor:

# Error rate SLI
1 - (
  sum(rate(http_requests_total{code=~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
)

# Latency SLI (proportion of fast requests)
sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))

Greșeli frecvente

1. Prea multe SLO-uri — Începe cu 1-3 per serviciu
2. SLO-uri nelegate de experiența utilizatorului — Utilizarea CPU nu e un SLO
3. Fără politică de error budget — SLO-urile fără consecințe sunt doar dashboard-uri
4. Măsurarea lucrului greșit — Verificările sintetice ≠ experiența reală a utilizatorului
5. Setează și uită — SLO-urile ar trebui revizuite trimestrial

Construirea unei culturi SLO

Partea cea mai grea nu e implementarea tehnică — e schimbarea culturală. Iată ce recomandăm:

• Fă SLO-urile vizibile — Dashboard pe un ecran mare în birou
• Sărbătorește consumul de error budget — Dacă folosești bugetul, înseamnă că inovezi
• Postmortem-uri fără vinovați — Învață din incidente, nu căuta vinovați
• Susținerea conducerii — Leadership-ul trebuie să înțeleagă compromisurile

Ai nevoie de ajutor?

Implementarea practicilor SRE e un drum, nu o destinație. La Kicked, ajutăm echipele să adopte practici SRE pragmatice și sustenabile. Hai să vorbim despre obiectivele tale de fiabilitate.