# Cos'è uno SLO? Guida pratica per i team di piattaforma URL: https://upstreamapi.com/it/journal/cos-e-uno-slo Type: blog Locale: it Published: 2026-10-31 Updated: 2026-11-01 --- > Una risposta semplice su cos'è uno SLO, come funzionano budget di errore e alert di burn rate, e come collegare il numero ai rilasci. Cos'è uno SLO? Uno SLO (service level objective) è un obiettivo di affidabilità per un comportamento preciso che l'utente percepisce, misurato su una finestra temporale fissa. "Il 99.9% delle richieste di checkout va a buon fine in meno di 800 ms, su 30 giorni" è uno SLO. "Il sito deve essere veloce" è un desiderio. Il numero conta meno di ciò che controlla: lo SLO decide quando continuare a rilasciare e quando fermarsi. Sono le 03:12. PagerDuty segnala che la latenza del checkout è "elevata". Apri la dashboard e vedi una linea di p99 che da quaranta minuti sale piano. Nessuno sa dire se sia un problema, perché nessuno ha mai scritto quanta latenza è troppa. La discussione che segue, in call, con un occhio su Slack, è il costo di non avere uno SLO. ![Telefono illuminato su un comodino di notte durante un allarme di reperibilità](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/da5f84-i1.webp) ## SLI, SLO, SLA: tre parole, tre responsabili Le persone li usano come sinonimi. Non sono la stessa cosa, e confonderli è il modo in cui un team finisce per firmare un contratto che non può rispettare. - **SLI (service level indicator)** è la misura. Un rapporto tra eventi buoni ed eventi validi: richieste con risposta 2xx in meno di 800 ms, divise per tutte le richieste che avrebbero dovuto ricevere una risposta. - **SLO (service level objective)** è l'obiettivo per quel rapporto su una finestra temporale. 99.9% su 30 giorni. - **SLA (service level agreement)** è il contratto con il cliente, con dei soldi in ballo se lo manchi. È sempre meno stringente dello SLO. Se il tuo SLA dice 99.9% e il tuo SLO dice 99.9%, non hai margine per accorgerti di un problema prima di dover dei rimborsi. Il [capitolo del libro SRE di Google sugli service level objective](https://sre.google/sre-book/service-level-objectives/) traccia la stessa linea: lo SLO è un obiettivo interno, più stringente di qualsiasi cosa prometti all'esterno. Gli ingegneri possiedono SLI e SLO. Prodotto e legale possiedono lo SLA. Evita l'istinto di aggiungere una quarta parola per ogni metrica che già raccogli. CPU, memoria e profondità delle code sono utili per il debugging. Non sono SLI, perché nessun cliente le percepisce direttamente. ## Come si presenta un buon SLI in pratica Un buon SLI è un rapporto, viene misurato il più vicino possibile all'utente e ha una definizione chiara di "buono". Per un servizio guidato dalle richieste, il punto di partenza sono due SLI: disponibilità (risposte non 5xx sul totale delle richieste valide) e latenza (richieste sotto una soglia sul totale delle richieste valide). Usa una soglia, non una media. La media nasconde la coda, e la coda è dove arrivano i ticket di supporto. Misura al load balancer o all'edge, non dentro il servizio. Un servizio che va in crash all'avvio riporta un tasso di errore perfetto per le richieste che non ha mai ricevuto. Le metriche lato server sono cieche davanti a questo guasto, mentre l'utente lo vive come un'interruzione. Sii esplicito su cosa escludi. Gli health check, le probe sintetiche del tuo monitoraggio e le risposte 4xx causate da input errati del client di solito non devono pesare sullo SLO. Scrivi le esclusioni accanto allo SLO. Quando durante una revisione di incidente qualcuno discute il numero, la discussione deve riguardare la definizione, non ciò che la dashboard mostra per caso. ## L'aritmetica che nessuno fa prima di scegliere i nove Ogni nove in più riduce di dieci volte il downtime consentito. Questa è la tabella da tenere nel documento. - **99%** su 30 giorni: 1% di budget di errore, 7.2 ore di interruzione totale consentita. - **99.9%**: 0.1% di budget, 43.2 minuti. - **99.95%**: 0.05% di budget, 21.6 minuti. - **99.99%**: 0.01% di budget, 4.32 minuti. Rileggi l'ultima riga. Con il 99.99%, un singolo deploy sbagliato che impiega cinque minuti a essere rilevato e annullato ha già bruciato il mese. Un umano non riesce a rispondere a una pagina, aprire il laptop e fare il revert in meno di quattro minuti: quel target è raggiungibile solo con l'automazione, un gate che blocca il rollout prima che il budget finisca. Scegli quindi il numero di cui il servizio ha davvero bisogno. La maggior parte delle API interne sta bene al 99.9%. Un percorso di pagamento può giustificare di più. Un job batch notturno può andare bene al 99%. Scegliere il 99.99% perché "suona serio" è il modo in cui un team si iscrive a una reperibilità che non riesce a coprire. ![Clessidra con quasi tutta la sabbia scesa, a rappresentare un budget di errore esaurito](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/a422c2-i2.webp) ## Il budget di errore è il punto, non lo SLO Uno SLO al 99.9% significa che puoi fallire lo 0.1% delle volte. Quello 0.1% è il tuo budget di errore, ed è l'idea più utile di tutta la disciplina. Il budget trasforma una discussione in un numero. Il prodotto vuole rilasciare la migrazione rischiosa. Il SRE dice che è rischiosa. Senza budget è un'opinione contro un'altra, e vince l'anzianità. Con il budget la domanda diventa: quanto ne resta, e quanto può plausibilmente consumarne questo cambiamento? Due regole lo fanno funzionare. - **Budget residuo: rilascia.** Puoi prendere dei rischi, quindi prendili. Un team che non consuma mai il proprio budget investe troppo in affidabilità che gli utenti non hanno chiesto. - **Budget esaurito: blocca.** Il lavoro sulle funzionalità si ferma finché il lavoro di affidabilità non riporta lo SLI sopra il target. Funziona solo se la leadership l'ha concordato prima del primo incidente, non durante. Se la seconda regola non è concordata in anticipo, non hai uno SLO. Hai una dashboard con una zona verde e una zona rossa. ## Allertare sul burn rate, non sullo SLI stesso È qui che la maggior parte dei primi tentativi fallisce. Qualcuno imposta un alert quando la disponibilità scende sotto il 99.9%. L'alert scatta quando il danno è già fatto, oppure oscilla a ogni piccolo blip, o entrambe le cose. Il segnale migliore è il **burn rate**: quanto velocemente stai consumando il budget rispetto al ritmo che lo esaurirebbe esattamente alla fine della finestra. Un burn rate di 1 significa che chiuderai il mese con zero budget. Un burn rate di 14.4 significa che sei sulla strada per bruciare il budget di un mese in circa due giorni. Il [Google SRE Workbook sull'alerting sugli SLO](https://sre.google/workbook/alerting-on-slos/) consiglia di abbinare una finestra lunga e una corta, così l'alert è significativo e il problema è ancora in corso. Per uno SLO di 30 giorni, due pagine sono un buon punto di partenza: - Burn rate 14.4 su 1 ora, confermato su 5 minuti: consuma il 2% del budget mensile. Avvisa qualcuno. - Burn rate 6 su 6 ore, confermato su 30 minuti: consuma il 5% del budget mensile. Avvisa qualcuno. L'aritmetica è semplice. Una finestra di 30 giorni corrisponde a 720 ore. Bruciare a 14.4x per un'ora usa 14.4 / 720 = 2% del budget. La finestra corta evita che l'alert scatti un'ora dopo la fine del problema. Ecco la prima regola scritta come alert Prometheus, supponendo che tu registri un tasso di errore per ogni finestra: `groups: - name: checkout-slo-burn rules: - alert: CheckoutErrorBudgetFastBurn expr: | job:checkout_error_ratio:rate1h > (14.4 * 0.001) and job:checkout_error_ratio:rate5m > (14.4 * 0.001) labels: severity: page annotations: summary: "Il checkout sta consumando il 2% del budget di errore di 30 giorni ogni ora"`Lo 0.001 è il tasso di errore ammesso per uno SLO al 99.9%. Se cambi il target, anche quella costante cambia. Tienila in un solo posto, altrimenti alert e SLO si disallineano senza che nessuno se ne accorga. I consumi più lenti non richiedono una pagina. Un burn rate di 1 sostenuto per tre giorni va in un ticket per la mattina lavorativa successiva. Svegliare qualcuno per una perdita lenta è il modo in cui i team di reperibilità imparano a ignorare il pager. ![Corridoio di un data center con rack di server e luci di stato](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/f23ee5-i3.webp) ## Dove calcolare lo SLI senza comprare una seconda piattaforma Non ti serve un prodotto SLO dedicato per iniziare. Ti servono un contatore di eventi buoni, un contatore di eventi totali e un posto dove conservarli per 30 giorni. Se le metriche vivono già su una piattaforma hosted, la funzione SLO è di solito un livello sottile sopra dati per cui paghi già. Datadog copre gli SLO in modo nativo, con alert di burn rate, ed è la strada più semplice se tracce e metriche sono già lì. Il conto è il punto critico: le metriche custom e i tag ad alta cardinalità si moltiplicano in fretta, quindi verifica il prezzo delle serie SLI prima di impegnarti. Se usi Prometheus, Grafana copre lo stesso terreno con le regole di registrazione e i suoi strumenti per gli SLO, al prezzo di più configurazione e più tempo tuo. Il confronto onesto è tra tempo al primo alert utile e costo a scala. Datadog vince il primo. Grafana con Prometheus di solito vince il secondo. Scegli in base a ciò di cui il tuo team ha meno. ## Collegare lo SLO al rollout, la parte che la maggior parte dei team salta Uno SLO che produce solo un report è usato a metà. Il passaggio che cambia i comportamenti è collegare il budget al percorso di deploy, così il rilascio si ferma da solo. Un rollout progressivo con gate SLO funziona così. Rilascia al 1% del traffico dietro un flag. Osserva lo SLI di quella coorte rispetto alla baseline. Se il burn rate della coorte canary supera la soglia, torna indietro in automatico. Se regge, passa al 5%, poi al 25%, poi al 100%. È diverso da una dashboard che qualcuno dovrebbe guardare alle 03:12. Alle 03:12 non vuoi pensare. Vuoi un pulsante, o meglio nessun pulsante. È qui che i feature flag si ripagano, perché un flag trasforma un revert in una modifica di configurazione che richiede secondi invece di un redeploy che ne richiede dieci. LaunchDarkly e piattaforme simili ti danno il rollout a percentuale e lo switch di emergenza. Quello che la maggior parte lascia a te è la decisione: quale SLI leggere, quale soglia conta come negativa, chi può fare override. È il vuoto che un pilot automatico con auto-rollback sullo SLO vuole colmare, ed è l'angolo che prendiamo in upstreamapi. LaunchDarkly vince per ampiezza di SDK e controlli enterprise, e lo diciamo. Ecco la forma del gate in TypeScript. La logica di decisione è la parte che vale la pena scrivere da sé, qualunque sia il sistema di flag che usi: `type Cohort = { good: number; total: number }; const SLO_TARGET = 0.999; const BUDGET = 1 - SLO_TARGET; // 0.001 const PAGE_BURN_RATE = 14.4; function burnRate(c: Cohort): number { if (c.total === 0) return 0; const errorRatio = 1 - c.good / c.total; return errorRatio / BUDGET; } export function rolloutDecision(canary: Cohort): "advance" | "hold" | "revert" { if (canary.total < 500) return "hold"; // traffico insufficiente per giudicare return burnRate(canary) > PAGE_BURN_RATE ? "revert" : "advance"; }`Nota il ramo `hold`. Un canary all'1% di un servizio tranquillo può vedere quaranta richieste in dieci minuti, e un errore su quaranta è un tasso di errore del 2.5%. Senza un campione minimo, il gate torna indietro sul rumore e il team impara a non fidarsi. ## Gli errori che vediamo continuamente nei team da 80 ingegneri Gli stessi pochi errori ricorrono in molti team, e quasi nessuno è tecnico. - **Troppi SLO.** Venti obiettivi per servizio significano che nessuno ne ricorda nessuno. Due o tre per percorso utente bastano. - **SLO su cui nessuno ha concordato.** Un ingegnere li scrive da solo nel weekend. Il prodotto non li ha mai visti, quindi la policy sul budget crolla la prima volta che dice "no" a un lancio. - **SLO fissati sulla performance attuale.** Se il servizio gira al 99.97% oggi, fissare il target al 99.97% non lascia budget e garantisce un mancato rispetto. Fissalo dove gli utenti iniziano a essere insoddisfatti, che quasi sempre è più in basso. - **Trattare lo SLO come permanente.** Rivedi il numero ogni trimestre. Se non consumi mai il budget, stringi il target o rilascia più in fretta. Se lo bruci ogni mese, correggi il sistema o ammetti che il target era un'illusione. - **Contare ciò che è facile invece di ciò che si sente.** Una risposta 200 con un carrello vuoto è un successo nei tuoi log e un fallimento per il cliente. Definisci "buono" dal lato dell'utente. ## Chi dovrebbe scrivere il primo questa settimana Non ti serve un programma. Scegli il percorso che farebbe chiamare il CEO a qualcuno se si rompesse. Definisci per esso un SLI di disponibilità e uno di latenza. Fissa il target al 99.9% per il primo trimestre, scrivi la policy di blocco in due frasi e fai rispondere per iscritto "concordato" al prodotto. Poi aggiungi un alert di burn rate e un posto dove vedere il budget residuo, visibile a tutto il team. Se ti serve un posto leggero dove iniziare prima di impegnarti in una piattaforma completa, Better Stack gestisce il monitoraggio di uptime e la notifica degli incidenti con una configurazione molto più semplice, anche se i calcoli del budget non te li regala. La prima versione sarà sbagliata. Va bene. Ciò che conta è che la prossima revisione dell'incidente parta da un numero che hai scritto in anticipo, invece che da una sensazione. ## E tu, come sarebbe la tua 03:12 adesso? Pensa all'ultimo incidente che il tuo team ha avuto. C'era un numero scritto che diceva se contava davvero? Se la risposta onesta è no, quello è il tuo primo SLO, e il post-mortem ti ha già detto cosa misurare. ## FAQ ### Cos'è uno SLO in parole semplici? Uno SLO è un obiettivo di affidabilità per un comportamento specifico visto dall'utente, misurato su una finestra fissa, per esempio il 99.9% delle richieste riuscite in 30 giorni. Indica quanto fallimento è accettabile e quando fermare i rilasci. ### Qual è la differenza tra SLI, SLO e SLA? L'SLI è la misura, un rapporto tra eventi buoni ed eventi validi. Lo SLO è l'obiettivo interno per quel rapporto. Lo SLA è il contratto con il cliente, con penali, e deve essere sempre meno stringente dello SLO. ### Quanto downtime consente un 99.9%? Su una finestra di 30 giorni, il 99.9% consente 43.2 minuti di interruzione totale. Il 99% ne consente 7.2 ore, il 99.95% 21.6 minuti e il 99.99% 4.32 minuti. ### Cos'è un budget di errore? Il budget di errore è 100% meno il target dello SLO. Con il 99.9% è lo 0.1% degli eventi. Finché resta budget, il team può prendersi rischi nei rilasci. Quando si esaurisce, il lavoro sulle funzionalità si ferma finché l'affidabilità non torna. ### Cos'è il burn rate negli alert SLO? Il burn rate indica quanto velocemente si consuma il budget di errore rispetto al ritmo che lo esaurirebbe esattamente alla fine della finestra. Un burn rate di 14.4 sostenuto per un'ora consuma il 2% del budget di 30 giorni. ### Quanti SLO dovrebbe avere un servizio? Due o tre per percorso utente critico sono sufficienti, di solito un SLI di disponibilità e uno di latenza. Oltre, nessuno li ricorda e nessuno cambia una decisione in base a essi. ### Da quale target di SLO conviene partire? Parti dal 99.9% per il percorso utente più importante, rivedilo dopo un trimestre e fissalo dove gli utenti iniziano a notare problemi, non sulla performance attuale.