Uno SLI (service level indicator) è una misurazione del comportamento del tuo servizio, come la quota di richieste andate a buon fine. Uno SLO (service level objective) è l’obiettivo interno per quella misurazione, come il 99,9% di controlli riusciti su 30 giorni. Uno SLA (service level agreement) è la promessa che fai ai clienti, di solito con un obiettivo più basso dello SLO e una conseguenza, come un credito di servizio, se non lo rispetti. L’indicatore è ciò che misuri, l’obiettivo è ciò a cui punti e l’accordo è ciò che firmi.
Questa guida spiega ogni termine con esempi, mostra cosa significano in minuti le percentuali di uptime e ti accompagna nella scelta degli indicatori per un sito web o un’API, nel decidere cosa conta come downtime e nello scrivere uno SLA comprensibile per i clienti.
I tre termini in parole semplici
SLI: la misurazione
Un service level indicator è un numero che puoi calcolare da dati reali. Quasi sempre è un rapporto: eventi positivi divisi per tutti gli eventi. Per un sito web può essere la quota di controlli di uptime che hanno restituito la risposta attesa. Per un’API può essere la quota di richieste che hanno risposto con uno stato diverso da 5xx in meno di 500 millisecondi. Uno SLI non ha un obiettivo associato. Dice semplicemente cosa è successo.
SLO: l’obiettivo
Un service level objective aggiunge a uno SLI un obiettivo e una finestra temporale. “Il 99,9% dei controlli sul checkout va a buon fine, misurato su 30 giorni mobili” è uno SLO. È uno strumento interno. Dice al team quando l’affidabilità è sufficiente per continuare a rilasciare funzionalità e quando è il momento di rallentare e sistemare le cose.
SLA: il contratto
Un service level agreement è la promessa verso l’esterno, scritta in un contratto o nei termini di servizio. Indica il servizio, l’obiettivo, come viene misurato, cosa è escluso e cosa riceve il cliente se non lo rispetti. Non tutti i servizi hanno bisogno di uno SLA, ma ogni SLA ha bisogno di uno SLO alle spalle, altrimenti non hai alcun preavviso quando stai per violarlo.
Come si combinano SLI, SLO e SLA
Pensali come livelli. Lo SLI è il segnale grezzo. Lo SLO è una soglia interna più severa tracciata su quel segnale. Lo SLA è una soglia esterna più permissiva tracciata sullo stesso segnale. Una configurazione comune per un prodotto SaaS è questa (valori di esempio):
SLI: quota di controlli al minuto su app.lumenanalytics.io che restituiscono lo stato 200 e contengono il titolo della dashboard.
SLO: 99,95% per mese solare.
SLA: 99,9% per mese solare, con un credito di servizio se non viene rispettato.
La differenza tra 99,95% e 99,9% è il margine di sicurezza. Se il team vede lo SLO scivolare nella seconda settimana, ha ancora il tempo di intervenire prima che la promessa contrattuale sia a rischio.
Le percentuali di uptime in minuti
Sulla carta gli obiettivi di uptime sembrano vicini, ma ogni nove in più riduce di dieci volte il downtime consentito. La tabella qui sotto usa un mese medio (un anno di 365,25 giorni diviso per 12), come il calcolatore di uptime; un mese di 30 giorni consente un po’ meno.
Obiettivo di uptimeDowntime consentito al meseDowntime consentito all’anno99%7 h 18 min 18 s3 giorni 15 h 39 min 36 s99,5%3 h 39 min 9 s1 giorno 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99%4 min 22 s52 min 35 s99,999 s5 min 15 s
Ne derivano due conseguenze pratiche. Primo, il tuo monitoraggio deve essere in grado di vedere il downtime che prometti. Con controlli ogni cinque minuti non puoi misurare onestamente un obiettivo mensile del 99,99%, perché una sola interruzione non rilevata potrebbe consumare tutto il budget. Secondo, ogni obiettivo sopra il 99,9% lascia pochissimo spazio a una risposta manuale. Al 99,99%, un solo incidente notturno gestito con lentezza chiude il mese.
Error budget: trasformare lo SLO in decisioni
Un error budget è la quantità di guasti che il tuo SLO consente. Con uno SLO mensile del 99,9%, il budget è lo 0,1% del mese, circa 43 minuti e 49 secondi in un mese medio (43 minuti e 12 secondi in uno di 30 giorni). Ogni incidente ne consuma una parte.
Il budget rende l’affidabilità una decisione condivisa invece che una discussione. Una regola semplice usata da molti team:
Più di metà del budget disponibile: rilascia come sempre.
Meno di metà disponibile: rivedi i deploy rischiosi, aggiungi un secondo paio d’occhi alle modifiche al database.
Budget esaurito: sospendi i rilasci di funzionalità per quel servizio e lavora sulle cause degli ultimi incidenti finché la finestra non si azzera.
Un esempio: harborlabs.dev ha uno SLO mensile del 99,9% per la sua API pubblica. Il giorno 9 un deploy difettoso causa 18 minuti di errori. Il giorno 20 un problema di certificato ne causa altri 9. Sono 27 minuti spesi su 43, con dieci giorni ancora da coprire. Il team rimanda la prossima migrazione dello schema al nuovo mese, perché un altro incidente della stessa entità violerebbe l’obiettivo.
Scegliere gli SLI per un sito web o un’API
Buoni SLI descrivono ciò che vivono gli utenti, non ciò che sentono i tuoi server. Una CPU al 90% non è uno SLI. Un checkout che fallisce lo è. Parti con due o tre indicatori per servizio:
Disponibilità: la quota di controlli o richieste che vanno a buon fine. Per un sito web, “a buon fine” dovrebbe significare il codice di stato giusto e il contenuto giusto, non solo una risposta.
Latenza: la quota di richieste che rispondono più velocemente di una soglia, per esempio il 95% sotto gli 800 ms. Una quota è più facile da interpretare di una media, che nasconde i valori anomali lenti.
Correttezza: per le API, la quota di risposte che contengono i campi attesi. Un 200 con il body vuoto non è un successo.
Misura i percorsi che contano. Per un negozio come northwind.shop significa il checkout e le pagine prodotto, non solo la homepage in cache. Per un’API significa gli endpoint con cui si integrano i clienti, idealmente tramite un endpoint di health check che verifica il database e le altre dipendenze. Un monitor API che valida il body della risposta trasforma quell’endpoint in uno SLI di cui ti puoi fidare.
Cosa conta per l’uptime
La maggior parte delle controversie sugli SLA non riguarda il numero. Riguarda cosa viene conteggiato. Decidi questi punti prima di pubblicare un obiettivo:
Manutenzione pianificata. Molti SLA escludono la manutenzione programmata annunciata in anticipo, per esempio con 72 ore di preavviso e un tetto di quattro ore al mese. Se la escludi, specifica come viene annunciata e fissa un limite, altrimenti la “manutenzione” diventa una scappatoia.
Interruzioni parziali. Il servizio è down se il login funziona ma il checkout no? Definisci i componenti coperti e se l’interruzione di uno conta come downtime per l’intero servizio.
Prestazioni degradate. Decidi se le risposte più lente di una soglia contano come errori. Se una pagina impiega 30 secondi, per gli utenti è down.
Cause fuori dal tuo controllo. Problemi di rete lato cliente, uso improprio e forza maggiore sono comunemente esclusi. Il tuo provider di hosting di solito no: i clienti hanno acquistato il servizio da te.
Durata minima. Alcuni SLA conteggiano solo le interruzioni più lunghe di un minuto o confermate da più di un controllo, in linea con il modo in cui il monitoraggio conferma i guasti.
Internamente è spesso saggio conteggiare la manutenzione pianificata nello SLO anche se lo SLA la esclude. Gli utenti non riuscivano comunque a raggiungere il servizio, e lo SLO deve riflettere la loro esperienza.
Scrivere uno SLA per i clienti
Un buon SLA è breve e preciso. Deve rispondere a sei domande: quale servizio, quale obiettivo, misurato come, su quale periodo, con quali esclusioni e cosa succede se non lo rispetti. Ecco una clausola di esempio che puoi adattare:
Servizio: l’applicazione web Lumen Analytics su app.lumenanalytics.io
e l’API pubblica su api.lumenanalytics.io.
Obiettivo: disponibilità mensile del 99,9%.
Misurazione: la disponibilità è misurata da controlli esterni ogni minuto.
Un minuto è considerato non disponibile quando il servizio restituisce un errore (5xx)
o nessuna risposta, confermata da un secondo controllo.
Esclusioni: manutenzione programmata annunciata con almeno 72 ore di anticipo
sulla nostra pagina di stato (max. 4 ore al mese); problemi causati dalla
rete o dai sistemi del cliente.
Crediti: sotto il 99,9%: 10% del canone mensile.
sotto il 99,0%: 25% del canone mensile.
I clienti richiedono i crediti entro 30 giorni dalla fine del mese.
Imposta lo SLA sotto ciò che ottieni davvero. Se lo storico del monitoraggio mostra il 99,97% nell’ultimo anno, promettere il 99,9% è realistico. Promettere il 99,99% perché suona meglio trasforma ogni incidente in un problema contrattuale.
Mantieni i crediti proporzionati e la procedura di richiesta semplice. Raramente i clienti vogliono i soldi. Vogliono vedere che prendi sul serio la promessa e che misuri in modo onesto.
Misurare con il monitoraggio esterno
I tuoi log non possono misurare un’interruzione in cui il server non ha mai ricevuto la richiesta. Guasti DNS, certificati scaduti, problemi di rete e un load balancer andato in crash lasciano tutti silenziose le metriche interne. Per questo la misurazione dello SLA dovrebbe arrivare dall’esterno, nello stesso modo in cui ti raggiungono i clienti. Se l’argomento è nuovo per te, parti da cos’è il monitoraggio uptime e come funziona.
Una configurazione solida per il reporting degli SLA:
Controlla ogni minuto. L’intervallo determina la risoluzione della tua misurazione.
Conferma ogni guasto con un secondo controllo. Così un singolo intoppo di rete resta fuori dai tuoi numeri di downtime.
Valida il contenuto. Cerca una parola o un campo che compare solo quando il servizio funziona.
Conserva lo storico. Ti servono gli orari di inizio e fine degli incidenti per ogni mese su cui fai report.
Pubblicalo. Una pagina di stato con lo storico dell’uptime permette ai clienti di vedere gli stessi numeri che vedi tu.
Uptimecheck copre tutto questo con il monitoraggio uptime fino a ogni minuto da Stoccolma, Londra e New York, report SLA per monitor per il mese corrente o quello precedente o per gli ultimi 7, 30 o 90 giorni rispetto al tuo obiettivo, esportazione CSV per il rendiconto SLA mensile e report via email settimanali e mensili. Una pagina di stato collegata agli stessi monitor mostra ai clienti lo storico dell’uptime dietro la tua promessa.
L’uptime è solo un lato dell’affidabilità. La velocità con cui rilevi e risolvi gli incidenti decide quanta parte del budget consuma ciascuno; leggi MTTR, MTTA e MTBF spiegati per il lato della risposta.
Checklist: definire SLI, SLO e uno SLA
Elenca i percorsi utente che contano: login, checkout, l’API principale.
Definisci uno SLI di disponibilità e, dove serve, uno SLI di latenza per ogni percorso.
Misura per un mese o due prima di scegliere gli obiettivi.
Imposta lo SLO leggermente sotto ciò che ottieni oggi, e concorda una regola per l’error budget.
Imposta lo SLA sotto lo SLO, con esclusioni chiare e crediti proporzionati.
Misura dall’esterno ogni minuto e rivedi i numeri ogni mese.
Misura l’uptime che prometti dal punto di vista dei tuoi clienti. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.