SRE (Site Reliability Engineering): ce este, ce NU este, cum începi

Site Reliability Engineering (SRE) este disciplina de a aplica practici de inginerie software problemelor clasice de operare a sistemelor în producție. Tratezi fiabilitatea ca o funcționalitate care se proiectează, se măsoară și se îmbunătățește sistematic, nu ca ceva ce „ar trebui să meargă de la sine".

Termenul a apărut la Google în 2003 și a intrat în vocabularul industriei odată cu publicarea cărții Site Reliability Engineering în 2016. Confuzia obișnuită este că SRE ar cere o echipă dedicată sau o infrastructură de tip Google. Nu cere. Cere disciplină aplicată consistent, cu câteva instrumente clare.

De unde vine termenul SRE și ce problemă a rezolvat Google?

La Google, echipa de site reliability engineering a apărut ca soluție la tensiunea clasică: inginerii voiau să livreze des și rapid, ops-ul voia stabilitate și schimbări rare. Tensiunea producea fie livrări blocate, fie incidente frecvente.

Soluția lui Ben Treynor Sloss a fost să angajeze ingineri software care să facă operare, dar cu instrumentele și mentalitatea de cod: automatizare, măsurători, cod de producție în loc de proceduri manuale. Regulile de bază:

• Toil minimizat. Toil este munca operațională repetitivă, manuală și fără valoare de durată. SRE-ul Google limita toil-ul la maximum 50% din timp; restul mergea în automatizare și îmbunătățiri structurale.
• Error budget ca mecanism de aliniere. Nu „echipa de ops decide când se poate face deploy", ci numerele decid. Negocierea politică dispare.
• Postmortem blameless. Incidentele nu sunt vina unui individ, ci simptome ale unui sistem cu deficiențe de design sau proceduri. Cauza rădăcină contează, nu vinovatul.

Cum diferă SRE de DevOps și de ops clasic?

Ops clasic operează sisteme conform unor proceduri: dacă X se întâmplă, execuți pașii Y din manual. Cunoașterea este tacită, răspunsul este manual. Funcționează la scară mică, se rupe când sistemele sau echipele cresc.

DevOps este o schimbare culturală: development și operare colaborează, ownership-ul sistemelor nu se termină la „am livrat codul". SRE este o implementare specifică a filosofiei DevOps, cu instrumente precise: SLO-uri, măsurarea toil-ului, postmortem-uri ca artefacte de inginerie.

Diferența față de ops clasic este rigoarea ingineresc: orice decizie operațională are un număr în spate. Legătura cu observabilitatea este directă: nu poți face SRE fără telemetrie solidă, pentru că SLI-urile se calculează din date reale.

Care sunt practicile fundamentale ale SRE?

Patru concepte formează coloana vertebrală a oricărei implementări SRE:

• SLI (Service Level Indicator). O metrică care măsoară un aspect al fiabilității din perspectiva utilizatorului: rata de succes a request-urilor, latența sub un prag, disponibilitatea endpoint-ului principal. SLI-ul este numărul brut.
• SLO (Service Level Objective). Pragul intern pe care și-l propune echipa pentru un SLI pe o fereastră de timp. SLO-ul intern este mai strict decât SLA-ul extern promis clienților, exact ca să existe marjă de reacție.
• Error budget. Diferența dintre 100% și SLO-ul definit, exprimată în timp permis de nefuncționare. Un SLO de 99,9% pe 30 de zile înseamnă ~43 de minute budget. Când budget-ul e consumat, politica standard este să oprești orice schimbare nouă în producție. Error budget-ul transformă o conversație subiectivă despre risc într-o regulă matematică.
• Blameless postmortem. Document scris după orice incident semnificativ: ce s-a întâmplat, impactul, cauza rădăcină sistemică, ce a funcționat bine, ce acțiuni urmează. Blameless înseamnă că postmortem-ul nu caută vinovați, caută deficiențe de sistem. Oamenii raportează onest când nu le este teamă de consecințe personale.

