SLI: ce metrici alegi și de ce contează ce măsori, nu câte

Un SLI (Service Level Indicator) este o măsurătoare care surprinde un singur aspect al fiabilității unui serviciu, din perspectiva utilizatorului. Este numărul brut pe baza căruia decizi dacă serviciul a funcționat la nivelul așteptat. Un SLI bun răspunde la întrebarea „a reușit utilizatorul să facă ce a vrut?" nu „cât de ocupat era sistemul?".

Confuzia frecventă este că orice metrică operațională ar fi un SLI. CPU-ul, memoria, lungimea cozii interne sunt metrici de sistem, utile pentru diagnosticare, dar nu reflectă experiența utilizatorului. Un SLI prost ales îți poate da impresia că totul merge bine exact când utilizatorul nu poate folosi aplicația.

Ce este un SLI mai exact?

Un SLI este un raport sau o valoare numerică care măsoară o singură dimensiune a comportamentului unui serviciu, calculat pe o fereastră de timp definită, din perspectiva celui care consumă serviciul. Definiția formală vine din practica site reliability engineering: un SLI este un indicator selectat atent pentru că schimbarea lui contează pentru utilizator.

Două caracteristici care separă un SLI corect de o metrică operațională obișnuită:

• Este calculat din perspectiva utilizatorului. Dacă un serviciu răspunde intern în 50 ms dar rețeaua adaugă 2 secunde, un SLI calculat din interiorul serverului raportează 50 ms, ceea ce nu reflectă ce a experimentat utilizatorul. Un SLI corect măsoară de la marginea sistemului spre exterior, nu din interior spre interior.
• Este specific și limitat. Un SLI acoperă o singură dimensiune: fie disponibilitate, fie latență, fie rată de erori. Agregarea mai multor dimensiuni într-un singur număr pierde informație; un serviciu cu disponibilitate perfectă dar latență dezastruoasă ar părea acceptabil dacă le-ai combina.

Termenul apare în contextul SLO-urilor și SLA-urilor: SLI este măsurătoarea brută, SLO este ținta pe care o stabilești pe baza SLI-ului, SLA este contractul care expune o parte din acea țintă clienților.

Care sunt tipurile principale de SLI?

Cinci categorii acoperă majoritatea serviciilor. Fiecare măsoară o dimensiune diferită a experienței utilizatorului:

• Disponibilitate (availability). Raportul dintre cererile reușite și totalul cererilor, pe o fereastră definită. O cerere este reușită dacă a returnat un răspuns valid (non-5xx) în limita de timp așteptată. Exemplu: 99,92% din cererile HTTP pe 30 de zile returnate în sub 2 secunde.
• Latență (latency). Durata procesării unei cereri, măsurată ca percentile (p95, p99), nu ca medie. Media ascunde cozile. Percentila 95 surprinde experiența utilizatorilor care nu au noroc, nu a celor care prind momentul bun.
• Rată de erori (error rate). Procentul cererilor terminate cu eroare. De obicei 5xx pentru HTTP, sau orice răspuns care semnalează că serviciul n-a putut onora cererea. Distinct de disponibilitate: un serviciu poate fi disponibil și totuși să returneze erori pentru un subset de cereri.
• Debit (throughput). Numărul de cereri pe unitate de timp procesabile menținând celelalte SLI-uri în parametri. Relevant pentru servicii cu obligații de procesare batch: dacă debitul scade, serviciul nu mai livrează la ritmul promis chiar dacă cererile individuale reușesc.
• Prospețimea datelor (freshness). Vârsta maximă a datelor servite față de sursa de adevăr. Un SLI de freshness ar putea fi „datele afișate au cel mult 4 ore în 99% din cazuri". Fără el, un pipeline oprit silențios nu declanșează nicio alertă până când utilizatorul observă că vede prețuri de ieri.

Cum alegi un SLI care reflectă experiența utilizatorului, nu performanța sistemului?

Testul practic: pune-te în locul utilizatorului și formulează o propoziție de forma „m-am dus la serviciu ca să fac X și am reușit sau nu am reușit". Din acea propoziție, extrage ce definește reușita. De obicei: serviciul a răspuns, a răspuns corect și a răspuns suficient de repede. Acestea devin disponibilitate, rată de erori și latență.

