SLA: ce este, cum se calculează, diferența față de SLO și SLI

Un SLA (Service Level Agreement) este acordul contractual prin care un furnizor de software se obligă față de client la un nivel minim de disponibilitate, performanță sau suport, cu consecințe financiare dacă pragul nu este respectat. Termenul apare mereu alături de SLO (Service Level Objective) și SLI (Service Level Indicator), cu care este des confundat, deși reprezintă trei niveluri diferite ale aceluiași lanț. Un SLA de 99,999% cu douăzeci de categorii de excludere valorează mai puțin decât un angajament modest măsurat fără cosmetică.

Ce este SLA-ul mai exact?

SLA, SLO și SLI formează un lanț în care fiecare nivel se bazează pe cel de dedesubt:

• SLI (Service Level Indicator). Metrica brută măsurată: procentul de request-uri cu răspuns sub 500 ms, rata de erori HTTP 5xx, disponibilitatea unui endpoint pe o fereastră dată. SLI-ul este cifra reală din sistem, înainte de orice interpretare.
• SLO (Service Level Objective). Obiectivul intern al echipei, de obicei mai strict decât SLA-ul extern. Dacă SLA-ul promite clienților 99,9%, SLO-ul intern poate fi 99,95%: dacă SLO-ul se apropie de prag, echipa acționează înainte ca SLA-ul să fie încălcat.
• SLA (Service Level Agreement). Acordul extern, cu clauze, penalități și consecințe contractuale. Se bazează pe SLO-uri, dar este negociat și semnat cu clientul.

Regula simplă: SLI-ul măsoară, SLO-ul țintește, SLA-ul contractează. Dacă nu ai SLI-uri clare și un sistem de observabilitate care să le colecteze continuu, orice SLA rămâne o promisiune goală pe hârtie, greu de apărat sau de contestat la primul incident.

Cum se calculează downtime-ul permis dintr-un SLA?

Cel mai util exercițiu când negociezi sau scrii un SLA este să traduci procentajul în ore concrete. Mulți clienți semnează un SLA de 99% fără să realizeze că acoperă 3,65 zile de downtime pe an. Tabelul de mai jos arată downtime-ul permis per an și per lună la patru niveluri uzuale:

Disponibilitate	Downtime / an	Downtime / lună
90%	~36,5 zile	~72 ore
99%	~3,65 zile	~7,2 ore
99,9%	~8,76 ore	~43,8 minute
99,99%	~52,6 minute	~4,4 minute

Nivelul 99,99% (patru de nouă) cere redundanță activă, deployment fără downtime și o echipă de on-call disponibilă permanent. Nu este o țintă realistă pentru echipele mici fără buget dedicat de infrastructură. Nivelul 99,9%, adică maxim 8,76 ore de downtime pe an, este un angajament serios și realizabil cu un stack bine instrumentat și procese de alertare funcționale.

Care sunt capcanele unui SLA scris?

• Excluderi prea largi. Mentenanța planificată, force majeure și dependențele de terți sunt excluderi legitime când sunt definite strict. Problema apare când lista ajunge să acopere și „trafic neașteptat", „probleme la nivelul DNS-ului clientului" sau „comportament cauzat de erori ale utilizatorului". Un SLA cu zece pagini de excluderi poate acoperi practic orice incident.
• Uptime măsurat intern, nu extern. Dacă serverul tău raportează 100% disponibilitate dar clienții nu pot accesa aplicația din cauza unui routing stricat în rețea, cifra internă nu valorează nimic față de client. Uptime-ul relevant se măsoară de la un punct extern, din perspectiva utilizatorului final, nu dintr-un healthcheck intern.
• Ferestre de calcul convenabile. Un SLA calculat pe luni calendaristice arată mai bine decât unul pe fereastră glisantă de 30 de zile: un incident din ultima zi a lunii nu mai afectează statisticile lunii viitoare. Ferestrele calendaristice sunt convenabile pentru furnizor, nu pentru client.
• Media anuală ascunde incidentele concentrate. Un uptime mediu de 99,9% pe an poate ascunde o săptămână cu 95% disponibilitate urmată de unsprezece săptămâni perfecte. Clientul a trăit un serviciu dezastruos, dar media arată bine. SLI-urile raportate pe ferestre scurte sunt mai oneste decât o medie anuală.
• Dependențe externe neincluse. Dacă produsul tău colectează date din surse externe prin scraping sau prin API-uri third-party, indisponibilitatea acelor surse poate afecta utilizatorii tăi fără ca serverele tale să aibă vreo problemă. SLA-ul trebuie să clarifice explicit cum tratezi aceste situații, altfel fiecare incident cu o cauză externă devine o negociere separată.

Cum măsurăm noi SLA-ul la crawlerra?

Pe RestoInsights, angajamentul nostru intern este 99,9% disponibilitate, calculat pe o fereastră de doi ani. Regula de calcul nu are asteriscuri: excludem doar mentenanța planificată comunicată în avans, includem toate incidentele cu impact asupra utilizatorilor, indiferent de cauza din spate, fie că este vorba despre infrastructură proprie, cod aplicație sau o dependență externă. Cifra de 99,9% pe fereastra mai 2024 – mai 2026 este măsurată de un monitor extern aplicației, reconciliată manual cu jurnalul de tichete interne¹.

Includerea dependențelor externe este o decizie conștientă. Dacă un furnizor terț cade și clientul simte impactul, acela este un incident al nostru. Delegarea cauzei către un furnizor extern este cel mai comod mecanism de a dilua un SLA; preferăm un angajament modest măsurat cinstit față de un procentaj impresionant plin de condiții. Alertele care semnalizează apropierea de prag ajung la echipă prin n8n, care rutează notificările după severitate, fără să depindem de refresh manual pe dashboard-uri.

Cum scrii un SLA cinstit pentru clienții tăi?

Câteva practici care fac diferența dintre un SLA pe hârtie și un angajament real:

• Publică SLI-urile, nu doar SLA-ul. Spune clientului ce metrici măsori (disponibilitatea endpoint-ului principal, latența la percentila 95, rata de erori), cu ce instrument și cu ce frecvență. Un SLI transparent face SLA-ul verificabil de ambele părți.
• Definește „incident" înainte de a scrie procentajul. Ce durată minimă de indisponibilitate contează ca incident? Un minut? Cinci minute? Clarifică și dacă erorile de rate limiting (HTTP 429) intră sau nu în calcul, altfel fiecare caz devine o negociere separată.
• Angajează-te la ce poți măsura extern. Dacă nu ai un monitor extern configurat în momentul semnării, nu poți justifica cifra promisă în fața clientului. Configurează monitorizarea înainte de a scrie numărul în contract.
• Limitează excluderile la maximum trei categorii clare. Mentenanță planificată comunicată în avans, forță majoră cu definiție legală, atacuri DDoS documentate. Orice altceva contează ca incident al tău.

Un SLA slab este mai periculos decât absența lui: creează așteptări pe care nu le poți onora și generează litigii. Software-ul care rămâne funcțional ani de zile pornește de la o relație de transparență cu clientul, nu de la linii mici de contract. Despre cum arată acea continuitate în practică, vezi articolul nostru despre software-ul care durează.

1. Uptime cumulat pe RestoInsights pe fereastra mai 2024 – mai 2026, calculat excluzând mentenanța planificată și incluzând toate incidentele cu impact asupra utilizatorilor, măsurat de un monitor extern și reconciliat manual cu jurnalul de tichete interne. [resto.uptime_two_year]