Cos'è uno SLO? Guida pratica per chi sviluppa da solo

Cos'è uno SLO? È un numero che ti prometti sulla frequenza con cui il tuo servizio deve funzionare, misurato su una finestra di tempo fissa. "Il 99.9% delle richieste va a buon fine in 30 giorni" è un SLO. Trasforma "il sito sembra a posto" in qualcosa che puoi verificare, e ti dice quando smettere di rilasciare funzionalità per sistemare le cose.

Non ti serve un team di piattaforma per questo. Un dev solo con una API e un database Postgres può scrivere un SLO utile in un pomeriggio. Ecco cosa significa il termine, come scegliere il numero e dove di solito si sbaglia.

Alle 2 di notte nessuno sapeva se l'app era rotta

Immagina un side project con 400 utenti settimanali. Una notte l'endpoint del checkout comincia a restituire errori 500 per una ventina di minuti. Nessuno scrive su Twitter, nessuno manda una mail. Lo scopri tre giorni dopo, da un unico messaggio di assistenza.

Era grave? Senza un obiettivo non puoi rispondere. Con un obiettivo sì: se il tuo SLO ammette circa 43 minuti di disservizio al mese e ne hai appena bruciati 20, sai di aver consumato quasi metà della tua quota in una sola brutta notte. È proprio questo lo scopo di uno SLO. Sostituisce una sensazione con un budget.

SLI, SLO e SLA, senza il tono da glossario

Si confondono SLI, SLO e SLA in continuazione, quindi ecco la versione breve.

Uno SLI (service level indicator) è una misura. "La percentuale di richieste HTTP che hanno restituito uno status diverso da 5xx negli ultimi 30 giorni" è un SLI. È un rapporto tra eventi buoni ed eventi totali.

Uno SLO (service level objective) è l'obiettivo per quella misura. "Quel rapporto deve restare almeno al 99.9%" è l'SLO. È interno: lo fissi tu, puoi cambiarlo, e nessuno ti fa causa per questo.

Uno SLA (service level agreement) è un contratto con conseguenze, di solito rimborsi o crediti. La maggior parte dei side project non ha un SLA, e va bene così. Puoi usare gli SLO anche senza. Il capitolo del workbook SRE di Google sull'implementazione degli SLO è il riferimento standard se vuoi la versione lunga.

L'ordine conta: prima scegli lo SLI, poi l'SLO, e pensi a un SLA solo se un cliente pagante lo chiede per iscritto.

Error budget: la parte che cambia il modo di lavorare

Uno SLO del 99.9% significa anche che lo 0.1% degli eventi può fallire. Quella quota di tolleranza è il tuo error budget, ed è la metà utile dell'idea.

In un mese di 30 giorni, una disponibilità del 99.9% lascia circa 43 minuti di downtime. Il calcolo è 30 giorni per 24 ore per 60 minuti, cioè 43.200 minuti, per 0.001. Un obiettivo del 99% dà circa 7.2 ore. Un obiettivo del 99.99% dà circa 4.3 minuti.

Gli ultimi due numeri spiegano perché la maggior parte dei piccoli progetti non dovrebbe puntare in alto. Quattro minuti al mese significano che un deploy sbagliato e un rollback fanno già saltare l'obiettivo. Ecco dove la gente inciampa nella pratica: più alzi l'asticella, più il tuo tempo va nel difendere il numero invece che nel costruire il prodotto.

Il budget dà anche una regola per decidere cosa costruire dopo. Budget quasi intatto: rilascia la funzionalità rischiosa. Budget bruciato: sistema prima il pezzo instabile. Nessuna riunione, basta un numero su una dashboard.

Facciamo un esempio con i numeri veri. Supponi uno SLO del 99.5% di disponibilità su 30 giorni, e circa 600.000 richieste al mese. Quell'obiettivo ammette lo 0.5% di fallimenti, quindi 3.000 richieste fallite prima che il budget sia esaurito.

Il giorno 9 una migrazione sbagliata restituisce 500 per 25 minuti e ti costa 1.100 richieste fallite. Hai usato circa il 37% del budget in una serata. Il giorno 17 un'API di terze parti va in timeout e ne brucia altre 900. Ora sei a circa il 67% speso, con 13 giorni davanti.

