SLO: cum bagi un buffer între obiectivul intern și SLA-ul extern

Un SLO (Service Level Objective) este ținta internă de calitate a serviciului pe care o echipă și-o stabilește pentru un SLI, înainte ca acel obiectiv să devină un angajament extern față de clienți. Cu alte cuvinte, SLO-ul este ce te propui tu să atingi; SLA-ul este ce ai promis că vei atinge. Decalajul dintre ele este intenționat și util.

Confuzia obișnuită este să tratezi SLO-ul ca pe un sinonim al SLA-ului sau ca pe un număr aspirațional ales la întâmplare. Nici una, nici alta. SLO-ul bine ales pornește de la un baseline măsurat real și lasă un buffer calculat, nu ghicit.

Ce este un SLO și cum se leagă de SLI și SLA?

Cele trei abrevieri descriu trei niveluri diferite ale aceluiași lanț de responsabilitate:

• SLI (Service Level Indicator). Metrica brută pe care o măsori, de exemplu procentul de cereri cu răspuns sub 200 ms sau uptime-ul calculat pe o fereastră de 30 de zile. SLI-ul este datele, fără judecată.
• SLO (Service Level Objective). Obiectivul pe care echipa și-l propune intern pentru acel SLI: de exemplu, cel puțin 99,95% din cereri sub 200 ms. SLO-ul este intern, nu apare în contract cu clientul, și poate fi ajustat de echipă fără negociere externă.
• SLA (Service Level Agreement). Angajamentul contractual față de client, mai lax decât SLO-ul intern. Dacă SLO-ul intern este 99,95%, SLA-ul extern ar putea fi 99,9%. Diferența de 0,05 puncte procentuale este buffer-ul de reacție.

Relația se rezumă simplu: SLI-ul furnizează numărul, SLO-ul stabilește ce înseamnă „bun", SLA-ul definește consecințele dacă nu e bun. Dacă nu ai SLO intern, SLA-ul este și obiectivul intern, și nivelul la care contractul se declanșează, fără nicio marjă de reacție.

De ce un SLO intern este mai strict decât SLA-ul extern?

Buffer-ul există pentru că incidentele nu anunță când au loc. Dacă SLO-ul intern este egal cu SLA-ul extern și ai un incident de 15 minute, ești deja în breșă de SLA fără să fi apucat să reacționezi. Buffer-ul îți cumpără timp, literal: câte minute sau ore dintr-o lună poți pierde înainte ca SLA-ul contractual să fie afectat.

Calculul este direct. Fie SLA-ul extern 99,9% pe o fereastră de 30 de zile. Asta înseamnă că poți tolera 0,1% din timp în stare de nerespectare a SLA-ului: 30 × 24 × 60 × 0,001 = 43,2 minute pe lună. Dacă SLO-ul tău intern este 99,95%, buffer-ul intern este 0,05%, adică 21,6 minute. Când valoarea SLI-ului coboară sub 99,95% dar rămâne peste 99,9%, ești în zona de alertă internă, nu în breșă externă. Ai 21 de minute să rezolvi înainte ca SLA-ul să fie atins.

Cât de mare trebuie să fie buffer-ul? Cât de mare este tipic un incident la tine, plus o marjă pentru comunicare și remediere. Dacă incidentele se rezolvă în sub 5 minute, un buffer de 10 minute este suficient. Dacă ai procese de aprobare sau escaladare, ai nevoie de mai mult. Numărul se alege din datele de incident ale ultimelor 3-6 luni, nu din aer.

Cum calculezi error budget pornind de la un SLO?

Error budget este complementul SLO-ului la 100%: totalul de „timp rău" sau „cereri eșuate" pe care le poți consuma într-o fereastră dată fără să încalci obiectivul. Dacă SLO-ul este 99,9% disponibilitate pe 30 de zile, error budget-ul este 0,1% din 43.200 minute, adică 43,2 minute pe lună. Fiecare minut de incident consumă din acest buget.

Formula generică, indiferent de ce măsoară SLI-ul:

• Error budget în procente = 100% minus SLO (%)
• Error budget în timp = durata ferestrei × (1 minus SLO)
• Error budget în cereri eșuate = numărul total de cereri × (1 minus SLO)

