Cos'è il site reliability engineering SRE? Guida pratica

Cos'è il site reliability engineering SRE? È l'idea di trattare le operazioni come un problema di software: fissi un obiettivo di affidabilità misurabile, tieni traccia di quante volte lo manchi e lasci che quel numero decida se rilasciare funzionalità o sistemare le cose. Google ha coniato il termine, ma il principio funziona a ogni dimensione. Per un dev solo con una app e qualche decina di utenti, significa decidere in anticipo quanto downtime sei disposto ad accettare.

Il problema pratico è che la maggior parte dei side project non ha nessun numero del genere. Sono «su» finché qualcuno non ti scrive. Questa guida spiega l'SRE in parole semplici, poi lo riduce a qualcosa che una persona sola può far girare in un weekend.

Cos'è davvero il site reliability engineering?

La versione breve arriva dal libro SRE di Google: l'SRE è quello che ottieni quando chiedi a un ingegnere del software di progettare un team di operazioni. Invece di riavviare i server a mano, scrivi codice che lo fa, e misuri i risultati.

Tre idee portano gran parte del peso. L'affidabilità è una funzionalità con un obiettivo, non una sensazione. Il lavoro manuale e ripetitivo (il libro lo chiama toil) è un difetto da automatizzare. E il guasto è previsto, quindi pianifichi come imparare da lui invece di come evitare di dare la colpa a qualcuno.

DevOps e SRE si sovrappongono molto. La differenza pratica è questa: DevOps è una cultura in cui si rilascia e si gestisce il codice insieme, mentre l'SRE ti dà strumenti precisi per discuterne con i numeri. Non serve scegliere una squadra per usare i numeri.

Nella pratica, il vantaggio più concreto non è la teoria ma la conversazione. Quando il team (o tu con te stesso alle undici di sera) si chiede se rallentare o andare avanti, il dibattito smette di dipendere da chi alza più la voce. Il numero non risolve tutto, ma sposta la discussione da «mi sento sicuro» a «siamo al 60% del budget a metà mese».

Attenzione però a non trasformarlo in un rituale vuoto. Un SLO che nessuno guarda è peggio di niente, perché ti dà l'illusione del controllo. Se il numero non cambia mai una decisione, non è un SLO: è un grafico da mostrare alle riunioni.

SLI, SLO e SLA: tre sigle, un'idea ciascuna

Un SLI (service level indicator) è ciò che misuri. Per un'app web di solito è la percentuale di richieste andate a buon fine, oppure la percentuale che risponde sotto i 300 ms. Scegline uno o due. Non dodici.

Un SLO (service level objective) è l'obiettivo che fissi su quella misura, per esempio «il 99,9% delle richieste riesce nell'arco di 30 giorni». È interno: è una promessa che fai a te stesso.

Un SLA (service level agreement) è un contratto con un cliente, di solito con dei rimborsi se lo manchi. Se nessuno ti paga per l'uptime, non hai ancora un SLA, e non dovresti scriverne uno per sbaglio nel testo della pagina prezzi.

Error budget: la parte che cambia il modo di lavorare

L'error budget è semplicemente il 100% meno il tuo SLO. Un obiettivo del 99,9% su 30 giorni lascia circa 43 minuti di guasto ammesso. È il budget che puoi spendere in rilasci rischiosi, migrazioni ed esperimenti.

La parte utile è la regola collegata. Finché c'è budget, rilasci. Quando è finito, smetti di rilasciare funzionalità e lavori sull'affidabilità finché il budget non si ricarica. Il capitolo del libro dedicato al rischio presenta questo meccanismo come un modo per chiudere la discussione tra «andiamo più veloci» e «non rompiamo niente» con un numero condiviso invece che con una trattativa.

C'è anche un punto secco che vale la pena ripetere: il 100% quasi mai è l'obiettivo giusto. Chi usa una rete mobile instabile non distingue il 99,99% dal 99,9%, e ogni nove in più costa molto più del precedente. Non è un obiettivo perfetto. È un obiettivo praticabile.

Se vuoi il flusso concreto per scegliere gli indicatori e scrivere il primo obiettivo, il capitolo del workbook sull'implementazione degli SLO è il più pratico, e si legge in fretta.

Che cosa fa un SRE tutto il giorno?

In un'azienda grande un SRE divide il tempo tra reperibilità, gestione degli incidenti, pianificazione della capacità e automazione. Il libro di Google dice di limitare il carico operativo a circa metà del tempo di un ingegnere, così che il resto vada all'ingegneria vera. Quel limite è un vincolo di progettazione, non un optional.

Il lavoro ricorrente è più o meno questo:

• definire gli SLO insieme ai team di prodotto e far scattare gli avvisi sul consumo del budget, non su ogni singolo picco

• organizzare la reperibilità e scrivere runbook, così la chiamata delle 3 di notte ha una checklist davanti

• guidare la risposta agli incidenti e poi scrivere un postmortem senza colpe

• automatizzare tutto ciò che si fa a mano più di qualche volta

• rivedere i lanci per i rischi di affidabilità prima che arrivino in produzione