È il momento in cui il budget si fa valere. Non serve andare in panico, ma non devi nemmeno rilasciare il refactoring rischioso previsto per il giorno 20. Aggiungi un timeout e un fallback per quella chiamata esterna, scrivi il controllo sulla migrazione che avevi saltato, e sposti il refactoring al mese dopo.

Il senso non è che i fallimenti siano un male. I fallimenti sono previsti e già messi in conto. Quello che il numero ti dà è una risposta calma e condivisa alla domanda "possiamo permetterci questo rischio adesso?", anche quando nella stanza c'è una sola persona, cioè tu.

Come scegliere un SLI che puoi misurare davvero

Parti da cosa un utente chiamerebbe "rotto". Per una web app di solito si riduce a due domande: la richiesta è andata a buon fine, ed è stata abbastanza veloce?

Per la maggior parte dei side project, due SLI coprono il 90% del valore:

• Disponibilità: richieste buone diviso richieste totali, dove buona significa una risposta non 5xx.

• Latenza: la percentuale di richieste servite sotto una soglia, per esempio il 95% delle richieste sotto i 500 ms.

Nota che la latenza si scrive come percentuale di richieste sotto una soglia, non come media. La media nasconde la coda lenta, e la coda lenta è dove gli utenti mollano. Ragionare per percentili conta: una media di 300 ms può convivere con un p99 di 4 secondi.

Misura il più vicino possibile all'utente, al bordo del sistema. Un health check che pinga /healthz dall'interno della stessa VPC ti dice che il processo è vivo, non che gli utenti riescono ad accedere. Se puoi permetterti una sola misura, prova un percorso reale dell'utente, come login o checkout, dall'esterno.

Quale numero scegliere: partire più in basso di quanto sembri

La risposta onesta per un progetto nuovo è 99% o 99.5%. Guarda gli ultimi 30 giorni di dati, capisci cosa hai consegnato davvero, fissa l'SLO leggermente sotto quel valore, e stringilo più avanti se gli utenti si lamentano.

Ecco una guida orientativa per un progetto da solo:

• Tool hobby, senza ricavi: il 99% basta. Circa 7 ore di disservizio al mese sono invisibili alla maggior parte degli utenti.

• SaaS a pagamento con qualche decina di clienti: dal 99.5% al 99.9%, a seconda di quanto il prodotto dipende dal tempo.

• Tutto ciò da cui i clienti dipendono in orario di lavoro: 99.9%, e testa il tuo percorso di rollback prima di prometterlo.

Testato, non ottimale, e comunque vale la pena farlo: un SLO che raggiungi il 100% delle volte è un numero fissato troppo in basso, e un SLO che manchi ogni mese è un numero di cui nessuno si fida. Punta a mancarlo ogni tanto, perché è in quel momento che il budget fa il suo lavoro.

Rivedi ogni SLO una volta al trimestre, o dopo ogni mese in cui lo hai mancato di molto o non hai mai toccato il budget. Mancarlo due volte di fila significa che il sistema ha bisogno di lavoro vero, oppure che l'obiettivo era ambizioso per la fase in cui sei. Entrambe le cose sono informazioni utili.

Se arrivano clienti paganti, chiedi loro cosa vuol dire "rotto" per loro. Un cliente che usa un report settimanale si preoccupa del lunedì mattina, non di un blip di sabato sera, e il tuo SLO può riflettere questo con un obiettivo più stretto durante le sue ore.

Un SLO piccolo che puoi scrivere oggi, e quali strumenti servono

Un SLO non è solo monitoraggio uptime con qualche passo in più, anche se i due si sovrappongono. Un monitor ping ti dice che il sito ha risposto in un certo minuto. Uno SLO ti dice quale percentuale di richieste reali degli utenti ha funzionato in un mese, e cosa significa per la tua prossima decisione.

Immagina due settimane in cui un monitor ping resta verde ogni minuto, ma una query lenta sul database fa andare in timeout la pagina dashboard per il 3% degli utenti loggati. Il monitor dice che va tutto bene. L'SLI dice che hai mancato l'obiettivo di latenza. Solo uno dei due cambia quello che fai lunedì.

