Questo documento nella sezione Framework dell'architettura Google Cloud: affidabilità fornisce dettagli sugli avvisi relativi agli SLO.
Un approccio errato all'introduzione di un nuovo sistema di osservabilità come gli SLO consiste nell'utilizzare il sistema per sostituire completamente un sistema precedente. Dovresti invece vedere gli SLO come un sistema complementare. Ad esempio, anziché eliminare gli avvisi esistenti, ti consigliamo di eseguirli in parallelo con gli avvisi SLO introdotti qui. Questo approccio consente di scoprire quali avvisi legacy sono predittivi degli avvisi SLO, che si attivano in parallelo con quelli SLO e quali non vengono mai attivati.
Un principio della SRE è l'avviso in base ai sintomi, non alle cause. Gli SLO sono, per loro stessa natura, misurazioni dei sintomi. Quando adotti gli avvisi SLO, potresti scoprire che l'avviso di sintomi si attiva insieme ad altri avvisi. Se scopri che i tuoi avvisi precedenti basati sulla causa vengono attivati senza SLO o sintomi, è consigliabile disattivare completamente, trasformarli in avvisi di richiesta di assistenza o registrati per un riferimento futuro.
Per maggiori informazioni, consulta il foglio di lavoro SRE, capitolo 5.
Velocità di burn rate SLO
La frequenza di burnout di uno SLO misura la velocità con cui un'interruzione espone gli utenti agli errori ed esaurisce il budget di errore. Se misuri la burn rate, puoi determinare il tempo prima che un servizio violi il suo SLO. Gli avvisi basati sul burn rate SLO sono un approccio prezioso. Ricorda che lo SLO si basa su una durata, che potrebbe essere piuttosto lunga (settimane o anche mesi). Tuttavia, l'obiettivo è rilevare rapidamente una condizione che genera una violazione dello SLO prima che si verifichi effettivamente.
La tabella seguente mostra il tempo necessario per superare un obiettivo se il 100% delle richieste non riesce nell'intervallo specificato, supponendo che le query al secondo (QPS) siano costanti. Ad esempio, se hai uno SLO del 99,9% misurato nell'arco di 30 giorni, puoi resistere a 43,2 minuti di tempo di inattività completo durante quei 30 giorni. Ad esempio, questi tempi di inattività possono verificarsi contemporaneamente o distribuiti su più incidenti.
| Scopo | 90 giorni | 30 giorni | 7 giorni | 1 giorno |
|---|---|---|---|---|
| 90% | 9 giorni | 3 giorni | 16,8 ore | 2,4 ore |
| 99% | 21,6 ore | 7,2 ore | 1,7 ore | 14,4 minuti |
| 99,9% | 2,2 ore | 43,2 minuti | 10,1 minuti | 1,4 minuti |
| 99,99% | 13 minuti | 4,3 minuti | 1 minuto | 8,6 secondi |
| 99,999% | 1,3 minuti | 25,9 secondi | 6 secondi | 0,9 secondi |
In pratica, non puoi permetterti incidenti di interruzione del 100% se vuoi ottenere percentuali di successo elevate. Tuttavia, molti sistemi distribuiti possono avere un guasto parziale o una riduzione controllata. Anche in questi casi, è comunque importante sapere se un essere umano deve intervenire, anche in questi errori parziali e gli avvisi SLO ti offrono un modo per determinarlo.
Quando attivare l'avviso
Una domanda importante è quando intervenire in base alla burn rate del tuo SLO. Di regola, se esaurisci il budget di errore entro 24 ore, il tempo necessario per contattare qualcuno e risolvere un problema è ora.
Misurare il tasso di insuccesso non è sempre semplice. Una serie di piccoli errori potrebbe sembrare terrificante al momento, ma rivelarsi di breve durata e avere un impatto irrilevante sul tuo SLO. Analogamente, se un sistema rimane leggermente inutilizzato per molto tempo, questi errori possono corrispondere a una violazione dello SLO.
Idealmente, il tuo team reagirà a questi indicatori in modo da farti spendere quasi tutto il budget di errore (ma non superarlo) per un determinato periodo di tempo. Una spesa eccessiva viola il tuo SLO. Se spendi troppo poco, non corri abbastanza rischi o potenzialmente esaurire i membri del tuo team disponibile.
Devi trovare un modo per stabilire quando un sistema è rotto a sufficienza da permettere a un essere umano di intervenire. Le sezioni seguenti illustrano alcuni approcci a questa domanda.
Bruciatura rapida
Un tipo di burnout SLO è l'operazione di burn SLO rapida perché elimina rapidamente il budget di errore e richiede che tu intervenga per evitare una violazione dello SLO.
Supponiamo che il tuo servizio operi normalmente a 1000 query al secondo (QPS) e che tu voglia mantenere una disponibilità del 99% misurata nell'arco di sette giorni alla settimana. Il budget di errore corrisponde a circa 6 milioni di errori consentiti (su circa 600 milioni di richieste). Ad esempio, se mancano 24 ore prima che il budget di errore si esaurisca, il limite è di circa 70 errori al secondo o di 252.000 errori in un'ora. Questi parametri si basano sulla regola generale secondo cui gli incidenti con pagine devono consumare almeno l'1% del budget di errore trimestrale.
Puoi scegliere di rilevare questa percentuale di errori prima che sia trascorsa un'ora. Ad esempio, dopo aver osservato una frequenza di 70 errori al secondo per 15 minuti, potresti decidere di contattare il tecnico di chiamata, come illustrato nel seguente diagramma.
Idealmente, il problema viene risolto prima di spendere un'ora del budget di 24 ore. Se si sceglie di rilevare questa frequenza in un periodo di tempo più breve (ad esempio, un minuto), è probabile che sia troppo soggetta a errori. Se il tempo target per il rilevamento è inferiore a 15 minuti, questo numero può essere modificato.
Ustioni lente
Un altro tipo di burn rate è la slow burn. Supponiamo che tu presenti un bug che riduce il budget di errore settimanale entro il quinto o il sesto giorno o il budget mensile entro la seconda settimana. Qual è la risposta migliore?
In questo caso, potresti introdurre un avviso di scrittura SLO lenta che indica che sei sulla buona strada per esaurire l'intero budget di errore prima della fine della finestra di avviso. Naturalmente, quell'avviso potrebbe restituire molti falsi positivi. Ad esempio, può verificarsi spesso una condizione in cui gli errori si verificano brevemente ma con una frequenza che consuma rapidamente il budget di errore. In questi casi, la condizione è un falso positivo perché dura solo per poco tempo e non minaccia il budget di errore a lungo termine. Ricorda che l'obiettivo non è eliminare tutte le fonti di errore, ma rimanere entro un intervallo accettabile non superare il budget di errore. Vuoi evitare di avvisare un essere umano di intervenire per eventi che non minacciano legittimamente il tuo budget di errore.
Ti consigliamo di avvisare la coda dei ticket (anziché il paging o l'invio di email) per gli eventi a bassa velocità. Questi eventi non sono emergenze, ma richiedono l'attenzione umana prima della scadenza del budget. Questi avvisi non devono essere email per un elenco di team, che diventano rapidamente una seccatura da ignorare. I biglietti devono essere monitorabili, assegnabili e trasferibili. I team dovrebbero sviluppare report per il carico delle richieste, i tassi di chiusura, l'azionabilità e i duplicati. Un numero eccessivo di richieste di assistenza non eseguibili è un ottimo esempio di faticale.
Utilizzare in modo appropriato gli avvisi SLO può richiedere tempo e dipendere dalla cultura e dalle aspettative del tuo team. Ricorda che puoi perfezionare gli avvisi SLO nel tempo. Puoi anche avere più metodi di avviso, con finestre di avviso diverse, a seconda delle tue esigenze.
Avvisi di latenza
Oltre agli avvisi di disponibilità, puoi anche ricevere avvisi di latenza. Con gli SLO di latenza, misuri la percentuale di richieste che non soddisfano un target di latenza. Con questo modello, puoi usare lo stesso modello di avviso che utilizzi per rilevare le ustioni rapide o lente del budget di errore.
Come indicato in precedenza per gli SLO di latenza mediana, metà delle tue richieste può uscire dallo SLO. In altre parole, gli utenti possono subire una latenza scadente per giorni prima di rilevare l'impatto sul budget di errore a lungo termine. I servizi dovrebbero invece definire gli obiettivi di latenza della coda e gli obiettivi di latenza tipica. Suggeriamo di utilizzare il 90° percentile storico per definire i valori tipici e il 99° percentile per la coda. Dopo aver impostato questi target, puoi definire gli SLO in base al numero di richieste che ti aspetti di ricevere in ogni categoria di latenza e a quante sono troppo lente. Questo approccio è lo stesso di budget di errore e deve essere considerato allo stesso modo. Di conseguenza, alla fine potresti ottenere un'istruzione come "Il 90% delle richieste verrà gestito all'interno della latenza tipica e il 99,9% entro gli obiettivi di latenza della coda". Questi target assicurano che la maggior parte degli utenti sperimenta la latenza tipica e ti permettono comunque di tenere traccia di quante richieste sono più lente rispetto ai target di latenza di coda.
Per alcuni servizi potrebbero essere previsti runtime molto variabili. Ad esempio, le aspettative in termini di prestazioni della lettura da un sistema di datastore potrebbero essere notevolmente diverse da quelle della scrittura su un sistema di datastore. Anziché enumerare ogni possibile aspettativa, puoi introdurre i bucket di prestazioni di runtime, come mostrato nelle tabelle seguenti. Questo approccio presuppone che questi tipi di richieste siano identificabili e preclassificati in ciascun bucket. Non aspettarti di classificare le richieste in tempo reale.
| Sito web rivolto agli utenti | |
|---|---|
| Bucket | Runtime massimo previsto |
| Lettura | 1 secondo |
| Scrivi / aggiorna | 3 secondi |
| Sistemi di trattamento dati | |
|---|---|
| Bucket | Runtime massimo previsto |
| Small | 10 secondi |
| Medio | 1 minuto |
| Large | 5 minuti |
| Molto grande | 1 ora |
| Enorme | 8 ore |
Se misuri il sistema così com'è, puoi capire quanto tempo richiede in genere l'esecuzione di queste richieste. Prendiamo come esempio un sistema per elaborare i caricamenti dei video. Se il video è molto lungo, i tempi di elaborazione dovrebbero richiedere più tempo. Possiamo utilizzare la durata del video in secondi per classificare queste operazioni in un bucket, come mostra la tabella seguente. La tabella registra il numero di richieste per bucket e vari percentili della distribuzione del runtime nel corso di una settimana.
| Durata video | Numero di richieste misurato in una settimana | 10% | 90% | 99,95% |
|---|---|---|---|---|
| Small | 0 | - | - | - |
| Medio | 1,9 milioni | 864 millisecondi | 17 secondi | 86 secondi |
| Large | 25 milioni | 1,8 secondi | 52 secondi | 9,6 minuti |
| Molto grande | 4,3 milioni | 2 secondi | 43 secondi | 23,8 minuti |
| Enorme | 81.000 | 36 secondi | 1,2 minuti | 41 minuti |
Da questa analisi puoi ricavare alcuni parametri per gli avvisi:
- fast_typical: al massimo, il 10% delle richieste è più veloce di questo periodo. Se troppe richieste sono più veloci di questo periodo, le destinazioni potrebbero essere errate o qualcosa nel sistema potrebbe essere cambiato.
- slow_typical: almeno il 90% delle richieste è più veloce di questo intervallo di tempo. Questo limite guida lo SLO di latenza principale. Questo parametro indica se la maggior parte delle richieste è abbastanza veloce.
- slow_tail: almeno il 99,95% delle richieste è più veloce di questo periodo. Questo limite garantisce che non ci siano troppe richieste lente.
- deadline: il momento in cui la RPC o l'elaborazione in background di un utente scade e non va a buon fine (un limite in genere è già impostato come hardcoded nel sistema). Queste richieste non saranno effettivamente lente, ma in realtà non andranno a buon fine con un errore e verranno conteggiate ai fini dello SLO di disponibilità.
Una linea guida nella definizione dei bucket è mantenere i valori fast_typical, slow_typical e slow_tail di un bucket entro un ordine di grandezza l'uno dall'altro. Questa linea guida garantisce che il tuo bucket non sia troppo ampio. Ti consigliamo di non cercare di evitare sovrapposizioni o intervalli tra i bucket.
| Bucket | fast_typical | slow_typical | slow_tail | scadenza |
|---|---|---|---|---|
| Small | 100 millisecondi | 1 secondo | 10 secondi | 30 secondi |
| Medio | 600 millisecondi | 6 secondi | 60 secondi (1 minuto) | 300 secondi |
| Large | 3 secondi | 30 secondi | 300 secondi (5 minuti) | 10 minuti |
| Molto grande | 30 secondi | 6 minuti | 60 minuti (1 ora) | 3 ore |
| Enorme | 5 minuti | 50 minuti | 500 minuti (8 ore) | 12 ore |
Questo comporta la creazione di una regola come api.method: SMALL => [1s, 10s].
In questo caso, il sistema di monitoraggio SLO vede una richiesta, determina il proprio bucket (ad esempio analizzando il nome del metodo o l'URI e confrontando il nome con una tabella di ricerca), quindi aggiorna la statistica in base al runtime di quella richiesta. Se l'operazione ha richiesto 700 millisecondi, rientra nel target slow_typical. Se è di 3 secondi, è all'interno di slow_tail. Se è di 22 secondi, è oltre slow_tail, ma non è ancora un errore.
In termini di soddisfazione degli utenti, puoi pensare alla mancanza di latenza di coda come a un'indisponibilità. Ciò significa che la risposta è così lenta da considerare un errore. Per questo motivo, ti consigliamo di utilizzare la stessa percentuale che utilizzi per la disponibilità, ad esempio:
La latenza tipica spetta a te. Alcuni team di Google considerano che il 90% sia un buon obiettivo. Questi dati sono correlati alla tua analisi e alla modalità di scelta delle durate per slow_typical. Ad esempio:
Avvisi suggeriti
Date queste linee guida, la tabella seguente include un insieme di riferimento suggerito di avvisi SLO.
| SLO | Finestra di misurazione | Velocità di combustione | Azione |
|---|---|---|---|
|
Disponibilità, burnout rapida Latenza tipica Latenza coda |
Finestra di 1 ora | Meno di 24 ore per la violazione dello SLO | Chiamare qualcuno |
|
Disponibilità, Slow burn Latenza tipica, bruciatura lenta Latenza coda, bruciatura lenta |
Finestra di 7 giorni | Più di 24 ore per la violazione dello SLO | Crea un ticket |
Gli avvisi SLO sono una competenza il cui sviluppo può richiedere tempo. Le durate in questa sezione sono suggerimenti e puoi modificarle in base alle tue esigenze e al tuo livello di precisione. Collegare gli avvisi alla finestra di misurazione o alla spesa del budget di errore potrebbe essere utile oppure potresti aggiungere un ulteriore livello di avviso tra ustioni rapide e operazioni lente.