SRE (Site Reliability Engineering) è un approccio per rendere accessibili i progetti web. È considerato un framework per DevOps e spiega come avere successo nell'applicazione delle pratiche DevOps. Questo articolo traduce Capitolo 4 Obiettivi del livello di servizio libri Ingegneria dell'affidabilità del sito da Google. Ho preparato personalmente questa traduzione e ho fatto affidamento sulla mia esperienza nella comprensione dei processi di monitoraggio. Nel canale Telegram monitorim_it и ultimo post su Habré Ho anche pubblicato una traduzione del capitolo 6 dello stesso libro sugli obiettivi del livello di servizio.

Traduzione per gatto. Buona lettura!

È impossibile gestire un servizio se non si comprende quali indicatori contano effettivamente e come misurarli e valutarli. A tal fine, definiamo e forniamo un certo livello di servizio ai nostri utenti, indipendentemente dal fatto che utilizzino una delle nostre API interne o un prodotto pubblico.

Usiamo la nostra intuizione, esperienza e comprensione del desiderio degli utenti di comprendere gli indicatori del livello di servizio (SLI), gli obiettivi del livello di servizio (SLO) e gli accordi sul livello di servizio (SLA). Queste dimensioni descrivono le principali metriche che vogliamo monitorare e alle quali reagiremo se non riusciamo a fornire la qualità del servizio prevista. In definitiva, la scelta delle metriche giuste aiuta a indirizzare le azioni giuste se qualcosa va storto e dà inoltre fiducia al team SRE nello stato di salute del servizio.

Questo capitolo descrive l'approccio che utilizziamo per combattere i problemi di modellazione metrica, selezione metrica e analisi metrica. La maggior parte della spiegazione sarà priva di esempi, quindi utilizzeremo il servizio Shakespeare descritto nel suo esempio di implementazione (ricerca delle opere di Shakespeare) per illustrare i punti principali.

Terminologia del livello di servizio

Molti lettori probabilmente hanno familiarità con il concetto di SLA, ma i termini SLI e SLO meritano un'attenta definizione perché in generale il termine SLA è sovraccarico e ha numerosi significati a seconda del contesto. Per chiarezza, vogliamo separare questi valori.

Indicatori

Lo SLI è un indicatore del livello di servizio, una misura quantitativa attentamente definita di un aspetto del livello di servizio fornito.

Per la maggior parte dei servizi, la chiave SLI è considerata la latenza della richiesta, ovvero il tempo necessario per restituire una risposta a una richiesta. Altri SLI comuni includono il tasso di errore, spesso espresso come una frazione di tutte le richieste ricevute, e il throughput del sistema, solitamente misurato in richieste al secondo. Le misurazioni sono spesso aggregate: i dati grezzi vengono prima raccolti e poi convertiti in un tasso di variazione, media o percentile.

Idealmente, lo SLI misura direttamente il livello di servizio di interesse, ma a volte è disponibile per la misurazione solo una metrica correlata poiché quella originale è difficile da ottenere o interpretare. Ad esempio, la latenza lato client è spesso una metrica più appropriata, ma a volte la latenza può essere misurata solo sul server.

Un altro tipo di SLI importante per gli SRE è la disponibilità, ovvero la porzione di tempo durante il quale è possibile utilizzare un servizio. Spesso definito come il tasso di richieste riuscite, a volte chiamato rendimento. (Anche la durata, ovvero la probabilità che i dati vengano conservati per un periodo di tempo prolungato, è importante per i sistemi di archiviazione dei dati.) Sebbene una disponibilità del 100% non sia possibile, è spesso possibile ottenere una disponibilità vicina al 100%; i valori di disponibilità sono espressi come il numero di "nove" » percentuale di disponibilità. Ad esempio, la disponibilità del 99% e del 99,999% potrebbe essere etichettata come "2 nove" e "5 nove". L'attuale obiettivo di disponibilità dichiarato di Google Compute Engine è "tre nove e mezzo" o 99,95%.

Obiettivi