Error budget-ul are două utilizări practice. Prima este operațională: când budget-ul se epuizează, prioritizarea featurelor noi cedează fiabilității. A doua este strategică: dacă la final de lună 80% din budget a rămas neconsumat, ai argumente măsurabile fie că poți livra mai repede, fie că poți ridica SLO-ul intern.

O capcană frecventă este calculul pe ferestre calendaristice fixe (1 ianuarie - 31 ianuarie) față de ferestre rulante (ultimele 30 de zile). Fereastra fixă creează un efect de „resetare": la 1 februarie, error budget-ul revine la 100% indiferent ce s-a întâmplat pe 31 ianuarie. Fereastra rulantă este mai corectă operațional pentru că reflectă starea curentă a sistemului, nu o convenție de calendar.

Cum aplicăm SLO-uri la crawlerra?

Pe RestoInsights, baseline-ul măsurat este 99,9% uptime pe fereastra mai 2024 – mai 2026, calculat excluzând mentenanța programată și incluzând toate incidentele cu impact asupra utilizatorilor.¹ SLO-ul intern și SLA-ul extern se calibrează pornind de la acest număr, cu un buffer intenționat între ele și dimensionat pe baza istoricului de incidente, nu dintr-o regulă procentuală aleasă pe hârtie.

Principiul general pe care îl aplicăm este că SLO-ul trebuie să pornească din date de producție reale, nu din ceea ce pare ambițios sau rezonabil pe hârtie. Un obiectiv aspirațional pe care sistemul nu l-a atins niciodată produce un error budget cronic epuizat și o echipă care trăiește în alertă permanentă. Un obiectiv ancorat în baseline-ul istoric, cu un buffer calculat din date de incident, produce un SLO pe care echipa îl poate respecta și din care poate construi.

Care este capcana cea mai frecventă cu un SLO ales prost?

Capcana principală nu este SLO-ul prea ambițios, ci SLO-ul ales fără un SLI clar definit. Un SLO de „99,9% disponibilitate" nu înseamnă nimic dacă nu ai stabilit ce înseamnă „disponibil": HTTP 200 pe endpoint-ul de health check, timp de răspuns sub un prag, sau absența erorilor 5xx la utilizatori reali. Fiecare definiție produce o valoare diferită a SLI-ului și, prin urmare, un error budget diferit.

• SLO pe o metrică neacționabilă. Dacă SLI-ul tău măsoară ceva ce nu poți influența direct (de exemplu, latența la o dependență externă fără SLA propriu), SLO-ul pe acea metrică nu îți spune ce să faci când e breșă, ci doar că există o problemă.
• Fereastră de calcul nepotrivită cu cadența de revizuire. Un SLO calculat pe 90 de zile dar revizuit lunar te lasă să iei decizii pe date parțiale. Aliniază fereastra cu cadența efectivă a echipei.
• SLO stabilit fără date de baseline. Alegerea unui număr rotund (99%, 99,9%, 99,99%) fără să verifici mai întâi ce a livrat sistemul în ultimele luni produce fie un SLO trivial de atins, fie unul cronic breșat. Amândouă sunt inutile.
• SLO nereviziuit după schimbări majore de arhitectură. Dacă ai trecut de la un monolith la mai multe servicii, sau ai adăugat o dependență externă critică, SLO-ul vechi poate fi invalidat. Revizuiește-l de fiecare dată când topologia sistemului se schimbă semnificativ.
• Lipsa de legătură între SLO și error budget policy. Un SLO fără o politică clară de ce se întâmplă când error budget-ul se epuizează este doar un număr pe un dashboard. Politica trebuie stabilită și agreată înainte de primul incident, nu în mijlocul lui.

Legătura dintre SLO și practica mai largă de site reliability engineering este strânsă: SLO-ul bine ales este fundația pe care se construiesc runbook-urile, alertele și deciziile de prioritizare. Fără SLO, observabilitatea îți spune că ceva e rău, dar nu îți spune cât de rău e permis să fie. Cu SLO, ai un prag de referință față de care orice incident este evaluat cantitativ, nu subiectiv.

1. Uptime cumulat pe RestoInsights pe perioada mai 2024 – mai 2026, calculat excluzând mentenanța programată și incluzând toate incidentele cu impact asupra utilizatorilor. [resto.uptime_two_year]