Modulul 8 este despre fiabilitate. Prima jumătate a cursului a construit sisteme. Modulul 7 a acoperit practicile care le livrează. Acest modul este despre disciplinele care le țin în funcțiune odată ce utilizatori reali depind de ele și trebuie să înceapă cu întrebarea pe care orice echipă de date o primește în final: cât de fiabilă este data, exact?
Răspunsul cinstit pe care îl dau majoritatea echipelor este o formă de „destul de fiabilă, de obicei”. Acel răspuns nu supraviețuiește unei singure săptămâni proaste. Dashboard-ul a întârziat marți. Numerele din raportul de vineri nu s-au potrivit cu sistemul-sursă. Clientul a semnat un contract presupunând refresh peste noapte și acum e enervat că „peste noapte” înseamnă uneori 11 dimineața. Nimeni nu a notat ce însemna fiabilitatea, așa că fiecare are un model mental diferit, iar fiecare incident devine o renegociere.
Practica Site Reliability Engineering de la Google a rezolvat asta pentru servicii software acum vreo cincisprezece ani. Framework-ul este acum larg adoptat: SLI-urile măsoară, SLO-urile țintesc, SLA-urile se angajează, iar error budgets conectează fiabilitatea la restul muncii. Framework-ul a fost scris pentru sisteme request-response (latență, disponibilitate, rată de eroare a unui serviciu HTTP), dar aceeași formă se aplică curat la produsele de date dacă indicatorii sunt aleși cu grijă. Lecția aceasta traduce framework-ul SRE în vocabularul data-engineering și parcurge politicile care îl fac operațional.
Cei patru termeni
Vocabularul este mic, dar fiecare termen are un rol precis. Confundarea lor este greșeala cea mai comună la adoptarea timpurie.
SLI, Service Level Indicator, este o proprietate măsurabilă a sistemului. Este un număr pe care îl poți calcula din date pe care monitorizarea ta deja le colectează. „Fracțiunea de refresh-uri de dashboard care se completează până la 9 dimineața, calculată zilnic” este un SLI. „Fracțiunea de rânduri din tabelul customer care sunt non-null pe email, calculată orar” este un SLI. Testul definitoriu este: poate un script să returneze un număr? Dacă da, este un SLI candidat. Dacă proprietatea este „calitatea datelor”, nu este încă un SLI; este o categorie care trebuie ascuțită într-o măsurabilă.
SLO, Service Level Objective, este ținta pe care o setezi pentru SLI. SLI este măsurătoarea; SLO este scopul. „99% din refresh-urile de dashboard se completează până la 9 dimineața, măsurat lunar” este un SLO construit pe SLI-ul anterior. Obiectivul este intern. Este bara la care echipa se ține pe sine însăși și este bara care conduce prioritățile de inginerie. Numărul este ales deliberat, nu aspirațional; mai multe despre asta mai jos.
SLA, Service Level Agreement, este un angajament contractual către o parte externă cu consecințe dacă este ratat. SLA-urile implică de obicei bani: credite de servicii, rambursări, penalități contractuale. Proprietatea crucială este că SLA este aproape întotdeauna mai slab decât SLO-ul intern corespunzător. Echipa se angajează intern la 99,9% pentru a putea semna încrezător un SLA extern la 99%. Decalajul este marja de siguranță. O echipă al cărei SLA este egal cu SLO-ul ei este la o săptămână proastă distanță de a plăti penalități. O echipă al cărei SLA este mai laxă decât SLO-ul ei are loc să absoarbă varianța normală fără a încălca contractele.
Error budget este inversul SLO-ului. Dacă SLO este 99%, error budget este 1%. Pe parcursul unei luni, acel 1% înseamnă aproximativ 7 ore de downtime permis sau câteva mii de refresh-uri eșuate permise, în funcție de cum se numără SLI. Bugetul este o resursă finită, ca un sold de card de credit pentru nefiabilitate. Fiecare incident, fiecare refresh întârziat, fiecare rând lipsă cheltuie o parte din el. Când dispare, comportamentul se schimbă (descris mai jos).
Relațiile sunt ușor de pierdut din vedere. SLI este indicatorul de pe dashboard. SLO este unde stau benzile verde-galben-roșu. SLA este ce e în contract. Error budget este spațiul disponibil înainte ca SLO-ul să fie încălcat.
Aplicarea framework-ului la date
Produsele de date au patru dimensiuni de fiabilitate care merită instrumentate, iar fiecare se mapează curat pe o formă de SLI.
SLO-uri de freshness captează cât de veche poate fi data permis. „Tabelul customer nu este mai vechi de 1 oră, 99% din timp, măsurat pe rolling 30 de zile.” SLI este calculat din lag-ul maxim între timpul de commit din sistemul-sursă și timpul vizibil în warehouse, eșantionat oricum permite sistemul. Freshness este ceea ce vor să spună majoritatea stakeholderilor de business când spun „data este stricată”; raportul este de ieri când se aștepta să fie de azi, iar modelul care decide ce înseamnă „de azi” este SLO-ul de freshness.
SLO-uri de completeness captează rândurile lipsă. „Mai puțin de 0,1% din rândurile așteptate lipsesc pe zi, măsurat per pipeline.” SLI compară numerele de rânduri așteptate (din metadatele sistemului-sursă, dintr-o cardinalitate cunoscută sau din ziua precedentă plus o toleranță) cu numerele de rânduri reale. Erorile de completeness adesea se ascund pentru că dashboard-ul totuși randează; graficul doar arată un număr mai mic decât ar trebui și nimeni nu observă până când un sales person întreabă de ce regiunea lui pare greșită.
SLO-uri de accuracy captează greșeala, nu absența. „Totalul de venituri zilnice din warehouse se potrivește cu sistemul ERP source-of-truth în limita a 0,01%, măsurat nocturn.” SLI este o verificare de reconciliere: ia aceeași metrică din două sisteme, compară. Accuracy este dimensiunea cea mai grea de instrumentat, pentru că ai nevoie de un ground truth independent, dar este și dimensiunea care distruge încrederea cel mai rapid când eșuează. Stakeholderii iartă un dashboard întârziat. Nu iartă un dashboard greșit.
SLO-uri de availability captează dacă data este queryable când se așteaptă. „Dashboard-ul BI este queryable 99,9% din orele din timpul programului de lucru, măsurat per regiune.” SLI este o sondă sintetică: în fiecare minut, un query automatizat rulează, iar sistemul înregistrează dacă a reușit într-un prag de latență. Availability este cea mai apropiată de SLO-urile de servicii tradiționale, pentru că dashboard-ul este în esență un sistem request-response odată ce datele sunt încărcate.
Majoritatea produselor de date vor SLO-uri în două sau trei dintre aceste dimensiuni, nu în toate patru. Alege dimensiunile care se mapează pe durerea reală a stakeholderilor.
De ce SLO-urile funcționează mai bine decât „ar trebui doar să fim fiabili”
Modelul pre-SLO al fiabilității este implicit și adversarial. Engineering vrea să livreze features. Operations sau stakeholderii vor mai puține incidente. Fiecare incident devine o ceartă despre dacă echipa se mișcă prea repede și nu există un standard comun pentru „prea repede”. Framework-ul SLO înlocuiește acea ceartă cu trei proprietăți.
Face compromisul explicit. 100% fiabilitate nu este realizabilă, iar chiar dacă ar fi, costul ar fi absurd: fiecare nouă cifră de fiabilitate adițională costă tipic un ordin de magnitudine mai mult efort de inginerie. SLO numește ținta deliberat. 99% este ieftin. 99,9% este semnificativ mai scump. 99,99% cere investiție reală de inginerie. 99,999% rareori se justifică în afara sistemelor de plăți și a celor de siguranță a vieții. Alegerea între 99% versus 99,9% este alegerea cât din bugetul de inginerie merge la fiabilitate versus features, iar SLO face acea alegere vizibilă în loc să pretindă că nu există.
Dă echipei permisiunea să fie imperfectă. Un incident care consumă o parte din error budget nu este o eroare morală. Este sistemul cheltuind bugetul care i-a fost deja alocat. Pe parcursul unui trimestru, se așteaptă unele incidente. Echipa care are zero incidente probabil sub-investește în viteza de features; echipa care își epuizează bugetul în fiecare lună sub-investește în fiabilitate. Bugetul face conversația cantitativă.
Prioritizează munca automat. Când bugetul este sănătos, livrează features și ia riscuri. Când bugetul s-a dus, aceleași riscuri nu mai sunt acceptabile, iar efortul de inginerie se mută la munca de fiabilitate până când bugetul se recuperează. Mutarea este politică, nu negociere. Există o regulă scrisă, echipa o urmează, conversația despre la ce să lucrezi devine scurtă.
Politica de error budget
Politica de error budget este documentul care transformă bugetul abstract în comportament operațional. Google SRE Workbook (https://sre.google/workbook/error-budget-policy/, consultat 2026-05-01) dă un șablon; majoritatea organizațiilor îl adaptează. Structura este trei stări cu reguli diferite.
Buget sănătos (rămâne mai mult de 50% din bugetul perioadei): operațiuni normale. Livrează features. Ia riscuri rezonabile. Deploy vinerea dacă sistemul de deployment e suficient de fiabil. Rulează experimente. Echipa operează în regimul pentru care SLO-ul a fost proiectat să permită.
Buget mic (mai puțin de 50%, mai mult de 0%): atenție. Schimbările riscante primesc review suplimentar. Migrările majore se amână dacă nu sunt deja în zbor. Frecvența de deployment poate încetini. Echipa începe să plătească datoria de fiabilitate: tunarea alertelor, actualizările de runbook, micile fix-uri care au fost amânate. Scopul este recuperarea bugetului înainte ca epuizarea să forțeze măsuri mai dure.
Buget epuizat (zero sau negativ pentru perioadă): freeze. Niciun deployment în afară de cele care îmbunătățesc direct fiabilitatea sau repară incidentele care au consumat bugetul. Munca pe features se oprește. Echipa se concentrează pe a aduce SLI înapoi în verde și pe munca de inginerie care previne următoarea încălcare. Freeze-ul este inconfortabil, ceea ce este punctul: creează presiune să investești în fiabilitate înainte ca bugetul să se termine, nu după.
Freeze-ul este partea controversată. Echipele de inginerie rezistă pentru că munca pe features este mai vizibilă. Product manager-ii rezistă pentru că angajamentele de roadmap alunecă. Framework-ul funcționează doar dacă leadership-ul susține politica când este invocată. O politică care e suspendată prima dată când se declanșează efectiv este o politică care a antrenat echipa să o ignore.
Setarea SLO-urilor realiste
Greșeala SLO cea mai comună este alegerea numărului aspirațional. „Vrem 99,99% pentru că clientul a cerut” nu este un SLO. Este o dorință. SLO-ul real trebuie să fie ceva ce sistemul poate livra cu efort de inginerie rezonabil, iar modul de a găsi acel număr este să pornești de la performanța curentă.
Măsoară SLI pentru o perioadă reprezentativă (o lună, un trimestru). Uită-te la distribuție. SLO-ul ar trebui setat ușor peste performanța curentă, nu mult deasupra. Dacă dashboard-ul se reîmprospătează curent până la 9 dimineața 97% din timp, setează SLO la 98%, nu la 99,9%. Error budget la 98% dă echipei loc pentru varianța pe care o trăiește în prezent, în timp ce mica treaptă în sus forțează îmbunătățire incrementală. După un trimestru la 98%, urcă la 98,5%. Cricul lent, îmbunătățire sustenabilă.
Greșeala opusă este setarea SLO-ului prea laxă. Dacă performanța curentă este 99,5% și SLO-ul este setat la 95%, bugetul este așa de generos încât incidentele nu declanșează politica, iar framework-ul nu oferă nicio presiune operațională. SLO-ul trebuie setat la un număr pe care sistemul chiar riscă să-l încalce, altfel este teatru.
Angajamentele externe (SLA) sunt apoi derivate din SLO-ul intern, nu invers. Echipa internă se angajează la 99% ca SLO. Contractul extern se angajează la 95% ca SLA. Decalajul de 4 puncte procentuale este marja de siguranță. Clienții văd un angajament de 95% și echipa operează față de o țintă de 99%, ceea ce înseamnă că SLA este aproape niciodată încălcat chiar și când SLO-ul este.
Bucla de error budget
flowchart TD
A[Measure SLI from monitoring] --> B[Compare to SLO target]
B --> C[Compute remaining error budget]
C --> D{Budget state?}
D -->|Healthy| E[Ship features, take risks]
D -->|Low| F[Caution, pay down reliability debt]
D -->|Exhausted| G[Freeze, focus on reliability]
E --> H[Next measurement period]
F --> H
G --> H
H --> ABucla este ritmul zilnic și săptămânal. Monitorizarea calculează SLI-uri continuu. Un dashboard afișează conformitatea curentă cu SLO și bugetul rămas. Ședințele săptămânale sau lunare de review inspectează starea bugetului și ajustează alocarea muncii. Incidentele actualizează bugetul în timp real. Framework-ul devine lentila prin care echipa își vede propria muncă de fiabilitate.
Arcul de maturizare este gradual. În primul trimestru, echipa alege SLO-uri care se dovedesc greșite (prea strânse, prea laxe, măsurând lucrul greșit) și le revizuiește. În al doilea trimestru, SLI-urile sunt rezonabile, dar politica nu a fost încă invocată, deci nu a fost testată. În al treilea sau al patrulea trimestru, bugetul se epuizează pentru prima dată, politica este invocată, iar organizația descoperă dacă crede cu adevărat în framework. Echipele care supraviețuiesc acestui test au o practică reală de fiabilitate. Echipele care nu au un document.
Lecția 61 reia firul mergând cu un strat mai adânc în cea mai comună categorie de SLI pentru produse de date: calitatea datelor. SLO spune „mai puțin de 0,1% din rândurile așteptate lipsesc”; practica de testare a calității datelor este ceea ce produce acel număr fiabil. SLO-uri fără testare de calitate sunt presupuneri. Testarea calității fără SLO-uri este muncă de umplutură.