Greșeala clasică este să pornești de la metricile ușor de colectat, nu de la ce contează pentru utilizator. CPU, memoria și lungimea cozii interne sunt vizibile imediat în orice dashboard de observabilitate, dar utilizatorul nu experimentează direct niciuna dintre ele. Un serviciu cu CPU la 10% care returnează 5xx la fiecare a treia cerere nu are SLI-uri bune, chiar dacă toate metricile de sistem arată verde.

• Pornește de la incidente, nu de la dashboarduri. Ultimele cinci incidente care au supărat utilizatorii: ce nu a funcționat? Aceea este dimensiunea de măsurat.
• Preferă SLI-uri calculate din afara sistemului. Un monitor extern este mai onest decât o metrică internă; metrica internă poate arăta latență mică chiar când load balancer-ul are probleme.
• Maximum trei SLI-uri per serviciu. Mai mult nu înseamnă mai multă precizie; când toate dimensiunile sunt SLI, niciuna nu este cu adevărat importantă.
• Fii explicit despre ce numește o cerere reușită. „Răspuns non-5xx sub 2 secunde" este un SLI. „Funcționează bine" nu este. Ambiguitatea produce dezacorduri exact când SLI-ul scade sub țintă.

Cum măsurăm disponibilitatea pe RestoInsights?

SLI-ul de disponibilitate pentru RestoInsights este calculat de un monitor extern, nu dintr-un healthcheck intern. Distincția contează: un healthcheck intern poate raporta OK chiar când ceva din calea utilizatorului (proxy, load balancer, CDN) este oprit. Monitorul extern simulează cererea dinspre utilizator, perspectiva care contează pentru un SLI de disponibilitate.

Valoarea obținută din monitor este reconciliată manual cu jurnalul de tichete de suport, ca să includă toate incidentele cu impact real asupra utilizatorilor, indiferent de cauza lor. Un incident cauzat de un provider terț sau de o eroare de configurare intră tot în calculul SLI-ului dacă utilizatorul l-a resimțit. Pe fereastra de doi ani mai 2024 – mai 2026, SLI-ul de disponibilitate pe RestoInsights este 99,9%.¹

Principiul de bază: măsoară SLI-urile din perspectiva utilizatorului, nu din interiorul sistemului pe care încerci să-l caracterizezi. Orice lucru măsurat din interior tinde să subestimeze durata și frecvența incidentelor reale.

Care este capcana cea mai frecventă cu SLI-urile?

SLI-ul agregat care ascunde outliers. Un singur număr calculat pe întreaga bază de utilizatori poate arăta excelent deși un segment are o experiență mult mai proastă decât media.

• Agregare pe geografie. Disponibilitate de 99,9% calculată global poate ascunde 97% disponibilitate pentru utilizatorii dintr-o regiune care reprezintă puțin din traficul total. SLI-ul agregat este corect matematic și dezastruos pentru utilizatorii afectați.
• Agregare pe tip de cerere. Disponibilitate globală de 99,9% poate coexista cu 95% disponibilitate pe endpoint-ul de plăți, dacă plățile reprezintă 1% din trafic. Utilizatorii care încearcă să plătească nu sunt consolați de statisticile generale.
• Latența medie în loc de percentile. Latență medie de 200 ms poate coexista cu p99 de 8 secunde. Media maschează experiența utilizatorilor care nimeresc în coada lungă. Raportează p95 și p99, nu mediana.
• Ferestre prea lungi. Un SLI calculat pe 90 de zile poate arăta stabil chiar dacă ultima săptămână a fost dezastruoasă. Urmărește SLI-urile și pe ferestre scurte, nu doar pe tendința lungă.

Soluția este segmentarea: calculează SLI-uri separate pe dimensiunile care contează și urmărește distribuția, nu doar media. Metricile de observabilitate structurate cu etichete (labels) fac segmentarea ieftină; fără etichete, ești blocat la agregări globale. Un runbook bun documentează care segmente sunt monitorizate distinct. Practica de a alege SLI-uri corecte este fundamentul oricărei discipline de site reliability engineering; fără SLI-uri oneste nu poți stabili SLO-uri realiste și nu poți negocia SLA-uri cu acoperire reală în date.

1. SLI-ul de disponibilitate pe RestoInsights, calculat de un monitor extern și reconciliat manual cu jurnalul de tichete, a înregistrat 99,9% pe fereastra mai 2024 – mai 2026. [resto.uptime_two_year]