Storia ed evoluzione del Site Reliability Engineer (SRE)
Il Site Reliability Engineering (SRE) è un approccio in cui le attività operative vengono affrontate con mentalità e metodi da ingegneria del software: in altre parole, “trattare le operations come un problema software”. Nel tempo questa idea ha trasformato il modo in cui aziende e team gestiscono disponibilità, prestazioni e scalabilità dei servizi digitali.
Prima dell’SRE: quando l’operatività non scalava
Nei primi anni dei grandi servizi web, molte organizzazioni si affidavano a modelli tradizionali (amministrazione di sistema e operations) che funzionavano bene finché infrastrutture e rilasci rimanevano relativamente stabili. Con l’aumento del traffico, delle dipendenze e della frequenza di deploy, “spegnere incendi” a mano diventava costoso e rischioso: serviva un metodo ripetibile, misurabile e automatizzabile.
Le origini: Google e la nascita del ruolo
L’SRE nasce in Google: secondo le ricostruzioni storiche, il primo team SRE viene fondato nel 2003 da Benjamin Treynor Sloss. Google descrive inoltre l’SRE come una pratica che, “dal 2004”, si è evoluta fino a diventare un punto di riferimento per l’affidabilità dei servizi.
“SRE is what you get when you treat operations as if it’s a software problem.”
Da “tenere su i sistemi” a progettare affidabilità
Con l’approccio SRE, l’obiettivo non è solo reagire agli incidenti, ma ridurre il lavoro ripetitivo (toil), aumentare l’automazione e progettare sistemi che reggano il carico reale. Nel modello descritto da Google, l’attenzione è costante su disponibilità, latenza, performance e capacità, con un approccio ingegneristico e guidato dai dati.
La svolta: SLO ed error budget
Uno dei contributi più influenti dell’SRE moderno è l’uso esplicito di obiettivi di servizio (SLO) per allineare aspettative tecniche e di business. In questo contesto, l’error budget diventa uno strumento di governance: “Error budgets are the tool SRE uses to balance service reliability with the pace of innovation.”
Google definisce l’error budget in modo semplice: è “1 minus the SLO of the service”; ad esempio, con SLO 99,9% l’error budget è 0,1%. Un esempio operativo riportato da Google: su 1.000.000 di richieste in quattro settimane, uno SLO 99,9% implica un budget di 1.000 errori nello stesso periodo.
Nel modello proposto, se il servizio supera l’error budget in una finestra di quattro settimane, si possono bloccare i rilasci non critici finché il servizio non rientra nei target. Questo sposta la conversazione da “chi ha colpa?” a “quanta affidabilità stiamo consumando e quali scelte facciamo adesso?”.
Incidenti, postmortem e cambiamento controllato
Un’altra intuizione pratica è che molte interruzioni nascono dai cambiamenti: Google riporta che i cambiamenti sono una fonte importante di instabilità, associandoli a circa il 70% delle interruzioni (“outages”). Per questo l’SRE rafforza pratiche come rilasci progressivi, rollback rapidi, automazione dei controlli e postmortem strutturati.
- Gestione dell’incidente: rilevare, contenere, ripristinare e comunicare con disciplina.
- Postmortem: analizzare cause e contromisure con focus su apprendimento e prevenzione.
- Riduzione del toil: eliminare attività manuali ripetitive tramite strumenti e automazioni.
- Osservabilità: metriche, log e tracing per capire cosa succede davvero in produzione.
Diffusione nel settore: libri e standardizzazione
Nel 2016 il libro di Google “Site Reliability Engineering” ha acceso una discussione di settore su cosa significhi gestire servizi in produzione e sul perché l’affidabilità debba influenzare il design. Nel 2017, “The Site Reliability Workbook” viene presentato come compagno pratico, con esempi concreti per applicare principi e pratiche SRE.
Una linea del tempo essenziale
| Periodo | Cosa cambia | Perché conta |
|---|---|---|
| 2003 | Primo team SRE in Google (Ben Treynor Sloss). | Nasce un ruolo ibrido: operations + ingegneria software, con responsabilità sulla produzione. |
| Dal 2004 | SRE “evolve” come pratica di riferimento per l’affidabilità. | Si consolida un metodo: obiettivi misurabili, automazione, gestione del rischio. |
| 2016–2017 | Pubblicazione e diffusione di libri SRE di Google (book + workbook). | Le idee diventano replicabili: molte aziende le adottano e le adattano. |
L’SRE oggi: dall’infrastruttura al prodotto
Oggi l’SRE tende a collaborare strettamente con sviluppo, sicurezza e product management per rendere l’affidabilità un requisito di progetto, non un’aggiunta finale. In ambienti cloud-native e a microservizi, il ruolo evolve spesso verso “platform reliability”, con enfasi su self-service, guardrail, policy e automazioni condivise.
Competenze chiave del moderno SRE
- Programmazione e automazione (tooling, CI/CD, gestione configurazioni).
- Capacità di definire e negoziare SLO realistici con stakeholder tecnici e business.
- Incident response: prontezza operativa, comunicazione e coordinamento.
- Analisi sistemica: prevenzione, design resiliente, chaos testing e gestione dipendenze.
In sintesi, l’evoluzione dell’SRE racconta il passaggio da un’operatività “eroica” e reattiva a una disciplina ingegneristica basata su metriche, automazione e scelte esplicite di rischio, con SLO ed error budget come linguaggio comune.
