Panoramica

Questa sezione esamina il concetto di indicatori del livello del servizio (SLI), definisce che cosa rende un SLI buono o utile e fornisce esempi di implementazioni di SLI per servizi selezionati. Questa pagina è rivolta a chi vuole esempi che implementano SLI specifici per i servizi.

Introduzione agli SLI

L'affidabilità di un servizio è una nozione astratta; il significato di affidabilità dipende dal servizio e dalle esigenze dei suoi utenti. Un indicatore del 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 determinato periodo di tempo. Le dimensioni della finestra dipendono in genere dalla decisione per la quale vengono utilizzate le informazioni. Ad esempio, potresti misurare un singolo SLI nei seguenti modi:

  • Nell'ora più recente, per la creazione di criteri di avviso.
  • Nell'arco di settimane, per prendere decisioni tattiche.
  • Per mesi, per prendere decisioni strategiche.

Ti consigliamo di utilizzare 28 giorni come punto di partenza per la misurazione dell'SLI. Questo valore offre un buon equilibrio tra i casi d'uso strategici e tattici.

Per saperne di più, consulta le seguenti sezioni del Site Reliability Workbook:

Proprietà di un buon SLI

Consideriamo "buoni" gli SLI che soddisfano i seguenti criteri:

  • Gli SLI sono buone misure indirette della soddisfazione degli utenti.

    Un buon SLI è strettamente correlato alla soddisfazione dell'utente. L'SLI viene utilizzato come base per un obiettivo del livello di servizio (SLO), una soglia impostata sull'SLI. Imposti lo SLO in modo che, quando lo SLI rientra in un intervallo definito, la maggior parte degli utenti sia soddisfatta. Affinché questa relazione sia valida, lo SLI deve essere un buon indicatore della soddisfazione degli utenti.

    Se lo SLI è un buon sostituto della soddisfazione utente, quando si verifica un evento che influisce sulla soddisfazione utente, lo SLI cambia in una determinata direzione. Analogamente, quando non sono presenti eventi che influiscono sulla soddisfazione degli utenti, il valore dell'SLI non subisce variazioni.

  • Gli SLI variano in modo monotono e lineare in base alla soddisfazione dell'utente.

    Un buon SLI si basa su una scala monotona e lineare con la soddisfazione degli utenti. Se l'SLI migliora, aumenta la soddisfazione degli utenti. Analogamente, se lo SLI diminuisce, la soddisfazione dell'utente diminuisce. L'entità del miglioramento del valore di un buon SLI corrisponde all'entità del miglioramento della soddisfazione degli utenti.

  • Gli SLI producono misurazioni che vanno dal 0% al 100%.

    Un buon SLI produce una misurazione del rendimento compresa tra 0% e 100%: questo intervallo è intuitivo e facile da utilizzare. Ad esempio, un rendimento SLI del 100% indica che tutto funziona e un rendimento SLI dello 0% significa che non funziona nulla.

    Avere un SLI compreso tra 0% e 100% semplifica e chiarisce l'impostazione di uno SLO sull'SLI: assegna una percentuale target, ad esempio il 99,9%, e le prestazioni dell'SLI devono essere uguali o superiori a questo target affinché il servizio soddisfi il proprio 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 compreso tra 0% e 100%. Questi SLI si traducono bene anche in budget di errore: per un determinato SLO, il budget di errore è il numero di promesse che puoi non mantenere in un determinato intervallo di tempo pur rispettando lo SLO.

Ecco alcuni esempi di promesse:

  • Per 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 pubblicare 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 degli SLI

Una specifica SLI è ciò che vuoi misurare. La specifica non include i dettagli tecnici esatti su come misurarla. Ad esempio, la seguente è una specifica di un SLI per il tempo di caricamento della pagina:

  • La percentuale di richieste della home page che si caricano in meno di 100 ms.

Esistono molti modi per misurare un SLI, ognuno con compromessi e vantaggi. I modi per misurare lo SLI sono le implementazioni dello SLI. Ad esempio, potresti implementare la specifica di caricamento della pagina come una delle seguenti:

  • Il campo di latenza del log delle richieste del server di applicazioni.
  • Metriche esportate dal server dell'applicazione.
  • 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 misura il tempo necessario per ricevere risposte valide.
  • Codice specifico dell'applicazione eseguito nel browser del cliente che registra le informazioni sui tempi 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: l'importo in termini di denaro e tempo di ingegneria necessario per sviluppare e mantenere la soluzione.

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

Il compromesso è che la misurazione basata sul browser include anche eventuali latenze introdotte dalla connessione dell'utente al tuo servizio. Ad esempio, quando un servizio viene utilizzato su internet pubblico, questa latenza può variare notevolmente in base alla posizione geografica o alle condizioni della rete.

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

Per informazioni su come combinare più misurazioni per bilanciare questo compromesso, consulta questo post del The Telegraph.

Bucketing

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

Attività diverse

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

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

  • Le richieste di lettura devono essere rapide.
  • Le richieste di scrittura devono essere andate a buon fine.

Per acquisire questi diversi requisiti, l'SLI deve essere in grado di distinguere tra questi due casi. In genere, la metrica SLI ha un'etichetta che puoi utilizzare per classificare i valori in uno di diversi bucket.

Un'attività con risultati diversi

I servizi che eseguono un singolo tipo di lavoro, ma in cui le aspettative degli utenti differiscono in base alla risposta, beneficiano di più SLI.

Ad esempio, se il tuo servizio offre solo accesso in lettura ai dati, gli utenti potrebbero avere una tolleranza diversa per la latenza a seconda dell'esito della richiesta:

  • Gli utenti potrebbero tollerare gli errori restituiti rapidamente, perché possono quindi ritentare immediatamente la richiesta.
  • Gli utenti potrebbero essere meno tolleranti nei confronti di richieste riuscite che richiedono molto tempo.
  • Gli utenti sono meno tolleranti dello scenario peggiore: richieste che richiedono molto tempo per restituire un errore.

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

Passaggi successivi

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

Per informazioni sull'implementazione degli SLI specifici per l'applicazione, consulta quanto segue:

Per un esempio che illustra come creare un SLI per i servizi che generano report su metriche personalizzate, consulta Impostazione degli SLO: osservabilità mediante metriche personalizzate.