La maggior parte delle aziende che affermano di aver adottato SRE in realtà hanno semplicemente rinominato il team operativo. Hanno cambiato il titolo di "amministratore di sistema" in "ingegnere dell'affidabilità del sito", hanno lasciato i processi intatti e poi sono rimasti sorpresi quando gli incidenti sono continuati allo stesso ritmo e la tensione tra sviluppo e operazioni non si è allentata. SRE non è una posizione. È un modo specifico di pensare alla responsabilità, al rischio e alla velocità e, senza cambiare il modo in cui opera effettivamente il team, il titolo non vale nulla. Il problema non sta nell’intenzione, ma nel presupposto che un cambiamento nella nomenclatura sia sufficiente per trasformare la cultura del modo in cui ingegneria e operazioni si relazionano.
Cosa significa veramente SRE
Site Reliability Engineering è nata in Google con una premessa semplice: se vuoi che il software funzioni in modo affidabile su larga scala, incarica gli ingegneri del software di gestirlo. L'idea centrale non è avere persone che "si prendano cura dei server", ma avere ingegneri che applichino i principi di sviluppo software per risolvere i problemi operativi.
Ciò cambia radicalmente il profilo della funzione. Un SRE scrive codice per automatizzare il lavoro operativo ripetitivo. Il libro originale di Google definisce che fino al 50% del tempo di un SRE dovrebbe essere dedicato all'ingegneria: automazione, strumenti, miglioramenti delle infrastrutture. Quando questa percentuale scende al di sotto di questo, è segno che la squadra sta operando come una squadra operativa tradizionale con un nuovo nome e non come un vero SRE.
SLO e budget di errore: affidabilità negoziabile
Il meccanismo che rende SRE operativamente coerente è la combinazione di obiettivi del livello di servizio e budget di errore. Gli SLO definiscono il livello di affidabilità che un servizio deve fornire, ad esempio una disponibilità del 99,9% misurata su una finestra di 30 giorni. Il budget di errore è il complemento: il restante 0,1% rappresenta lo spazio a disposizione del team per commettere errori, implementare, testare modifiche senza rompere il contratto con l'utente.
Questo meccanismo trasforma l’affidabilità in qualcosa di negoziabile piuttosto che assoluto. Quando il budget degli errori è pieno, il team può essere più aggressivo nelle distribuzioni e negli esperimenti. Quando si esauriscono, i rilasci rallentano finché la finestra non si ripristina. Ciò elimina l’arbitrarietà delle decisioni relative al rischio: non è il responsabile delle operazioni a dire “non possiamo schierarlo adesso” – è il budget a dirlo con i dati. Il dialogo tra prodotto e ingegneria si basa su qualcosa di misurabile, che cambia completamente le dinamiche negoziali. Gli SLO scarsamente definiti, tuttavia, sono peggiori di SLO inesistenti: creano un falso senso di controllo mentre misurano cose che non riflettono la reale esperienza dell'utente.
La questione strutturale: SRE integrati o team di piattaforma
Una delle decisioni più concrete che un'organizzazione deve prendere quando adotta SRE riguarda la struttura: gli SRE funzionano integrati nei team di prodotto o formano un team di piattaforma centralizzata? Non esiste una risposta universale e diffidate di chiunque ne offra una senza chiedere informazioni sulle dimensioni dell’organizzazione, sul livello di maturità tecnica e sul profilo dei servizi in questione.
Ogni modello presenta dei veri e propri compromessi. Gli SRE integrati rimangono vicini al contesto del servizio, comprendono le decisioni sui prodotti e creano credibilità con gli sviluppatori del team. Il rischio è la dispersione: la SRE finisce per risolvere problemi urgenti per la squadra locale e perdere tempo per costruire infrastrutture condivise. Inoltre, è difficile mantenere la coerenza delle pratiche tra i diversi team.
Il modello di piattaforma concentra le competenze e consente di creare strumenti scalabili. Il rischio è l’opposto: distanza dal contesto reale dei servizi, tendenza a fornire soluzioni che non si adattano bene all’uso quotidiano e una dinamica del “cliente interno” che a volte genera più burocrazia che agilità. Le organizzazioni SRE mature spesso utilizzano entrambi i modelli contemporaneamente: un team della piattaforma responsabile dell'infrastruttura di base e SRE integrati nei team di prodotto ad alto rischio.
Come appare la transizione dall'interno
Per coloro che provengono dal lato operativo, l’adozione di SRE è spesso scomoda. L'aspettativa è che il lavoro si sposti dalla "risoluzione degli incidenti" alla "prevenzione che gli incidenti si ripetano attraverso il codice e l'automazione". Ciò richiede un cambiamento di identità: il professionista che era apprezzato per la sua capacità di spegnere gli incendi ora ha il compito di ridurre il tasso di incendi. Non tutti vogliono o possono effettuare questa transizione e fingere che sia semplice crea frustrazione.
Per coloro che provengono dal lato dello sviluppo, la regolazione è diversa. I team di prodotto devono accettare di avere ora la corresponsabilità per l’affidabilità dei servizi che forniscono. SRE introduce l'idea che le operazioni non sono "un problema di un'altra area": fanno parte del lavoro di ingegneria. Ciò si scontra con le culture in cui gli sviluppatori scrivono codice e lo "lanciano oltre il muro" affinché le operazioni se ne occupino. Il cambiamento culturale qui è importante quanto qualsiasi strumento o processo.
Dove l'adozione tende a interrompersi
I guasti SRE più comuni seguono modelli riconoscibili. Il primo è adottare il vocabolario senza adottare la sostanza: i team che definiscono gli SLO ma non hanno un meccanismo per agire quando il budget di errore è esaurito stanno solo documentando le aspettative, non gestendo il rischio. Il secondo errore comune è affidare completamente l’affidabilità al team SRE, sollevando i team di prodotto da qualsiasi responsabilità. Questo ricostruisce esattamente il silo che SRE è stato progettato per eliminare.
Il terzo punto di fallimento è la sottovalutazione degli investimenti nell’automazione. La filosofia SRE funziona solo se il lavoro manuale operativo viene sistematicamente ridotto. Senza tempo e risorse dedicati a questo, il team affoga nella fatica: un lavoro ripetitivo e reattivo che non genera valore accumulato. Un'adozione onesta di SRE richiede una leadership che protegga attivamente il tempo di progettazione del team rispetto alle esigenze operative a breve termine. Senza questo impegno esplicito, SRE diventa solo un costoso rebranding.
Leggi anche
- Metriche di ingegneria dell'affidabilità del sito: definizione e monitoraggio di SLI, SLO e SLA
- Risposta moderna agli incidenti: dal rilevamento al post-mortem senza drammi
- Copertura del test: Guida completa
- Test automatizzati: architettura e fondamenti
- Test di carico: cosa sono e perché il tuo sistema dovrebbe farli davanti al cliente
- Test di carico - Modelli di business per piccoli team