Cum aplicăm principiile SRE fără echipă dedicată?

La crawlerra nu avem un departament SRE. Avem o disciplină aplicată de toată echipa: fiecare serviciu livrat are un SLO definit, fiecare incident notabil primește un postmortem scris, fiecare alertă are un runbook asociat în repo. La ultima inventariere, aveam 20 de runbook-uri active¹.

Rezultatul practic se vede pe RestoInsights: 99,9% uptime pe fereastra mai 2024 – mai 2026², fără nicio persoană cu titlul de SRE în organigramă. Ce a produs acel număr nu a fost stack-ul tehnic, ci consecvența: alertele se tratează imediat, runbook-urile se actualizează după fiecare incident, postmortem-urile scurte se scriu chiar și pentru downtime-uri de câteva minute.

Folosim n8n pentru a direcționa alertele pe canalele corecte (Slack, SMS sau e-mail, după severitate), eliminând pasul manual de notificare. Migrările de schemă se gestionează cu Liquibase, eliminând toil-ul migrărilor manuale la fiecare deploy. Axioma noastră A.04 spune direct: „Măsurăm tot. Dashboard-uri, alerte, uptime, timpi de răspuns. Ce contează, e pe grafic." SRE fără echipă dedicată înseamnă exact asta: un sistem care generează date și o echipă care răspunde când numerele o cer.

Care sunt capcanele când copiezi practicile Google la scară mică?

Cartea Google SRE are 550 de pagini scrise pentru echipe care gestionează sisteme cu milioane de utilizatori și zeci de servicii interdependente. Copierea directă la scară mică produce supraingineritate, nu fiabilitate.

• Prea multe SLO-uri de la început. Dacă definești SLO-uri pentru cincisprezece servicii în prima săptămână, nu vei urmări niciunul serios. Un SLO corect urmărit o lună valorează mai mult decât zece definite și ignorate.
• SLO-uri mai stricte decât realitatea măsurată. Un SLO de 99,99% pe un serviciu care a rulat cu 99,5% este o aspirație, nu un obiectiv. SLO-ul inițial trebuie să reflecte performanța actuală. Setezi prea sus și error budget-ul se consumă în prima săptămână, demoralizând echipa.
• Postmortem-uri transformate în rapoarte de vină. Dacă postmortem-ul concluzionează „Ion nu a urmărit alerta", nu ai înțeles blameless. Concluzia corectă este „runbook-ul lipsea" sau „alerta nu era suficient de clară". Sistemul trebuie să fie robust față de oameni obosiți sau noi în echipă.
• Toil ignorat pentru că „suntem o echipă mică". Echipele mici au mai puțin timp, nu mai mult. Fiecare sarcină manuală repetitivă consumă ore care nu mai merg în livrare. Toil-ul trebuie cuantificat (chiar și printr-un calcul brut: câte minute pe săptămână?) și atacat sistematic.
• Runbook-uri scrise o singură dată, niciodată actualizate. Un runbook care reflectă arhitectura de acum 18 luni este periculos. Fiecare incident rezolvat altfel decât scrie runbook-ul trebuie să producă o actualizare. Aceasta este disciplina reală, nu existența runbook-urilor.

Despre cum arată software-ul care funcționează curat ani de zile, am scris în articolul nostru despre produse cu durată lungă de viață. SRE la scară mică înseamnă să aplici rigoarea ingineresc fără birocrația de scară.

1. Numărul de runbook-uri active în repo-ul de operațiuni la momentul ultimei revizii (mai 2026). [ops.runbooks_count]
2. Uptime cumulat pe RestoInsights pe perioada mai 2024 – mai 2026, calculat cu excluderea ferestrelor de mentenanță programată și includerea tuturor incidentelor cu impact asupra utilizatorilor. [resto.uptime_two_year]