Panoramica

Questa sezione esamina il concetto di indicatori del livello del servizio (SLI), definisce cosa rende uno SLI valido o utile e fornisce esempi di implementazioni degli SLI per i servizi selezionati. Questa pagina è rivolta alle persone che vogliono esempi che implementino SLI specifici per i servizi.

Introduzione agli SLI

L'affidabilità di un servizio è un concetto astratto; ciò che significa affidabilità dipende dal servizio e dalle esigenze dei suoi utenti. Un indicatore di livello del servizio (SLI) è una misura di questa affidabilità da utilizzare sia per comunicare l'affidabilità del servizio sia per gestirlo.

Gli SLI vengono misurati in un intervallo di tempo. La dimensione della finestra dipende in genere dalla decisione che prende l'informazione. Ad esempio, puoi misurare un singolo SLI nei seguenti modi:

  • Nell'ora più recente, per creare criteri di avviso.
  • Nel giro di settimane, per prendere decisioni tattiche.
  • Nel corso dei mesi, per prendere decisioni strategiche.

Consigliamo 28 giorni come punto di partenza per misurare il tuo SLI; questo valore fornisce un buon equilibrio tra i casi d'uso strategici e tattici.

Per ulteriori informazioni, consulta le seguenti sezioni del foglio di lavoro per la progettazione dell'affidabilità dei siti:

Proprietà di un buon SLI

Per SLI "buoni" si intendono le misure che soddisfano i seguenti criteri:

  • Gli SLI sono buone misure proxy per la soddisfazione degli utenti.

    Un buon SLI è strettamente correlato alla soddisfazione degli utenti. Puoi utilizzare lo SLI come base per un obiettivo del livello di servizio (SLO), una soglia impostata sullo SLI. Puoi impostare lo SLO in modo che, quando lo SLI rientra in un intervallo definito, la maggior parte degli utenti è soddisfatta. Affinché questa relazione possa essere mantenuta, lo SLI deve essere un buon indicatore della soddisfazione degli utenti.

    Se lo SLI è un buon indicatore della soddisfazione degli utenti, quando c'è un evento che influisce sulla soddisfazione dell'utente, lo SLI cambia in una certa direzione. Allo stesso modo, quando non ci sono eventi che incidono sulla soddisfazione degli utenti, lo SLI non cambia.

  • Gli SLI scalano in modo monotonico e lineare per soddisfare le aspettative degli utenti.

    Un buon SLI scala in modo monotonico e lineare, con soddisfazione degli utenti. Se lo SLI migliora, la soddisfazione degli utenti migliora. Analogamente, se lo SLI diminuisce, la soddisfazione degli utenti diminuisce. Il miglioramento del valore di un buon SLI corrisponde al livello di miglioramento della soddisfazione degli utenti.

  • Gli SLI producono misurazioni che vanno da 0% a 100%.

    Un buon SLI produce una misurazione delle prestazioni che va dallo 0% al 100%: questo intervallo è intuitivo e facile da utilizzare. Ad esempio, prestazioni SLI al 100% significa che tutto funziona correttamente, mentre prestazioni SLI allo 0% significa che non funziona nulla.

    Avere uno SLI che va da 0% a 100% rende l'impostazione di uno SLO sullo SLI facile e chiara: assegna un target percentuale come il 99,9% e le prestazioni dello SLI devono essere pari o superiori a questo obiettivo affinché il servizio soddisfi il suo SLO.

Promesse

Un modo per implementare uno SLI con queste proprietà è pensare allo SLI in termini di promesse fatte agli utenti. Contando le promesse che hai fatto e mantenuto in un determinato periodo di tempo, puoi ricavare un numero che va da 0% a 100%. Inoltre, questi SLI si traducono bene in budget di errore: per un determinato SLO, il budget di errore è il numero di promesse che puoi non rispettare in una finestra temporale pur rispettando il tuo SLO.

Ecco alcuni esempi di promesse:

  • Restituire una risposta con un codice di stato HTTP 200 alla richiesta di un cliente.
  • Per rispondere a una richiesta gRPC in meno di 100 ms.
  • Per completare correttamente il flusso di lavoro "Crea macchina virtuale".
  • Per elaborare i dati aggiornati negli ultimi 10 minuti.
  • Per avviare l'esecuzione del job batch pianificato entro un minuto dall'ora di inizio.

Specifiche e implementazioni SLI