Uno SLO è un obiettivo del livello di servizio: un valore target o un intervallo di valori per un livello di servizio misurato dallo SLI. Un valore normale per lo SLO è “SLI ≤ Target” o “Limite inferiore ≤ SLI ≤ Limite superiore”. Ad esempio, potremmo decidere di restituire i risultati della ricerca Shakespeare “rapidamente” impostando lo SLO su una latenza media delle query di ricerca inferiore a 100 millisecondi.

Scegliere lo SLO giusto è un processo complesso. Innanzitutto, non puoi sempre scegliere un valore specifico. Per le richieste HTTP esterne in entrata al tuo servizio, la metrica Query Per Second (QPS) è determinata principalmente dal desiderio degli utenti di visitare il tuo servizio e non puoi impostare uno SLO per questo.

D'altra parte, puoi dire che vuoi che la latenza media per ogni richiesta sia inferiore a 100 millisecondi. Stabilire un obiettivo del genere potrebbe costringerti a scrivere il tuo frontend con bassa latenza o ad acquistare apparecchiature che forniscono tale latenza. (100 millisecondi è ovviamente un numero arbitrario, ma è meglio avere numeri di latenza ancora più bassi. Ci sono prove che suggeriscono che velocità elevate sono migliori di velocità lente, e che la latenza nell'elaborazione delle richieste degli utenti al di sopra di determinati valori costringe di fatto le persone a stare lontane dal tuo servizio.)

Ancora una volta, questo è più ambiguo di quanto possa sembrare a prima vista: non dovresti escludere completamente il QPS dal calcolo. Il fatto è che QPS e latenza sono fortemente correlati tra loro: un QPS più elevato spesso porta a latenze più elevate e i servizi di solito subiscono un forte calo delle prestazioni quando raggiungono una determinata soglia di carico.

La selezione e la pubblicazione di uno SLO determinano le aspettative dell'utente su come funzionerà il servizio. Questa strategia può ridurre i reclami infondati contro il proprietario del servizio, come il rallentamento delle prestazioni. Senza uno SLO esplicito, gli utenti spesso creano le proprie aspettative sulle prestazioni desiderate, che potrebbero non avere nulla a che fare con le opinioni delle persone che progettano e gestiscono il servizio. Questa situazione può portare ad aspettative eccessive nei confronti del servizio, quando gli utenti credono erroneamente che il servizio sarà più accessibile di quanto non sia in realtà, e causare sfiducia quando gli utenti credono che il sistema sia meno affidabile di quanto non sia in realtà.

accordo

Un accordo sul livello di servizio è un contratto esplicito o implicito con i tuoi utenti che include le conseguenze del rispetto (o del mancato rispetto) degli SLO in essi contenuti. Le conseguenze sono più facilmente riconoscibili quando sono di natura finanziaria – uno sconto o una multa – ma possono assumere altre forme. Un modo semplice per parlare della differenza tra SLO e SLA è chiedere "cosa succede se gli SLO non vengono rispettati?" Se non ci sono conseguenze chiare, quasi sicuramente stai guardando uno SLO.

L'SRE in genere non è coinvolto nella creazione degli SLA perché gli SLA sono strettamente legati alle decisioni aziendali e sui prodotti. La SRE, tuttavia, è coinvolta nel contribuire a mitigare le conseguenze degli SLO falliti. Possono anche aiutare a determinare lo SLI: ovviamente, deve esserci un modo oggettivo per misurare lo SLO nell'accordo, altrimenti ci sarà disaccordo.

Ricerca Google è un esempio di un servizio importante che non ha uno SLA pubblico: vogliamo che tutti utilizzino la Ricerca nel modo più efficiente possibile, ma non abbiamo firmato un contratto con il mondo. Tuttavia, ci sono ancora delle conseguenze se la ricerca non è disponibile: l'indisponibilità comporta un calo della nostra reputazione e una riduzione delle entrate pubblicitarie. Molti altri servizi Google, come Google for Work, prevedono accordi espliciti sul livello del servizio con gli utenti. Indipendentemente dal fatto che un particolare servizio disponga di uno SLA, è importante definire SLI e SLO e utilizzarli per gestire il servizio.

Tanta teoria, ora l'esperienza.

Indicatori in pratica

Dato che abbiamo concluso che è importante selezionare parametri appropriati per misurare il livello di servizio, come fai ora a sapere quali parametri sono importanti per un servizio o un sistema?

