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, Service Level Indicator) est une mesure de la fiabilité à utiliser à la fois pour évaluer la fiabilité du service et prendre des décisions le concernant.

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 chapitres suivants du manuel sur l'ingénierie en fiabilité des sites:

Propriétés d'un bon SLI

Nous considérons les SLI "satisfaisants" à ceux qui 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 plus ou moins linéaire avec la satisfaction des utilisateurs.

    Un bon SLI évolue de manière monotone et plus ou moins linéaire, avec une bonne satisfaction des utilisateurs. Si le SLI s'améliore, le niveau de satisfaction des utilisateurs s'améliore et inversement. 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 cible.

Les promesses peuvent être de niveau inférieur, comme les exemples HTTP et gRPC, ou un niveau supérieur, comme l'exemple de workflow.

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 mise en œuvre.

Par contre, la mesure basée sur le navigateur inclut également toute latence introduite par la connexion de l'utilisateur à votre service. Dans le cas d'un service 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, alors que le signal basé sur le navigateur constitue un bonne représentation de la satisfaction des utilisateurs, le signal peut ne pas fournir des informations exploitables permettant d'améliorer la fiabilité de votre service.

Pour plus d'informations 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 si votre service effectue différents types de tâches pour différents utilisateurs ou s'il exécute une tâche particulière avec des résultats possibles différents.

Différentes tâches

L'un des services qui profite de plusieurs SLI est un service qui effectue plusieurs types de tâches, pour différentes catégories d'utilisateurs et dans lesquelles chaque type de travail présente des répercussions différentes sur la satisfaction des utilisateurs.

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, cela signifie que 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

Un autre type de service qui profite de plusieurs SLI est un service qui effectue un seul type de travail, mais où les attentes des utilisateurs diffèrent en fonction de la réponse.

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 seront 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: