Error budget: cum decizi când oprești feature-urile și investești în fiabilitate

Un error budget este cantitatea de timp de nefuncționare sau numărul de cereri eșuate pe care le poți consuma într-o perioadă dată fără să încalci SLO-ul stabilit. Matematic, este complementul SLO-ului la 100%: dacă ținta ta internă este 99,9% disponibilitate pe 30 de zile, error budget-ul este 0,1% din acea perioadă, adică aproximativ 43 de minute pe lună.

Conceptul vine din cartea Google SRE (2016) și are un scop precis: să transforme conversația despre risc dintr-o negociere subiectivă între echipa de produs și cea de operațiuni într-o regulă matematică. Câte minute de downtime poți permite luna asta? Exact atât. Problema apare când echipele calculează bugetul și nu îl respectă, transformând un instrument de decizie într-un număr decorativ.

Ce este error budget mai exact?

Error budget este definit pornind direct de la SLO (Service Level Objective). Dacă SLO-ul tău este 99,9% disponibilitate, error budget-ul este 0,1% din fereastra de calcul. Nu mai mult, nu mai puțin.

Trei forme echivalente ale aceluiași concept, în funcție de ce măsoară SLI-ul tău:

• Error budget în procente. 100% minus SLO (%). La 99,9% SLO, error budget-ul este 0,1%.
• Error budget în timp. Durata ferestrei înmulțită cu (1 minus SLO). Pe 30 de zile cu SLO 99,9%: 43.200 minute × 0,001 = 43,2 minute.
• Error budget în cereri eșuate. Numărul total de cereri înmulțit cu (1 minus SLO). La un milion de cereri pe lună cu SLO 99,9%: 1.000 de cereri eșuate permise.

Fiecare incident consumă din acest buget. Dacă un deploy prost ține serviciul oprit 20 de minute, ai consumat aproape jumătate din bugetul lunar. Dacă mai urmează un incident de 30 de minute în aceeași lună, ai depășit SLO-ul intern și, dacă nu există buffer față de SLA-ul extern, ești în breșă contractuală.

Cum se traduce în ore concrete de downtime permis?

Aritmetica este simplă, dar rezultatele surprind adesea echipele care aleg SLO-uri fără să calculeze ce înseamnă în practică:

• 99% disponibilitate pe 30 de zile: 7,2 ore de downtime permis pe lună. Pare mult până la primul incident de 8 ore.
• 99,9% disponibilitate pe 30 de zile: 43,2 minute. Suficient pentru un incident rezolvat rapid, consumat integral de un deploy greșit care necesită rollback.
• 99,95% disponibilitate pe 30 de zile: 21,6 minute. Un buffer realist față de SLA-ul extern de 99,9%, dacă incidentele tale se rezolvă în sub 15 minute.
• 99,99% disponibilitate pe 30 de zile: 4,3 minute. La acest nivel, orice maintenance neplanificat breșează SLO-ul. Justificabil doar când downtime-ul are consecințe financiare directe și măsurabile.

Fereastra de calcul contează la fel de mult ca procentul. Fereastra calendaristică fixă (1-31 ale lunii) creează un efect de resetare artificială: pe 1 ale lunii, error budget-ul revine la 100% indiferent ce s-a întâmplat pe 30 ale lunii precedente. Fereastra rulantă (ultimele 30 de zile) reflectă starea reală a sistemului în orice moment și este mai potrivită operațional.

Nu orice secundă de nefuncționare ar trebui să consume din buget în același mod. Mentenanța programată, anunțată în prealabil, se tratează diferit față de un incident neașteptat. Politica de calcul trebuie stabilită înainte de primul incident, nu improvizată în mijlocul lui.

Cum aplici politica de error budget (freeze pe feature-uri vs investiții în fiabilitate)?

Politica originală Google SRE este directă: când error budget-ul se epuizează, echipa oprește livrarea de funcționalități noi și investește în fiabilitate până când bugetul se reface. Rațiunea este că un sistem cu bugetul consumat este prea instabil ca să tolereze riscul unui nou deploy, oricât de bine testat ar fi.

Implementarea practică implică câteva decizii de stabilit în avans: cine declară că bugetul s-a epuizat, ce înseamnă concret „oprirea feature-urilor" (niciun deploy sau doar pauza sprints de produs), cât durează freeze-ul și ce tipuri de fix-uri rămân permise (patch-urile de securitate și îmbunătățirile de monitorizare ar trebui să rămână deschise). Fără aceste răspunsuri clare, politica se aplică arbitrar sau deloc, ceea ce este mai rău decât absența ei.

Cum se leagă error budget de practica noastră la crawlerra?

Pe RestoInsights, ținta de 99,9% disponibilitate se traduce într-un error budget implicit de aproximativ 43 de minute pe lună.¹ Practica noastră este să tratăm consumarea acestui buget ca un semnal pentru investiții în redundanță sau monitorizare, nu printr-o regulă procedurală de freeze automat. Când un incident consumă o parte semnificativă din bugetul lunar, întrebarea pe care o punem nu este „am breșat SLA-ul?" ci „ce trebuie schimbat ca incidentul ăsta să nu se repete cu aceeași magnitudine?"

Această abordare este posibilă pentru că avem observabilitate suficientă ca să vedem consumul bugetului în timp real, nu doar la finalul lunii când este prea târziu să reacționezi preventiv. Legătura cu site reliability engineering este directă: error budget-ul este instrumentul care face ca deciziile de prioritizare să fie bazate pe date, nu pe intuiție sau presiune de calendar. Runbook-urile documentate pentru incidentele frecvente sunt complementare: un incident rezolvat rapid din runbook consumă mai puțin din buget decât unul care necesită investigație de la zero.

Care e anti-pattern-ul cel mai costisitor (calculat dar niciodată respectat)?

Error budget-ul calculat dar ignorat este mai rău decât absența lui. Calculul creează iluzia că ai o politică de fiabilitate; ignorarea lui sistematică înseamnă că echipa a normalizat depășirea SLO-ului și că numărul pe dashboard nu mai are nicio consecință.

• SLO ales aspirațional, fără baseline real. Un obiectiv de 99,9% ales pentru că sună bine, când sistemul a livrat istoric 99,5%, produce un error budget cronic epuizat din prima săptămână. Echipa se obișnuiește să ignore semnalul și politica devine decorativă. SLO-ul trebuie pornit din datele de producție reale, nu din ce pare ambițios.
• Buget calculat pe hârtie, niciodată urmărit în timp real. Dacă verifici consumul error budget-ului o dată pe lună, în momentul raportării, informația este inutilă operațional. Bugetul trebuie urmărit continuu, integrat în același stack de observabilitate care urmărește latența și rata de erori.
• Politica agreată verbal, niciodată testată. O politică de freeze care nu a fost aplicată niciodată în practică nu există. Prima dată când bugetul se epuizează real este cel mai prost moment ca să afli că managementul nu a fost de acord cu oprirea feature-urilor. Testează politica în avans, în condiții neurgente.
• Error budget ca instrument de vina, nu de decizie. Dacă error budget-ul este folosit pentru a arăta că echipa de dezvoltare a „spart" serviciul, nu pentru a prioritiza investiții în fiabilitate, îl vei folosi o singură dată. Echipele care primesc feedback punitiv pe consum de buget încep să ascundă incidentele sau să manipuleze calculul. Instrumentul funcționează doar în culturi unde incidentele sunt tratate ca informații, nu ca vini.
• Lipsa legăturii cu chaos engineering sau teste de tip canary. O echipă care monitorizează error budget-ul dar nu face niciodată canary deployment sau injecție de erori controlată descoperă limitele sistemului în producție, nu în condiții controlate. Error budget-ul consumat de un experiment planificat este mai puțin costisitor decât cel consumat de o surpriză.

Anti-pattern-ul comun tuturor variantelor de mai sus: error budget-ul există ca raportare, nu ca instrument de decizie. Semnalul se acumulează, echipa îl vede și livrarea continuă la fel. Un buget care nu schimbă niciodată prioritizarea nu face altceva decât să documenteze că sistemul a fost instabil. Valoarea lui reală este prospectivă: îți spune, înainte de un incident, câtă marjă de risc mai ai.

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. Error budget lunar implicit = 43.200 minute × 0,001 = 43,2 minute. [resto.uptime_two_year]