Cosa interessa a te e ai tuoi utenti?

Non è necessario utilizzare ogni metrica come SLI che è possibile monitorare in un sistema di monitoraggio; Capire cosa desiderano gli utenti da un sistema ti aiuterà a selezionare diverse metriche. La scelta di troppi indicatori rende difficile concentrarsi su indicatori importanti, mentre la scelta di un numero piccolo può lasciare incustodite grandi parti del sistema. Solitamente utilizziamo diversi indicatori chiave per valutare e comprendere lo stato di salute di un sistema.

I servizi possono generalmente essere suddivisi in più parti in termini di SLI che sono rilevanti per loro:

• Sistemi front-end personalizzati, come le interfacce di ricerca per il servizio Shakespeare del nostro esempio. Devono essere disponibili, non avere ritardi e avere una larghezza di banda sufficiente. Di conseguenza si possono porre domande: possiamo rispondere alla richiesta? Quanto tempo ci è voluto per rispondere alla richiesta? Quante richieste possono essere elaborate?
• Sistemi di stoccaggio. Apprezzano la bassa latenza di risposta, la disponibilità e la durabilità. Domande correlate: quanto tempo è necessario per leggere o scrivere i dati? Possiamo accedere ai dati su richiesta? I dati sono disponibili quando ne abbiamo bisogno? Vedere il capitolo 26 Integrità dei dati: ciò che leggi è ciò che scrivi per una discussione dettagliata di questi problemi.
• I sistemi di big data come le pipeline di elaborazione dei dati si basano sulla velocità effettiva e sulla latenza di elaborazione delle query. Domande correlate: Quanti dati vengono elaborati? Quanto tempo impiegano i dati a viaggiare dalla ricezione di una richiesta all'emissione di una risposta? (Alcune parti del sistema potrebbero anche presentare ritardi in determinate fasi.)

Raccolta di indicatori

Molti indicatori del livello di servizio vengono raccolti in modo più naturale sul lato server, utilizzando un sistema di monitoraggio come Borgmon (vedi sotto). Capitolo 10 Avvisi pratici basati su dati di serie temporali) o Prometheus, o semplicemente analizzando periodicamente i log, identificando le risposte HTTP con stato 500. Tuttavia, alcuni sistemi dovrebbero essere dotati di raccolta di metriche lato client, poiché la mancanza di monitoraggio lato client può portare a ignorare una serie di problemi che riguardano utenti, ma non influiscono sulle metriche lato server. Ad esempio, concentrarsi sulla latenza della risposta del backend della nostra applicazione di test di ricerca Shakespeare può comportare una latenza sul lato utente a causa di problemi JavaScript: in questo caso, misurare il tempo impiegato dal browser per elaborare la pagina è una metrica migliore.

Aggregazione

Per semplicità e facilità d'uso, spesso aggreghiamo misurazioni grezze. Questo deve essere fatto con attenzione.

Alcuni parametri sembrano semplici, come le richieste al secondo, ma anche questa misurazione apparentemente semplice aggrega implicitamente i dati nel tempo. La misurazione viene ricevuta specificatamente una volta al secondo o viene calcolata la media del numero di richieste al minuto? Quest'ultima opzione può nascondere un numero istantaneo molto più elevato di richieste che durano solo pochi secondi. Considera un sistema che serve 200 richieste al secondo con numeri pari e 0 per il resto del tempo. Una costante sotto forma di valore medio di 100 richieste al secondo e il doppio del carico istantaneo non sono la stessa cosa. Allo stesso modo, la media delle latenze delle query può sembrare interessante, ma nasconde un dettaglio importante: è possibile che la maggior parte delle query sia veloce, ma ce ne saranno molte lente.

È meglio considerare la maggior parte degli indicatori come distribuzioni piuttosto che come medie. Ad esempio, per la latenza SLI, alcune richieste verranno elaborate rapidamente, mentre altre richiederanno sempre più tempo, a volte molto più tempo. Una semplice media può nascondere questi lunghi ritardi. La figura mostra un esempio: sebbene una tipica richiesta richieda circa 50 ms per essere servita, il 5% delle richieste è 20 volte più lento! Il monitoraggio e gli avvisi basati solo sulla latenza media non mostrano cambiamenti di comportamento nell'arco della giornata, quando in realtà si notano cambiamenti evidenti nel tempo di elaborazione di alcune richieste (riga più in alto).

Latenza di sistema 50, 85, 95 e 99 percentile. L'asse Y è in formato logaritmico.

L'utilizzo dei percentili per gli indicatori consente di vedere la forma della distribuzione e le sue caratteristiche: un livello percentile elevato, come 99 o 99,9, mostra il valore peggiore, mentre il 50 percentile (noto anche come mediana) mostra lo stato più frequente di la metrica. Maggiore è la dispersione dei tempi di risposta, maggiore sarà l'impatto delle richieste a lunga esecuzione sull'esperienza dell'utente. L'effetto è potenziato sotto carico elevato e in presenza di code. La ricerca sull'esperienza utente ha dimostrato che le persone generalmente preferiscono un sistema più lento con un'elevata varianza dei tempi di risposta, quindi alcuni team SRE si concentrano solo su punteggi percentili elevati, sulla base del fatto che se il comportamento di una metrica al percentile 99,9 è buono, la maggior parte degli utenti non incontrerà problemi .

Nota sugli errori statistici

Generalmente preferiamo lavorare con i percentili piuttosto che con la media (media aritmetica) di un insieme di valori. Questo ci permette di considerare valori più dispersi, che spesso hanno caratteristiche significativamente diverse (e più interessanti) rispetto alla media. A causa della natura artificiale dei sistemi informatici, i valori metrici sono spesso distorti, ad esempio nessuna richiesta può ricevere una risposta in meno di 0 ms e un timeout di 1000 ms significa che non possono esserci risposte riuscite con valori maggiori rispetto al timeout. Di conseguenza, non possiamo accettare che la media e la mediana possano essere uguali o vicine tra loro!

Senza test preliminari e a meno che non siano valide alcune ipotesi e approssimazioni standard, stiamo attenti a non concludere che i nostri dati siano distribuiti normalmente. Se la distribuzione non è quella prevista, il processo di automazione che risolve il problema (ad esempio, quando rileva valori anomali, riavvia il server con latenze di elaborazione delle richieste elevate) potrebbe farlo troppo spesso o non abbastanza spesso (entrambi i quali non sono Molto bene).

Standardizzare gli indicatori

Raccomandiamo di standardizzare le caratteristiche generali di SLI in modo da non dover speculare ogni volta su di esse. Qualsiasi caratteristica che soddisfi i modelli standard può essere esclusa dalle specifiche di un singolo SLI, ad esempio:

• Intervalli di aggregazione: “media su 1 minuto”
• Aree di aggregazione: “Tutte le attività nel cluster”
• Frequenza con cui vengono effettuate le misurazioni: “Ogni 10 secondi”
• Quali richieste sono abilitate: "HTTP GET dai lavori di monitoraggio della scatola nera"
• Come vengono ottenuti i dati: "Grazie al nostro monitoraggio misurato sul server"
• Latenza di accesso ai dati: "Tempo all'ultimo byte"

Per risparmiare fatica, crea una serie di modelli SLI riutilizzabili per ogni metrica comune; inoltre rendono più semplice per tutti capire cosa significa un certo SLI.

Obiettivi in ​​pratica

Inizia pensando (o scoprendo!) cosa interessa ai tuoi utenti, non cosa puoi misurare. Spesso ciò che interessa ai tuoi utenti è difficile o impossibile da misurare, quindi finisci per avvicinarti alle loro esigenze. Tuttavia, se inizi solo con ciò che è facile da misurare, ti ritroverai con SLO meno utili. Di conseguenza, a volte abbiamo scoperto che identificare inizialmente gli obiettivi desiderati e poi lavorare con indicatori specifici funziona meglio che scegliere gli indicatori e quindi raggiungere gli obiettivi.

Definire gli obiettivi

Per la massima chiarezza, è opportuno definire come vengono misurati gli SLO e le condizioni alle quali sono validi. Ad esempio, potremmo dire quanto segue (la seconda riga è uguale alla prima, ma utilizza le impostazioni predefinite SLI):