Tieni comunque il monitor ping. Costa poco e intercetta subito i disservizi totali. Trattalo come un input, non come la definizione di "funzionante".

Non ti serve un vendor per iniziare. Scrivi questo nel repo, in un file chiamato SLO.md:

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: tutte le richieste tranne /healthz
  latency:
    good: response_time < 500ms
    total: tutte le richieste tranne /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - sospendi le funzionalità non urgenti
  - sistema per primo la fonte di errore principale

Se il tuo stack esporta già i conteggi delle richieste, l'SLI di disponibilità in sintassi Prometheus è una sola riga:

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Quel rapporto, confrontato con il tuo obiettivo, è l'intera dashboard SLO. Il resto è rifinitura. Bastano tre pannelli: SLI attuale, budget rimasto e una linea del burn rate.

Grafana è la scelta predefinita per chi già esporta metriche Prometheus. Il piano gratuito è generoso per un side project, e la funzione SLO si appoggia sui dati che probabilmente hai già. Saltala se non hai ancora una pipeline di metriche e non hai voglia di costruirla.

New Relic ha un piano gratuito con 100 GB di dati ingeriti al mese e strumenti SLO integrati nella piattaforma. Fa per te se vuoi un setup basato su agent con poca configurazione. Il compromesso è che i costi diventano meno prevedibili una volta superata la soglia gratuita.

Datadog è l'opzione più completa e anche la più cara, con infrastruttura, APM e log fatturati a parte. Vale la pena se intorno a te cresce un team. Per un progetto da solo saltalo, a meno che non paghi qualcun altro.

Qualunque strumento scegli, resisti alla tentazione di definire quindici SLO il primo giorno. Uno SLO di disponibilità e uno di latenza per ogni servizio rivolto agli utenti bastano per imparare qualcosa.

Alert sul burn rate, non su ogni singolo picco

L'errore che fanno quasi tutti: mandare un alert ogni volta che il tasso di errore supera una soglia. Ti svegli alle 3 di notte per un picco di 90 secondi che è costato lo 0.2% del budget del mese.

Il burn rate risolve questo problema. Chiede quanto velocemente stai consumando il budget rispetto al ritmo che lo esaurirebbe esattamente alla fine della finestra. Un burn rate di 1 significa che chiudi il mese con il budget vuoto e senza sorprese. Un burn rate di 10 significa che sei a zero in tre giorni.

Per una persona sola un setup sensato sono due alert. Uno veloce, per esempio un burn rate sopra 10 su un'ora, che ti sveglia. Uno lento, per un burn rate intorno a 2 su un giorno, che diventa un ticket per la mattina. Il capitolo del libro SRE di Google sugli obiettivi di livello di servizio spiega il ragionamento dietro questa scelta, e la versione multi-finestra è nel workbook linkato sopra.

Tre errori che rendono gli SLO inutili

Misurare ciò che è facile invece di ciò che gli utenti percepiscono. L'uso della CPU non è un SLI. Agli utenti non importa che la CPU sia al 40%. Vogliono che la pagina si carichi.

Fissare il target dall'ambizione. "Vogliamo i cinque nove" suona serio e non significa nulla se il tuo database è un'unica istanza su una VM piccola. Fissa l'SLO dalla realtà osservata, poi migliora il sistema, e solo dopo stringi il numero.

Non usare mai il budget. Se chiudi ogni mese con il 98% del budget ancora disponibile, stai rilasciando troppo lentamente oppure il target è troppo largo. Un budget inutilizzato è capacità di rischio sprecata.

Quale servizio metteresti per primo sotto SLO? Scegli un endpoint che gli utenti noterebbero se si rompesse. Scrivi l'SLI in italiano semplice, fissa l'obiettivo mezzo punto sotto quello che hai consegnato il mese scorso, e ricontrollalo tra 30 giorni. Se vuoi un progetto da weekend che ti costringa a esercitarti, una piccola dashboard di uptime e latenza per le tue app è una buona idea. Quale dei tuoi servizi ti fideresti meno in questo momento?