Una specifica dello SLI è cosa vuoi misurare. La specifica non include i dettagli tecnici esatti sul modo in cui verrà misurata. Ad esempio, di seguito è riportata una specifica di uno SLI per il tempo di caricamento della pagina:

  • La percentuale di richieste della home page che vengono caricate in meno di 100 ms.

Ci sono molti modi per misurare uno SLI, ciascuno con compromessi e vantaggi. I modi per misurare lo SLI sono le implementazioni di SLI. Ad esempio, potresti implementare la specifica per il caricamento della pagina come segue:

  • Il campo della latenza del log delle richieste del server delle applicazioni.
  • Metriche esportate dal server delle applicazioni.
  • Metriche esportate da un bilanciatore del carico davanti ai server delle applicazioni.
  • Un servizio di monitoraggio black-box che invia richieste artificiali al sistema e calcola il tempo necessario per ricevere risposte valide.
  • Codice specifico per l'applicazione eseguito nel browser del cliente che registra le informazioni sulle tempistiche e le invia a un servizio di raccolta.

Ognuna di queste scelte comporta dei compromessi tra le seguenti caratteristiche:

  • Fedeltà: la precisione con cui acquisisce l'esperienza utente.
  • Copertura: la proporzione di interazioni utente misurate.
  • Costo: la quantità di denaro e tempo di progettazione necessari per creare e gestire la soluzione.

La fedeltà all'esperienza utente di solito migliora quando lo SLI viene misurato più vicino all'utente. Ad esempio, l'implementazione che utilizza codice nel browser dell'utente determina una misurazione della latenza più accurata di quella percepita dall'utente o da altre scelte di misurazione.

Il compromesso è che la misurazione basata su browser include anche l'eventuale latenza introdotta dalla connessione dell'utente al servizio. Ad esempio, quando un servizio viene utilizzato sulla rete internet pubblica, questa latenza può variare in modo significativo in base alla posizione geografica o alle condizioni della rete.

Il risultato è che l'indicatore basato sul browser è un buon indicatore della soddisfazione degli utenti. Tuttavia, questo indicatore potrebbe non fornire informazioni strategiche che puoi utilizzare per migliorare l'affidabilità del tuo servizio.

Per informazioni sulla combinazione di più misurazioni per bilanciare questo compromesso, consulta questo post di The Telegraph.

Bucket

Potresti aver bisogno di più SLI per un servizio quando quest'ultimo esegue tipi di lavoro diversi per utenti diversi o quando esegue una determinata attività con risultati possibili diversi.

Attività diverse

I servizi che eseguono più tipi di lavoro, per diverse categorie di utenti, e in cui ogni tipo di lavoro influenza la soddisfazione degli utenti, traggono vantaggio da più SLI in modo diverso.

Ad esempio, se il tuo servizio gestisce sia le richieste di lettura che di scrittura, gli utenti che eseguono queste attività potrebbero avere requisiti diversi:

  • Le richieste di lettura devono essere veloci.
  • Le richieste di scrittura devono avere esito positivo.

Per soddisfare questi diversi requisiti, il tuo SLI deve essere in grado di distinguere tra i due casi. In genere, la metrica SLI ha un'etichetta che puoi usare per classificare i valori in uno dei vari bucket.

Un'unica attività con risultati diversi

Servizi che eseguono un singolo tipo di lavoro, ma in cui le aspettative degli utenti differiscono in base alla risposta traggono vantaggio da più SLI.

Ad esempio, se il tuo servizio offre accesso di sola lettura ai dati, gli utenti potrebbero avere una tolleranza diversa per la latenza a seconda del risultato della richiesta:

  • Gli utenti potrebbero tollerare gli errori che vengono restituiti rapidamente, perché possono ritentare subito la richiesta.
  • Gli utenti potrebbero essere meno tolleranti nei confronti delle richieste andate a buon fine che richiedono molto tempo.
  • Gli utenti tollerano meno lo scenario peggiore, ovvero le richieste che richiedono molto tempo per restituire un errore.

In questo caso, lo SLI di latenza deve essere in grado di distinguere tra richieste andate a buon fine e non riuscite.

Passaggi successivi

Per informazioni sull'implementazione degli SLI per i servizi Google Cloud utilizzando le metriche di Google Cloud, vedi quanto segue:

Per informazioni sull'implementazione di SLI specifici per l'applicazione, vedi quanto segue:

Per un esempio che illustra come creare uno SLI per i servizi che segnalano metriche personalizzate, consulta Impostare gli SLO: osservabilità utilizzando metriche personalizzate.