• Il 99% (in media su 1 minuto) delle chiamate Get RPC verrà completato in meno di 100 ms (misurato su tutti i server backend).
• Il 99% delle chiamate Get RPC verrà completato in meno di 100 ms.

Se la forma delle curve delle prestazioni è importante, puoi specificare più SLO:

• Il 90% delle chiamate Get RPC sono state completate in meno di 1 ms.
• Il 99% delle chiamate Get RPC sono state completate in meno di 10 ms.
• Il 99.9% delle chiamate Get RPC sono state completate in meno di 100 ms.

Se i tuoi utenti generano carichi di lavoro eterogenei: elaborazione di massa (per la quale è importante il throughput) ed elaborazione interattiva (per la quale è importante la latenza), potrebbe essere utile definire obiettivi separati per ciascuna classe di carico:

• Il 95% delle richieste dei clienti richiede throughput. Imposta il conteggio delle chiamate RPC eseguite <1 s.
• Il 99% dei clienti si preoccupa della latenza. Imposta il conteggio delle chiamate RPC con traffico <1 KB ed esecuzione <10 ms.

Non è realistico e indesiderabile insistere affinché gli SLO vengano rispettati il ​​100% delle volte: ciò può ridurre il ritmo di introduzione e implementazione di nuove funzionalità e richiedere soluzioni costose. È invece preferibile consentire un budget di errore, ovvero la percentuale di tempo di inattività del sistema consentita, e monitorare questo valore quotidianamente o settimanalmente. Il senior management potrebbe volere valutazioni mensili o trimestrali. (Il budget di errore è semplicemente uno SLO per il confronto con un altro SLO.)

La percentuale di violazioni dello SLO può essere confrontata con il budget di errore (vedi capitolo 3 e par "Motivazione per i bilanci di errore"), con il valore della differenza utilizzato come input per il processo che decide quando distribuire le nuove versioni.

Selezione dei valori target

La selezione dei valori di pianificazione (SLO) non è un'attività puramente tecnica a causa del prodotto e degli interessi aziendali che devono riflettersi negli SLI, SLO (ed eventualmente SLA) selezionati. Allo stesso modo, potrebbe essere necessario scambiare informazioni su questioni relative al personale, ai tempi di commercializzazione, alla disponibilità delle attrezzature e ai finanziamenti. L’SRE dovrebbe far parte di questa conversazione e aiutare a comprendere i rischi e la fattibilità delle diverse opzioni. Abbiamo formulato alcune domande che potrebbero aiutare a garantire una discussione più produttiva:

Non scegliere un obiettivo in base alle prestazioni attuali.
Sebbene comprendere i punti di forza e i limiti di un sistema sia importante, adattare i parametri senza ragionamento può impedirti di mantenere il sistema: richiederà sforzi eroici per raggiungere obiettivi che non possono essere raggiunti senza una riprogettazione significativa.

Mantienilo semplice
Calcoli SLI complessi possono nascondere cambiamenti nelle prestazioni del sistema e rendere più difficile individuare la causa del problema.

Evita gli assoluti
Anche se è allettante avere un sistema in grado di gestire un carico in crescita indefinita senza aumentare la latenza, questo requisito non è realistico. Un sistema che si avvicina a tali ideali richiederà probabilmente molto tempo per la progettazione e la realizzazione, sarà costoso da gestire e sarà troppo adatto alle aspettative degli utenti che farebbero qualcosa di meno.

Utilizza il minor numero possibile di SLO
Selezionare un numero sufficiente di SLO per garantire una buona copertura degli attributi del sistema. Proteggi gli SLO che scegli: se non riesci mai a vincere una discussione sulle priorità specificando uno SLO specifico, probabilmente non vale la pena considerare quello SLO. Tuttavia, non tutti gli attributi del sistema sono riconducibili agli SLO: è difficile calcolare il livello di soddisfazione dell'utente utilizzando gli SLO.

Non inseguire la perfezione
Puoi sempre perfezionare le definizioni e gli obiettivi degli SLO nel tempo man mano che impari di più sul comportamento del sistema sotto carico. È meglio iniziare con un obiettivo variabile che affinerai nel tempo piuttosto che scegliere un obiettivo troppo rigido che deve essere rilassato quando scopri che è irraggiungibile.

