L’error budget è la quota di inaffidabilità che il tuo SLO consente in un determinato periodo: 100% meno l’obiettivo. Uno SLO del 99,9% su 30 giorni lascia un error budget di 43 minuti e 12 secondi di downtime, ovvero una richiesta fallita ogni mille. Finché resta budget, il team può rilasciare e prendersi dei rischi. Quando si esaurisce, il lavoro sull’affidabilità passa in primo piano finché la finestra non si ristabilisce.
Questa sola regola trasforma un obiettivo di affidabilità in decisioni concrete. In questa guida vediamo come calcolare un error budget, che cosa dovrebbe consumarlo e che cosa no, come capire a che velocità lo stai consumando e come scrivere una policy per quando si esaurisce.
Come calcolare un error budget
Ti servono due cose: uno SLO, l’obiettivo di affidabilità che ti dai, e una finestra, il periodo su cui lo misuri. L’error budget è lo spazio che resta tra l’obiettivo e la perfezione.
Error budget = (100% − SLO) × finestra
Per uno SLO del 99,9% su 30 giorni (43.200 minuti): 0,1% × 43.200 = 43,2 minuti, cioè 43 minuti e 12 secondi. La tabella applica lo stesso calcolo agli obiettivi più comuni, arrotondando per difetto al secondo.
SLOBudget su 30 giorniBudget su 90 giorni99%7h 12m21h 36m99,5%3h 36m10h 48m99,9m 12s2h 9m 36s99,95m 36s1h 4m 48s99,99%4m 19s12m 57s
Il calcolatore di SLA e uptime fa lo stesso per qualsiasi obiettivo e periodo. Usa il mese medio (un anno diviso per 12), quindi per il 99,9% mostra 43 minuti e 49 secondi invece del valore su 30 giorni indicato sopra.
Basato sul tempo o sulle richieste
Un error budget si può contare in due unità, a seconda dello SLI alla base del tuo SLO:
Basato sul tempo: minuti di downtime, misurati con controlli dall’esterno. È semplice, facile da spiegare e rispecchia il modo in cui è scritta la maggior parte degli SLA con i clienti. Uno SLO mensile del 99,9% consente circa 43 minuti.
Basato sulle richieste: la quota di richieste fallite, contata dai log del load balancer o dell’applicazione. Con 2 milioni di richieste al mese e il 99,9%, il budget è di 2.000 richieste fallite. Dà più peso alle ore di punta che a quelle tranquille, il che è più vicino a ciò che percepiscono gli utenti, ma richiede log di cui ti fidi.
Molti team usano entrambi: un budget basato sul tempo, dai controlli esterni, per il servizio nel suo insieme, e budget basati sulle richieste per gli endpoint più importanti, come il checkout o l’API.
Perché avere un error budget
Senza un budget, l’affidabilità è materia di discussione. Il prodotto vuole rilasciare, l’ingegneria vuole rallentare, e vince chi parla per ultimo. Un budget sostituisce la discussione con un numero su cui entrambe le parti si sono accordate in anticipo.
Rende il 100% l’obiettivo sbagliato. Un obiettivo del 100% non lascia alcun budget, quindi ogni deploy diventa un rischio che nessuno può prendersi. Del resto, con il loro Wi-Fi e le loro reti mobili gli utenti non distinguono il 99,99% dal 100%.
Rende il rischio spendibile. Una grande migrazione, una nuova region o un rilascio rischioso si possono pianificare in base al budget rimasto questo mese.
Decide le priorità al posto tuo. Quando il budget è finito, la policy dice che cosa succede dopo, così nessuno deve vincere una riunione per far entrare il lavoro sull’affidabilità nella roadmap.
Che cosa consuma il budget
Tutto ciò che il tuo SLI conta come negativo consuma budget. Decidilo quando scrivi lo SLO, non durante l’incidente.
Interruzioni confermate: il servizio non ha risposto, ha risposto con un errore o ha risposto con il contenuto sbagliato.
Risposte lente, se il tuo SLI stabilisce che una richiesta più lenta di un certo limite conta come fallita. Una pagina che impiega 30 secondi è online, ma non è utilizzabile.
Deploy falliti e rollback, per i minuti in cui gli utenti hanno visto errori.
Interruzioni dei tuoi fornitori. Se il tuo provider di pagamento o il tuo host DNS va giù, i tuoi utenti non riescono comunque a completare l’acquisto. Consuma il tuo budget anche se la soluzione non dipende da te: un buon motivo per monitorare i servizi da cui dipendi.
Manutenzione pianificata, solo se lo prevede lo SLO. Molti team escludono le finestre di manutenzione annunciate, con un tetto mensile.
Che cosa invece non dovrebbe consumarlo: i falsi positivi. Un singolo controllo fallito per un problema momentaneo di rete non è downtime. Conferma un errore con un secondo controllo prima di contarlo, altrimenti il budget si esaurisce per problemi che gli utenti non hanno mai visto.
Burn rate: a che velocità lo stai consumando
Il budget ti dice quanti errori puoi permetterti. Il burn rate ti dice a che velocità lo stai usando. Il workbook SRE di Google lo definisce come la velocità, rispetto allo SLO, con cui il servizio consuma l’error budget (Alerting on SLOs).
Un burn rate di 1 consuma l’intero budget esattamente alla fine della finestra.
Un burn rate di 2 lo consuma in metà della finestra: 15 giorni su un mese di 30.
Un’interruzione totale brucia a 1.000 rispetto a uno SLO del 99,9%, perché ogni minuto di downtime vale mille volte il ritmo consentito. Venti minuti così consumano il 46% di un budget su 30 giorni.
Il punto di partenza consigliato dal workbook per uno SLO del 99,9% prevede di chiamare qualcuno quando il 2% di un budget su 30 giorni si consuma entro un’ora (un burn rate di 14,4) o il 5% entro sei ore (un burn rate di 6), e di aprire un ticket quando il 10% si consuma entro tre giorni (un burn rate di 1). Ogni avviso controlla anche una finestra breve, così smette di scattare poco dopo che il problema è finito.
Per un’interruzione netta, un avviso sul burn rate e un normale avviso “il sito è down” scattano più o meno nello stesso momento. Il burn rate dimostra il suo valore con i guasti parziali: il 3% di richieste che fallisce per ore, senza mai mandare giù il sito, ma consumando in silenzio il budget del mese entro mercoledì.
Scrivi una error budget policy
Un budget senza policy è solo un numero su una dashboard. La policy stabilisce in anticipo che cosa fa il team a ogni livello di consumo. Concordala insieme a prodotto e ingegneria, e mettila per iscritto in un posto dove entrambi possano trovarla. Google pubblica un esempio di error budget policy che vale la pena leggere prima di scrivere la tua.
Una policy semplice da cui partire
Budget disponibile: si rilascia come sempre. Il lavoro rischioso pianificato va avanti.
Metà consumata prima di metà finestra: il responsabile della reperibilità esamina gli incidenti fin qui e ne indica la causa principale.
Budget esaurito: si rilasciano solo bug fix e lavoro sull’affidabilità finché la finestra non si ristabilisce. Le migrazioni rischiose aspettano.
Un singolo incidente ha consumato più di un quinto del budget: riceve un postmortem scritto con almeno un’azione correttiva.
Le eccezioni le decidono persone precise, per esempio il responsabile dell’ingegneria e il responsabile di prodotto insieme, e vengono messe per iscritto.
Le soglie sono esempi, non regole. Scegli quelle che il tuo team rispetterà davvero. Una policy ignorata la prima volta che fa male è peggio di nessuna policy, perché insegna a tutti che lo SLO non conta.
Errori comuni
Impostare lo SLO uguale allo SLA. Così il budget si esaurisce nello stesso momento in cui devi ai clienti dei service credit. Tieni lo SLO più stringente dello SLA, così l’allarme interno suona prima. SLA, SLO e SLI spiega come si combinano i tre.
Una finestra troppo breve. Un budget settimanale si azzera prima che una brutta settimana possa cambiare qualcosa. Trenta giorni, a finestra mobile o per mese di calendario, è la scelta abituale.
Dimenticare come si azzera la finestra. Un mese di calendario riparte da zero il giorno 1, quindi una brutta ultima settimana viene dimenticata in pochi giorni. Una finestra mobile di 30 giorni la ricorda per un mese, il che è più rigoroso e più equo.
Guardare solo il totale. Un’interruzione di 40 minuti e quaranta interruzioni di 1 minuto consumano lo stesso budget, ma le seconde interrompono il lavoro degli utenti ogni giorno. Tieni traccia del numero di incidenti e dell’MTTR accanto al budget.
Misurare solo dall’interno. I log del server non possono registrare le richieste che non sono mai arrivate. Un certificato scaduto o un record DNS rotto consumano budget che solo un controllo esterno vede.
Monitorare un error budget basato sul tempo con Uptimecheck
Uptimecheck ti dà i numeri di cui ha bisogno un budget basato sul tempo. Il monitoraggio uptime esegue controlli anche ogni minuto da Stoccolma, Londra e New York e conferma ogni controllo fallito da una seconda località, così un singolo problema momentaneo non consuma budget. Le finestre di manutenzione e i periodi in pausa non vengono conteggiati nell’uptime.
I report mostrano uptime, downtime e incidenti per ogni monitor per il mese corrente, il mese scorso o gli ultimi 7, 30 o 90 giorni, rispetto a un obiettivo SLA del 99%, 99,5%, 99,9%, 99,95% o 99,99%, con download in CSV. Il budget rimasto è il downtime consentito meno il downtime del report. Leggi come generare report rispetto a un obiettivo SLA.
Gli incidenti conservano le prove e una timeline di ogni controllo, avviso e nota: proprio ciò che serve per un postmortem. Scopri la gestione degli incidenti.
Le finestre di manutenzione tengono il lavoro pianificato fuori dai numeri. Leggi come pianificare le finestre di manutenzione.
Per dare un prezzo al budget che consumi, prova il calcolatore del costo del downtime. Per vedere che cosa consente ogni obiettivo, leggi che cosa significa un uptime del 99,9%.
Scopri quanto budget ti resta prima che finisca il mese. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.