I feature flag sono un buon esempio di questa mentalità. Un flag ti permette di spegnere una release difettosa in pochi secondi, senza un nuovo deploy, e così proteggi il budget. Se ti serve uno strumento hosted per questo dipende da quanti flag hai: una variabile d'ambiente basta per i primi tre.

Serve l'SRE se costruisci da solo?

Tre motivi per farlo, uno per non farlo.

I motivi per farlo: prima o poi il tuo progetto ti sveglierà di notte; un obiettivo scritto ti impedisce di cadere nell'over-engineering; e «gestisco la produzione con un SLO» rende bene quando qualcuno decide se assumerti o fidarsi di te. Il motivo per non farlo: se il progetto non ha ancora utenti, ti stai esercitando su un problema che non hai. Costruisci prima, misura quando qualcuno ci dipende.

Quindi salta l'apparato completo. Non pagare un servizio di reperibilità per un'app hobby, non usare Kubernetes per sembrare seri, e non scrivere un template di incidente di dieci pagine. Vale la pena farlo già con dieci utenti reali: un health check, un SLO e un posto dove guardare quando si rompe qualcosa.

Un setup SRE in una sera per un side project

Ecco il minimo che tende a reggere anche quando gli utenti arrivano a 10.000. Richiede una sera. Testato. Non ottimale. Lo facciamo lo stesso perché è noioso, e il noioso sopravvive.

Primo, scegli un solo SLI: la percentuale di richieste HTTP che non restituisce un 5xx. Secondo, imposta lo SLO al 99,5% su 30 giorni, che corrisponde a circa 3,6 ore di budget. Parti morbido e stringi dopo. Terzo, aggiungi un controllo di uptime esterno che colpisca un vero endpoint di salute.

Un endpoint di salute utile controlla le cose che si rompono davvero, non solo che il processo sia vivo:

// GET /healthz
app.get("/healthz", async (req, res) => {
  try {
    await db.query("select 1");          // database raggiungibile
    await cache.ping();                  // cache raggiungibile
    res.status(200).json({ ok: true });
  } catch (err) {
    res.status(503).json({ ok: false });
  }
});

Quarto, manda gli avvisi in un posto dove li vedrai davvero, una notifica push sul telefono e non una casella di posta. Quinto, tieni un file di testo semplice chiamato postmortems.md e aggiungi quattro righe dopo ogni outage: cosa è successo, perché, per quanto tempo, cosa cambia. È lo strumento di affidabilità più sottovalutato che avrai.

Un errore comune all'inizio è farsi svegliare ogni volta che fallisce una singola richiesta. Dopo una settimana silenzi il canale. Un segnale migliore è il burn rate: quanto velocemente stai consumando l'error budget, rispetto al ritmo che lo esaurirebbe esattamente alla fine della finestra. Per un side project tienilo grezzo: una notifica push se il tasso di errore degli ultimi 10 minuti supera il 5%, e un riepilogo via email se quello settimanale va verso la mancata dello SLO. Ti dà due livelli: svegliati adesso, oppure guarda il problema di lunedì. Il resto può aspettare finché non sono gli utenti a lamentarsi del primo livello.

Dove l'IA aiuta e dove no

Gli assistenti se la cavano bene con la parte ripetitiva: scrivere l'health check, il Terraform per un monitor di uptime, una prima bozza di runbook, oppure uno script che calcola il tasso di 5xx dai log. Sono scarsi nel decidere il tuo SLO, perché è una scelta di prodotto su quanto gli utenti tollerano.

Durante un incidente fai attenzione. Un assistente può proporre una correzione plausibile che tu applichi in produzione alle 2 di notte senza leggerla. Usalo per spiegare uno stack trace o per scrivere il postmortem dopo, e lascia la decisione sul rollback a una persona sveglia.

Anche i controlli di qualità del codice fanno parte di questo quadro. Molti outage derivano da una modifica che in review sembrava innocua. L'analisi statica in CI non ti dà affidabilità da sola, ma elimina una classe di errori stupidi prima che costino budget.

Come scrivere un postmortem che qualcuno legge

Tienilo breve e senza colpe. Senza colpe non vuol dire che nessuno è responsabile. Vuol dire chiedersi cosa, nel sistema, ha permesso l'errore, e non chi l'ha fatto. Quando sei l'unica persona del team, questo conta più di quanto sembri, perché la tentazione è sentirsi in colpa e saltare la stesura.

Bastano quattro titoli: cosa è successo, perché è successo, quanto tempo gli utenti sono stati colpiti, cosa cambia. L'ultimo deve nominare un'azione che farai davvero, con una data. «Stare più attento» non è un'azione. «Aggiungere un controllo in staging per le migrazioni prima del prossimo rilascio» lo è.

In un anno quel file diventa una mappa dei tuoi punti deboli. La regola dopo tre outage causati dallo stesso certificato scaduto è semplice: se la stessa causa torna due volte, automatizzala. Ci è voluta una sera per aggiungere il monitoraggio del rinnovo, e da allora il problema non si è più ripresentato.

Scegli un progetto che gestisci già, anche una app gratuita, e scrivi il suo SLI, il suo SLO e l'azione esatta che farai quando il budget finisce. Se non sai dire cosa smetteresti di fare, il numero è solo decorazione. Quale dei tuoi progetti noteresti che è giù prima che te lo dica un utente?