Gli SLO possono e devono essere un fattore chiave nel dare priorità al lavoro degli SRE e degli sviluppatori di prodotti perché riflettono una preoccupazione per gli utenti. Un buon SLO è un utile strumento di applicazione per un team di sviluppo. Ma uno SLO mal progettato può portare a uno spreco di lavoro se il team compie sforzi eroici per ottenere uno SLO eccessivamente aggressivo, o un prodotto scadente se lo SLO è troppo basso. SLO è una leva potente, usala con saggezza.

Controlla le tue misurazioni

SLI e SLO sono elementi chiave utilizzati per gestire i sistemi:

• Monitorare e misurare i sistemi SLI.
• Confronta SLI con SLO e decidi se è necessaria un'azione.
• Se è necessaria un’azione, scopri cosa deve accadere per raggiungere l’obiettivo.
• Completa questa azione.

Ad esempio, se il passaggio 2 mostra che la richiesta sta scadendo e, se non viene eseguita alcuna operazione, interromperà lo SLO in poche ore, il passaggio 3 potrebbe comportare il test dell'ipotesi che i server siano vincolati alla CPU e l'aggiunta di altri server distribuirà il carico. Senza uno SLO, non sapresti se (o quando) agire.

Imposta SLO: verranno impostate le aspettative dell'utente
La pubblicazione di uno SLO definisce le aspettative dell'utente riguardo al comportamento del sistema. Gli utenti (e potenziali utilizzatori) spesso vogliono sapere cosa aspettarsi da un servizio per capire se è idoneo all'utilizzo. Ad esempio, le persone che desiderano utilizzare un sito Web di condivisione di foto potrebbero voler evitare di utilizzare un servizio che promette longevità e basso costo in cambio di una disponibilità leggermente inferiore, anche se lo stesso servizio potrebbe essere ideale per un sistema di gestione dei record di archivio.

Per stabilire aspettative realistiche per i tuoi utenti, utilizza una o entrambe le seguenti tattiche:

• Mantenere un margine di sicurezza. Utilizza uno SLO interno più rigoroso rispetto a quello pubblicizzato per gli utenti. Questo ti darà l’opportunità di reagire ai problemi prima che diventino visibili esternamente. Il buffer SLO consente inoltre di avere un margine di sicurezza durante l'installazione di rilasci che influiscono sulle prestazioni del sistema e garantiscono che il sistema sia facile da manutenere senza dover frustrare gli utenti con tempi di inattività.
• Non superare le aspettative degli utenti. Gli utenti si basano su ciò che offri, non su ciò che dici. Se le prestazioni effettive del tuo servizio sono molto migliori dello SLO dichiarato, gli utenti faranno affidamento sulle prestazioni attuali. È possibile evitare un'eccessiva dipendenza spegnendo intenzionalmente il sistema o limitando le prestazioni in condizioni di carico leggero.

Capire quanto un sistema soddisfa le aspettative aiuta a decidere se investire nell’accelerazione del sistema e nel renderlo più accessibile e resiliente. In alternativa, se un servizio funziona troppo bene, una parte del tempo del personale dovrebbe essere dedicata ad altre priorità, come saldare il debito tecnico, aggiungere nuove funzionalità o introdurre nuovi prodotti.

Gli accordi in pratica

La creazione di uno SLA richiede che i team aziendali e legali definiscano le conseguenze e le sanzioni in caso di violazione dello stesso. Il ruolo dell'SRE è quello di aiutarli a comprendere le probabili sfide nel soddisfare gli SLO contenuti nello SLA. La maggior parte delle raccomandazioni per la creazione degli SLO si applicano anche agli SLA. È saggio essere prudenti in ciò che prometti agli utenti perché più hai, più difficile sarà modificare o rimuovere gli SLA che sembrano irragionevoli o difficili da rispettare.

Grazie per aver letto la traduzione fino alla fine. Iscriviti al mio canale Telegram sul monitoraggio monitorim_it и blog su Medium.

Fonte: habr.com