În practica IT actuală, confuzia dintre SRE, DevOps și Platform Engineering este frecventă, dar distincțiile sunt cruciale pentru cariera ta. DevOps este o cultură și un set de practici care unesc dezvoltarea și operațiunile pentru livrare rapidă. SRE este o specializare tehnică a DevOps, aplicând inginerie software pentru a automatiza infrastructura și a gestiona fiabilitatea. Platform Engineering este evoluția naturală, creând produse interne (platforme) pentru a reduce povara dezvoltatorilor. Înțelegerea acestor nuanțe te ajută să te poziționezi corect în echipă și să știi ce abilități să prioritizezi.
Concepte cheie
- DevOps: O filosofie culturală care elimină silozurile dintre echipele de dev și ops, promovând colaborarea continuă și automatizarea pipeline-urilor CI/CD.
- SRE (Site Reliability Engineering): O disciplină inginerescă care tratează operațiunile ca un problemă de software, folosind SLIs, SLOs și SLAs pentru a defini calitatea serviciului.
- Platform Engineering: Construirea unei platforme interne auto-gestionabile (Internal Developer Platform - IDP) care oferă dezvoltatorilor o experiență similară cu cea a produselor consumer, ascunzând complexitatea infrastructurii.
- SLI/SLO/SLA: Metrici esențiale; SLI este măsurătoarea reală (ex: latență), SLO este ținta internă (ex: 99.9% uptime), iar SLA este contractul cu clientul.
- Error Budget: Bugetul de eroare permis înainte de a opri lansările noi; dacă este epuizat, focusul se mută de la feature-uri la stabilitate.
- Toil: Muncă manuală, repetitivă și automatizabilă; rolul SRE este să reducă toil-ul prin automatizare, nu să îl gestioneze pe termen lung.
Exemplu practic
Imagină-ți un serviciu web care trebuie să aibă o latență de p99 sub 200ms.
# Exemplu de configurare SLO în Prometheus/Grafana
slo:
name: "api_latency"
objective: 0.99 # 99% succes
window: "30d"
error_budget:
policy: "burn_rate"
threshold: 14.4 # Alertă dacă consumăm bugetul rapid
Dacă monitorizarea arată că burn rate-ul (rata de ardere a bugetului) depășește pragul, sistemul generează o alertă critică. Echipa nu mai lansează noi feature-uri până când stabilitatea revine la normal, priorizând remedierea bug-urilor. Aceasta este aplicarea practică a conceptului de Error Budget.
Greșeli frecvente
- Confundă SRE cu SysAdmin modern: SRE nu este doar mentenanța serverelor, ci scrierea de cod pentru a elimina munca manuală.
- Ignoră cultura Blameless Post-Mortem: Analiza incidentelor nu trebuie să caute vinovați, ci să identifice cauzele rădăcină și să prevină recurența.
- Setează SLO-uri nerealiste: Un SLO de 100% este imposibil și costisitor; definește toleranțe realiste bazate pe impactul utilizatorului.
- Platforma ca proiect izolat: Platform Engineering eșuează dacă nu este tratată ca un produs cu clienți interni (dezvoltatorii) care oferă feedback.
Întrebări de interviu
1. Care este diferența dintre un SLO și un SLA? Un SLO este o țintă internă de performanță pe care echipa o urmărește pentru a menține încrederea utilizatorilor. Un SLA este un angajament contractual formal cu clientul, care poate implica penalități financiare dacă nu este respectat.
2. Ce faci când Error Budget-ul este epuizat? Oprești temporar lansarea de noi funcționalități (feature freeze) și redirectezi toate resursele echipei către stabilizare, remedierea bug-urilor și reducerea toil-ului până la refacerea bugetului.
3. Cum definești "toil" și cum îl reduci? Toil este munca manuală, repetitivă și scalabilă. O reduc automatizând procesele repetitive (ex: deploy-uri, provisioning) și documentând soluțiile pentru a transforma activitățile ad-hoc în produse standardizate.
Exercițiu
Alocă 45 de minute pentru următoarea sarcină:
- Alege un serviciu public cunoscut (ex: Google Search, Netflix, sau un API simplu pe care l-ai folosit).
- Identifică 3 SLIs (Service Level Indicators) relevante pentru acel serviciu (ex: rata de eroare HTTP 5xx, latența p95, succesul logării).
- Propune un SLO realist pentru fiecare indicator (ex: "Latența p95 < 200ms pentru 99% din cereri").
- Scrie un scurt scenariu (max 100 de cuvinte): ce se întâmplă dacă SLO-ul este încălcat timp de 2 ore? Cine este alertat și ce acțiune imediată se ia?
Această exercițiu îți testează capacitatea de a traduce cerințele de business în metrici tehnice, esențială pentru un SRE.