Présentation

Cette section passe en revue le concept des indicateurs de niveau de service (SLI, Service level indicators), définit ce qui fait un bon ou utile SLI, et fournit des exemples de mise en œuvre SLI pour certains services. Cette page est destinée aux personnes souhaitant obtenir des exemples mettant en œuvre des SLI spécifiques à un service.

Présentation des SLI

La fiabilité d'un service est une notion abstraite. La fiabilité dépend du service et des besoins de ses utilisateurs. Un indicateur de niveau de service (SLI) est une mesure de cette fiabilité à utiliser pour communiquer sur la fiabilité du service et pour le gérer.

Les SLI sont mesurés sur une période donnée. La taille de cette période dépend généralement de la décision sur laquelle repose les informations utilisées. Par exemple, vous pouvez mesurer un seul SLI de la manière suivante:

Au cours de l'heure la plus récente pour créer des règles d'alerte.
Au cours des semaines, pour prendre des décisions tactiques.
Au fil des mois, pour prendre des décisions stratégiques.

Nous recommandons un délai de 28 jours comme point de départ pour mesurer votre SLI. Cette valeur offre un bon équilibre entre les cas d'utilisation stratégiques et tactiques.

Pour en savoir plus, consultez les sections suivantes du Manuel d'ingénierie en fiabilité des sites :

Propriétés d'un bon SLI

Nous considérons que les SLI constituent une bonne mesure lorsqu'ils répondent aux critères suivants :

Les SLI constituent une bonne mesure représentative pour la satisfaction des utilisateurs.

Un bon SLI est en corrélation avec la satisfaction des utilisateurs. Vous utilisez le SLI comme base pour un objectif de niveau de service (SLO), un seuil défini sur le SLI. Vous définissez le SLO de sorte que, lorsque le SLI se trouve dans une plage définie, la plupart de vos utilisateurs sont satisfaits. Pour que cette relation soit maintenue, le SLI doit être une bonne mesure représentative pour la satisfaction des utilisateurs.

Si le SLI est un bon élément représentatif pour la satisfaction des utilisateurs, alors lorsqu'un événement affecte la satisfaction des utilisateurs, le SLI change dans une certaine direction. De même, lorsqu'aucun événement n'affecte la satisfaction des utilisateurs, le SLI ne change pas.
Les SLI évoluent de façon monotone et linéaire avec la satisfaction des utilisateurs.

Un bon SLI évolue de manière monotone et linéaire, avec une bonne satisfaction des utilisateurs. Si le SLI s'améliore, le niveau de satisfaction des utilisateurs s'améliore. De même, si le SLI diminue, le niveau de satisfaction des utilisateurs diminue. La dimension de l'amélioration de la valeur d'un bon SLI correspond à celle de la satisfaction des utilisateurs.
Les SLI fournissent des mesures comprises entre 0% et 100%.

Un SLI efficace produit une mesure de performance comprise entre 0% et 100%: cette plage est intuitive et facile à utiliser. Par exemple, une performance de SLI de 100% signifie que tout fonctionne correctement, tandis que les performances de SLI de 0% signifie que rien ne fonctionne.

Le fait d'avoir un SLI compris entre 0 % et 100 % facilite la définition d'un SLO sur le SLI de manière simple : attribuez un pourcentage cible tel que 99,9 %, et les performances de SLI doivent être égales ou supérieures à cette valeur pour le service pour respecter son SLO.

Promesses

Pour mettre en œuvre un SLI comportant ces propriétés, vous pouvez par exemple le considérer en fonction des promesses adressées à vos utilisateurs. En comptant les promesses que vous avez faites et tenues sur une période donnée, vous pouvez obtenir un nombre compris entre 0% et 100%. Ces SLI se traduisent également par une marge d'erreur: pour un SLO donné, votre marge d'erreur correspond au nombre de promesses qui peuvent ne pas être tenues pendant une période donnée tout en respectant votre SLO.

Voici quelques exemples de promesses :

Renvoyer une réponse avec un code d'état HTTP 200 à la requête d'un client.
Répondre à une requête gRPC en moins de 100 ms.
Terminer le workflow "Create Virtual Machine" (Créer une machine virtuelle),
Diffuser des données actualisées au cours des 10 dernières minutes.
Démarrer la tâche par lot planifiée dans la minute qui suit son heure de début.

Spécifications et mises en œuvre SLI

Une spécification SLI est l'élément que vous souhaitez mesurer. Elle n'inclut pas les détails techniques exacts de la façon dont vous allez le mesurer. Par exemple, voici une spécification de SLI pour le chargement d'une page:

