Cosa risolve SRE
Benvenuto in Site Reliability Engineering
Site Reliability Engineering (SRE) è nato in Google nel 2003. Ben Treynor Sloss ha preso in carico un piccolo team di operations e lo ha ricostruito come se fossero gli ingegneri, non i pager umani, a gestire la produzione. Il risultato è diventato il modello standard per far funzionare grandi servizi internet.
I team di operations tradizionali mantenevano i servizi in esecuzione attraverso lavoro manuale: riavviare questo server, avvisare quell'ingegnere, scrivere un runbook, sperare che regga. Quel modello si rompe alla scala. Un team di cinquanta operatori non può riavviare manualmente cinquemila server. Oltre una certa dimensione, le operazioni manuali diventano una tassa che consuma ogni ora produttiva.
SRE capovolge il modello. Invece di assumere più operatori quando i sistemi crescono, SRE assume ingegneri software e dice loro: scrivete codice che esegua il lavoro operativo al posto vostro. Il vostro lavoro si qualifica come ingegneria del software applicata ai problemi operativi. Il vostro output: automazione, monitoraggio e affidabilità ingegnerizzata, non interventi manuali.
Tre idee fondamentali guidano la pratica SRE:
- Service Level Objectives (SLO): obiettivi numerici di affidabilità, concordati in anticipo
- Error budget: l’inverso di uno SLO, speso per assumere rischi
- Eliminazione del toil: qualsiasi lavoro operativo che scala linearmente con le dimensioni del sistema deve scomparire
Queste tre idee si riflettono in ogni pratica SRE: post-mortem, turni di on-call, pianificazione della capacità, monitoraggio e release engineering.
Operazioni tradizionali versus SRE
Perché le Operazioni tradizionali falliscono alla scala
Un tipico team ops cresce linearmente con i sistemi che gestisce. Raddoppiare i server significa raddoppiare gli operatori. Questo ha senso finanziario per piccoli deployment, ma è disastroso su larga scala: non puoi assumere per uscire da un problema quadratico.
SRE limita il lavoro operativo al cinquanta percento del tempo di un ingegnere. L'altra metà deve essere dedicata all'ingegneria: costruire tool, automatizzare processi, eliminare il toil che li ha portati al cinquanta percento. Se il toil supera il cinquanta percento per troppo tempo, il team deve restituire lavoro a un team di sviluppo o assumere altri SRE. La regola del cinquanta percento impedisce a un team SRE di collassare in un team ops tradizionale sotto pressione sostenuta.
Confronta le modalità di fallimento:
- Traditional ops: più incidenti portano a più risposte manuali, che lasciano meno tempo per la prevenzione, che crea più incidenti. Un ciclo vizioso.
- SRE: più incidenti innescano post-mortem, che fanno emergere opportunità di automazione, che riducono il tempo di risposta al prossimo incidente. Un ciclo virtuoso, quando funziona.
SLI, SLO, SLA
Tre lettere che governano la produzione
L’affidabilità senza misurazione è teatro. SRE trasforma l’affidabilità in un numero, concordato in anticipo, che tutti possono verificare.
Service Level Indicator (SLI): una misurazione del comportamento del servizio. Esempi: latenza delle richieste, tasso di errori, throughput, profondità della coda. Un SLI è una cosa che puoi rappresentare su un grafico.
Service Level Objective (SLO): un valore o un intervallo obiettivo per un SLI. Esempio: "il 99,9% delle richieste HTTP ha successo in una finestra mobile di 28 giorni". Un SLO è una promessa che fai a te stesso e ai tuoi utenti sulla qualità accettabile del servizio.
Service Level Agreement (SLA): un impegno contrattuale, generalmente con penali economiche in caso di violazione. Esempio: "Rimborsiamo il 10% se la disponibilità mensile scende sotto il 99,9%". Un SLA è una promessa fatta rispettare dagli avvocati.
Distinzione fondamentale: il tuo SLA deve essere sempre più lasco del tuo SLO. Se punti internamente al 99,9% e contratti esternamente il 99,9%, non hai margine. Gli SRE tipicamente impostano gli SLO con un nove in più rispetto all'SLA: obiettivo 99,95%, contratto 99,9%. Il margine assorbe la settimana negativa inevitabile.
Error Budget: l'SLO inverso
Dai target di affidabilità alle decisioni ingegneristiche
Un SLO definisce un target di affidabilità. L'error budget è ciò che resta: la quantità di failure che puoi spendere prima di mancare il target.
Se il tuo SLO promette il 99,9% di successi su 28 giorni, il tuo error budget è lo 0,1% delle richieste, ovvero circa 40 minuti di downtime totale al mese. Questo budget è tuo da spendere come preferisci: su release pianificate, su feature sperimentali, su chaos engineering o per tollerare una dipendenza instabile.
Gli error budget trasformano il conflitto tra dev e ops. Senza un budget, ogni outage scatena discussioni su chi ha rilasciato la modifica difettosa e su come evitare la prossima. Con un budget:
- Budget residuo: procedi più velocemente, prendi più rischi, esegui esperimenti. Il budget li copre.
- Budget esaurito: smetti di lanciare nuove feature, congela le modifiche rischiose, concentrati sul lavoro di affidabilità finché il budget non si ricostituisce.
Questo trasforma l'affidabilità da argomento emotivo in una risorsa misurabile. Gli ingegneri possono spendere il budget in modo deliberato, come qualsiasi altro input di produzione.
Definizione di Toil
Cosa si considera Toil
Non tutte le attività operative sono toil. SRE definisce il toil in modo preciso: lavoro manuale, ripetitivo, automatizzabile, tattico, privo di valore duraturo e che scala linearmente con la crescita del servizio.
Tutte e sei le proprietà devono essere presenti. Una migrazione dati una tantum è manuale ma non ripetitiva: non si qualifica come toil. Un ingegnere senior che progetta una nuova architettura di servizio prende una decisione tattica ma aggiunge valore duraturo: non si qualifica come toil.
Esempi che si qualificano come toil:
- Riavviare manualmente un servizio dopo un crash causato da memory leak
- Incollare frammenti di log in un canale di chat durante il triage di un incidente
- Compilare un modulo ticket per il provisioning di un nuovo database
- Esecuzione manuale di un report trimestrale sulla capacità
- Approvazione uno per uno delle richieste di deployment di routine
La regola del cinquanta percento limita il toil al massimo al 50% del tempo di un SRE. Oltre il 50%, il team deve restituire la responsabilità a un team di prodotto o assumere altri ingegneri, ma l’obiettivo resta chiaro: ridurre il toil verso lo zero sostituendolo con sistemi ingegnerizzati che svolgono lo stesso lavoro senza intervento umano.
L’automazione non si limita a far risparmiare tempo. Elimina completamente una classe di errori umani. Uno script che effettua il provisioning di un database non dimentica passaggi dopo un turno lungo.
Ragionamento sull’Audit del Toil
Il tuo team tiene traccia di come viene impiegato il suo tempo. Nell’ultimo trimestre la ripartizione era: 30% deploy, 25% risposta agli incidenti, 20% lavoro sulla capacità, 15% feature engineering, 10% richieste una tantum dai team di prodotto.
Igiene dell'On-Call
Engineer, non Pager
Essere di reperibilità ha un costo reale. Il sonno viene interrotto, i weekend vengono disturbati e lo stress per problemi imprevisti si accumula. SRE considera la reperibilità come una risorsa finita che deve rimanere sostenibile, non un onere eroico sostenuto da chi si preoccupa di più.
Le rotazioni di reperibilità sane seguono diversi principi:
- Tempo compensato: le ore di reperibilità corrispondono a tempo libero, retribuzione aggiuntiva o un beneficio equivalente. La reperibilità non retribuita porta al burnout del team.
- Profondità di rotazione ragionevole: un team di sei persone con reperibilità primaria e secondaria significa che ogni ingegnere svolge un turno ogni tre settimane. Le rotazioni a due persone distruggono le carriere.
- Budget di volume di paging: il libro SRE di Google suggerisce un massimo di due eventi di paging per turno di dodici ore. Oltre questo limite, il team deve investire tempo di engineering per ridurre il volume di alert, non solo sopportarlo.
- Solo alert azionabili: ogni pagina deve richiedere un'azione umana. Se una pagina verrebbe ignorata, automatizzata o si attiva ripetutamente durante il normale funzionamento, non dovrebbe esistere. L'alert fatigue è un difetto di affidabilità.
- Passaggi di consegne follow-the-sun: i team distribuiti globalmente si passano i turni ai confini dei fusi orari, in modo che nessuno riceva pagine alle 3 del mattino a meno che il sistema non possa davvero aspettare fino al mattino.
Blameless Postmortems
Come gli Outage Diventano Miglioramenti
Ogni incidente significativo prevede un postmortem: un’analisi scritta di cosa è successo, perché, cosa lo ha risolto e quali cambiamenti prevengono il ripetersi. Il postmortem è l’equivalente SRE dell’interesse composto: ognuno aggiunge affidabilità permanente al sistema.
Blameless significa che il documento attribuisce i fallimenti a sistemi e processi, mai alle persone. Se un ingegnere ha eseguito il comando sbagliato, il postmortem chiede: perché il sistema ha permesso quel comando? Perché nessun controllo lo ha intercettato? Quale modifica al sistema, alla documentazione o agli strumenti impedirebbe al prossimo ingegnere di commettere lo stesso errore?
La blamelessness esiste per un unico motivo: le persone nascondono gli errori quando temono punizioni. Gli errori nascosti diventano il prossimo incidente. Il costo di una cultura blameless è basso rispetto al costo di accumulare difetti non dichiarati.
I postmortem tipicamente coprono:
- Riepilogo: descrizione in un paragrafo dell’incidente e dell’impatto
- Timeline: ricostruzione minuto per minuto con timestamp
- Analisi delle cause radice: fattori tecnici e di processo che hanno permesso il fallimento
- Rilevamento: come il team ha scoperto l'incidente e quanto tempo ha impiegato
- Risoluzione: le azioni intraprese per ripristinare il servizio
- Lezioni apprese: cosa ha funzionato e cosa no
- Action items: task di ingegneria concreti, assegnati e con scadenza
Gli action items vivono in un tracker. Vengono prioritizzati come qualsiasi altro lavoro di ingegneria. I post-mortem senza action items si riducono a un racconto. Il lavoro non cambia nulla.
I Quattro Golden Signals
Cosa deve misurare ogni servizio
Il libro SRE di Google propone quattro segnali che ogni servizio rivolto agli utenti deve esporre: latency, traffic, errors e saturation. Insieme descrivono lo stato di salute del servizio dal punto di vista dell'utente. Monitorare con meno segnali lascia punti ciechi; monitorare con centinaia di metriche sommerge il team in alert fatigue.
Latency: quanto tempo impiegano le richieste. Tracciare le distribuzioni, non le medie. p50 (mediana) descrive l'esperienza tipica. p99 descrive l'1% peggiore degli utenti. La media da sola nasconde le code lunghe: un servizio con mediana 50 ms e p99 5.000 ms appare normale sulla media ma rovina un utente su cento.
Traffic: la domanda sul servizio. Per un servizio web significa richieste al secondo. Per un servizio di streaming, connessioni simultanee. Per un job batch, elementi elaborati al minuto. Il traffico correla con le decisioni di capacità e rivela anomalie nel carico di lavoro.
Errors: il tasso di richieste fallite. Contano sia i fallimenti espliciti (HTTP 500), sia quelli impliciti (HTTP 200 con dati corrotti), sia i fallimenti di policy (risposta troppo lenta per rispettare lo SLO). Distinguere tra questi è importante: un 200 con payload errato spesso danneggia gli utenti più di un onesto 500.
Saturazione: quanto è pieno il sistema. Utilizzo CPU, profondità della coda, pressione della memoria, occupazione del pool di connessioni. La saturazione prevede la latenza futura: un sistema al 95% di CPU ha pochissimo margine prima che la latenza percepita dagli utenti aumenti bruscamente.
La maggior parte degli alert SRE deriva da questi quattro segnali. L'alerting basato sui sintomi (avvisa quando gli utenti lo noterebbero) è superiore all'alerting basato sulle cause (avvisa quando la CPU supera l'80%). I quattro golden signals descrivono i sintomi.
Percorsi di carriera SRE
Dove le competenze SRE sono più richieste
Le carriere SRE si differenziano in base a quale aspetto della disciplina l'ingegnere apprezza di più:
Infrastructure SRE: costruisce le piattaforme su cui operano gli altri team. Kubernetes, service mesh, cloud interno. Forte focus su systems engineering, teoria dei sistemi distribuiti e progettazione di piattaforme. Remunera molto bene nelle grandi aziende perché il lavoro scala: un solo Infrastructure SRE supporta centinaia di product engineer.
Embedded SRE: collabora con un team di product engineering per migliorare l’affidabilità di un servizio specifico. Metà ingegnere, metà coach. Le capacità di comunicazione e code review contano tanto quanto la profondità tecnica. Spesso è il percorso migliore per gli ingegneri che amano insegnare.
Reliability tooling: costruisce lo stack di osservabilità: monitoring, alerting, dashboard, tool per i post-mortem e piattaforme di gestione degli incidenti. Forte lavoro su frontend e data engineering. Il risultato viene utilizzato da tutti gli altri team.
Production engineering: il termine usato da Facebook/Meta per indicare l’SRE focalizzato su capacità, deployment e gestione del traffico. Forte lavoro su networking e sistemi.
Certificazioni tecniche da possedere: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional e le certificazioni CNCF (Kubernetes Administrator, Kubernetes Application Developer) indicano una solida padronanza del cloud-native. Le certificazioni della Linux Foundation segnalano una solida conoscenza dei sistemi. Nessuna di queste sostituisce il lavoro sul portfolio, ma aiutano a superare i filtri dei recruiter.
Conclusione
Cosa Sai Ora
Site reliability engineering è nato come risposta di Google a un problema di scalabilità ed è diventato una disciplina ora praticata in tutto il settore. Hai trattato:
- Il passaggio dalle operazioni manuali all'affidabilità progettata
- SLI, SLO, SLA e il concetto di error budget come inverso dell'SLO
- La definizione di toil, la regola del 50% e la riduzione guidata dall'ingegneria
- Rotazioni di on-call sostenibili e pratica dei post-mortem senza colpe
- I quattro segnali d'oro come punto di partenza per il monitoraggio dei servizi
- I percorsi di carriera SRE e le certificazioni che aprono le porte
Due idee contano di più. L’affidabilità è un numero, concordato in anticipo. E il toil è un difetto, non una descrizione del lavoro. Porta avanti queste due idee e il resto di SRE segue naturalmente.
Lettura consigliata: il libro SRE di Google (gratuito online: sre.google/books/), l’SRE Workbook per esercizi pratici e gli scritti di Charity Majors sull’osservabilità. La lezione companion geometry-of approfondisce la struttura visiva alla base della pratica SRE: distribuzioni di latenza, coni di error budget, grafi delle dipendenze e layout delle dashboard.