Il s'agit du pourcentage de requêtes de page d'accueil qui se chargent en moins de 100 ms.

Il existe de nombreuses façons de mesurer un SLI, chacune présentant des compromis et des avantages. Les méthodes permettant de mesurer le SLI sont les mises en œuvre du SLI. Par exemple, vous pouvez mettre en œuvre la spécification de chargement de page avec l'une des options suivantes :

Champ de latence du journal de requêtes du serveur d'application.
Métriques exportées par le serveur d'application.
Métriques exportées par un équilibreur de charge devant les serveurs d'applications.
Un service de surveillance par boîte noire qui envoie des requêtes artificielles au système et calcule le temps jusqu'à réception de réponses valides.
Un code spécifique à l'application exécuté dans le navigateur du client qui enregistre les informations de durée et les renvoie à un service de collecte.

Chacun de ces choix implique des compromis entre les caractéristiques suivantes:

Précision : niveau de précision sur l'évaluation de l'expérience utilisateur
Couverture: quelle proportion d'interactions de l'utilisateur est mesurée.
Coût: le temps d'ingénierie et le coût nécessaire à la création et à la maintenance de la solution

La précision pour l'expérience utilisateur s'améliore généralement lorsque le SLI est mesuré plus près de l'utilisateur. Par exemple, la mise en œuvre qui utilise du code dans le navigateur de l'utilisateur permet d'obtenir une mesure plus précise de la latence observée par l'utilisateur que les autres options de mesures.

Par contre, la mesure basée sur le navigateur inclut également toute latence introduite par la connexion de l'utilisateur à votre service. Par exemple, lorsqu'un service est utilisé sur l'Internet public, cette latence peut varier considérablement selon l'emplacement géographique ou les conditions du réseau.

En conséquence, le signal basé sur le navigateur constitue une bonne représentation de la satisfaction des utilisateurs. Toutefois, ce signal peut ne pas fournir des informations exploitables permettant d'améliorer la fiabilité de votre service.

Pour en savoir plus sur la combinaison de plusieurs mesures afin d'équilibrer ce compromis, consultez cet article du blog The Telegraph.

Binning

Vous aurez peut-être besoin de plusieurs SLI pour un service lorsque votre service effectue différents types de tâches pour différents utilisateurs ou lorsqu'il exécute une tâche particulière avec des résultats possibles différents.

Différentes tâches

Les services qui effectuent plusieurs types de tâches, pour différentes catégories d'utilisateurs et dans lesquelles chaque type de travail influence la satisfaction des utilisateurs, bénéficient de plusieurs SLI différents.

Par exemple, si votre service traite à la fois des requêtes de lecture et d'écriture, les utilisateurs effectuant ces tâches peuvent avoir des exigences différentes :

Les requêtes de lecture doivent être rapides.
Les requêtes d'écriture doivent être réussies.

Pour répondre à ces différentes exigences, votre SLI doit pouvoir faire la distinction entre ces deux cas. En règle générale, la métrique SLI comporte un libellé que vous pouvez utiliser pour classer les valeurs dans un bucket parmi plusieurs buckets.

Une tâche avec des résultats différents

Les services qui effectuent un seul type de travail, mais où les attentes des utilisateurs diffèrent en fonction de la réponse, profitent de plusieurs SLI.

Par exemple, si votre service offre uniquement un accès en lecture aux données, les utilisateurs peuvent bénéficier d'une tolérance différente pour la latence en fonction du résultat de la requête :

Les utilisateurs peuvent tolérer les erreurs renvoyées rapidement, car ils peuvent ensuite relancer immédiatement la requête.
Les utilisateurs risquent d'être moins tolérants aux requêtes réussies qui prennent beaucoup de temps.
Les utilisateurs sont moins tolérants face au pire scénario : les requêtes qui prennent beaucoup de temps pour renvoyer une erreur.

Dans ce cas, votre SLI de latence doit pouvoir distinguer les requêtes ayant réussi ou échoué.

Étape suivante

Pour en savoir plus sur la mise en œuvre des SLI pour les services Google Cloud à l'aide de métriques Google Cloud, consultez les articles suivants:

Pour en savoir plus sur la mise en œuvre des SLI spécifiques à une application, consultez les articles suivants:

Pour obtenir un exemple illustrant la création d'un SLI pour les services qui signalent des métriques personnalisées, consultez la section Définir des SLO : observabilité à l'aide de métriques personnalisées.