Choisir vos objectifs de niveau de service (SLO)

Last reviewed 2024-03-29 UTC

Ce document du framework d'architecture Google Cloud explique comment l'expérience utilisateur définit la fiabilité et comment choisir les objectifs de niveau de service appropriés pour atteindre ce niveau de fiabilité. Ce document s'appuie sur les concepts définis dans la section Composants des SLO.

La culture de l'ingénierie en fiabilité des sites (SRE) exige des services fiables et la satisfaction du client (ou satisfaction du client). Sans niveau de service défini et méthode de collecte des métriques définie, il est difficile (voire impossible) de déterminer où et combien investir dans les améliorations.

La métrique principale que vous utilisez pour mesurer le niveau de service est l'objectif de niveau de service (SLO, Service Level Objective). Un SLO est constitué des valeurs suivantes:

  • Un indicateur de niveau de service (SLI): une métrique d'un aspect spécifique de votre service, comme décrit dans la section Choisir vos SLI.
  • Durée: période de mesure du SLI. Il peut s'agir d'une période calendaire ou glissante.
  • Une cible: valeur (ou plage de valeurs) que le SLI doit atteindre pendant la durée donnée dans un service opérationnel. Par exemple, le pourcentage d'événements satisfaisants par rapport au nombre total d'événements que vous souhaitez que votre service respecte, tel que 99,9%.

Choisir les SLO adaptés à votre service est un processus.. Vous commencez par définir les parcours utilisateur qui définissent la fiabilité et, à terme, vos SLO. Les SLO que vous choisissez doivent mesurer l'intégralité du système tout en équilibrant les besoins de développement des fonctionnalités et la stabilité opérationnelle. Une fois que vous avez choisi vos SLO, vous devez les améliorer de manière itérative et les gérer à l'aide de marges d'erreurs.

Définir vos parcours utilisateur

Dans l'idéal, vos SLI et SLO sont basés sur les parcours utilisateur critiques (CUJ). Les CUJ tiennent compte des objectifs des utilisateurs et de la manière dont votre service les aide à les atteindre. Vous définissez un CUJ sans tenir compte des limites du service. Lorsqu'un CUJ est atteint, le client est satisfait, ce qui indique que le service a réussi.

La satisfaction du client, ou insatisfaction, détermine la fiabilité et est la fonctionnalité la plus importante de tout service.

Par conséquent, définissez un SLO suffisamment élevé pour que la plupart des utilisateurs soient satisfaits de votre service, mais pas au-delà. Tout comme une disponibilité de 100% n'est pas le bon objectif, l'ajout de plus de "9" à vos SLO devient rapidement coûteux et peut même ne pas avoir d'importance pour le client.

Pour le temps d'activité et d'autres métriques essentielles, visez une cible inférieure à 100 %, mais proche de celle-ci. Évaluez le niveau minimal de performances et de disponibilité du service requis. Ne définissez pas de cibles en fonction de niveaux contractuels externes.

Utiliser des CUJ pour développer des SLO

Choisissez les CUJ les plus importants de votre entreprise et procédez comme suit pour développer des SLO:

  1. Choisissez une spécification SLI (par exemple, disponibilité ou actualisation).
  2. Définissez le mode de mise en œuvre de la spécification SLI.
  3. Assurez-vous que votre plan couvre tous les CUJ.
  4. Définissez des SLO en fonction des performances passées ou des besoins de l'entreprise.

Les CUJ ne doivent pas être limités à un seul service, ni à une seule équipe de développement ou une seule organisation. Votre service peut dépendre de dizaines d'autres services ou plus. Vous pouvez également vous attendre à ce que ces services fonctionnent à 99,5%. Toutefois, si les performances de bout en bout (système entier) ne sont pas suivies, l'exécution d'un service fiable s'avère difficile.

Définir la cible et la durée

Il peut être difficile de définir une cible et une durée (voir la définition précédente d'un SLO). Une méthode pour commencer le processus consiste à identifier les SLI et à les suivre au fil du temps. Rappelez-vous qu'un SLO n'a pas besoin d'être parfait dès le départ. Itérez votre SLO pour vous assurer qu'il concorde avec la satisfaction client et qu'il répond aux besoins de votre entreprise.

Lorsque vous effectuez le suivi de conformité des SLO lors d'événements tels que des déploiements, des interruptions ou un trafic quotidien normal, vous obtenez des informations sur la cible. Grâce à ces informations, il sera plus facile de déterminer ce qui est bon, mauvais ou tolérable pour vos cibles et vos durées.

Le développement de fonctionnalités, l'amélioration du code, les mises à niveau matérielles et d'autres tâches de maintenance peuvent vous aider à rendre votre service plus fiable. La possibilité d'effectuer ces petites modifications fréquentes vous aide à fournir des fonctionnalités plus rapidement et avec une meilleure qualité. Toutefois, la fréquence de modification de votre service affecte également la fiabilité. Les objectifs de fiabilité réalisables définissent un rythme et un champ d'application du changement (appelés vitesse des caractéristiques) que les clients peuvent tolérer et dont ils peuvent bénéficier.

Si vous ne pouvez pas mesurer l'expérience client et définir des objectifs basés sur celle-ci, vous pouvez faire appel à des sources externes et à des analyses comparatives. S'il n'y a pas de référence comparable, mesurez l'expérience client, même si vous ne pouvez pas encore définir d'objectifs. Au fil du temps, vous pouvez atteindre un seuil raisonnable de satisfaction client. Ce seuil correspond à votre SLO.

Comprendre le système dans son ensemble

Votre service peut résider dans une longue ligne de services avec un traitement à la fois en amont et en aval. La mesure des performances d'un système distribué de manière fragmentaire (service par service) ne reflète pas précisément l'expérience de votre client et peut provoquer une interprétation trop sensible.

Au lieu de cela, vous devez mesurer les performances par rapport au SLO à l'interface du processus afin de comprendre l'expérience des utilisateurs. L'utilisateur n'a pas à s'inquiéter d'une défaillance de composant qui entraîne l'échec d'une requête si celle-ci est relancée automatiquement et avec succès.

Si des services internes partagés sont en place, chaque service peut mesurer les performances séparément par rapport au SLO associé, les services visibles par l'utilisateur servant de clients. Gérez ces SLO séparément.

Il est possible de créer un service à disponibilité élevée (par exemple, 99,99 %) sur un service moins disponible (par exemple, 99,9 %) en utilisant des facteurs de résilience tels que les nouvelles tentatives d'exécution intelligentes, la mise en cache et la mise en file d'attente. Toute personne ayant une connaissance pratique des statistiques doit pouvoir lire et comprendre votre SLO sans comprendre votre service ou votre structure organisationnelle sous-jacent, comme décrit dans la loi de Conway.

Choisir les SLO appropriés

Il existe une tension naturelle entre la vitesse de développement des produits et la stabilité opérationnelle. Plus vous modifiez votre système, plus les chances de dysfonctionnement augmentent. Les outils de surveillance et d'observabilité sont essentiels pour la stabilité opérationnelle à mesure que vous augmentez la vitesse d'exécution des caractéristiques. Ces outils sont appelés outils de gestion des performances des applications (APM, Application Performance Management) et peuvent également être utilisés pour définir des SLO.

Lorsqu'il est correctement défini, un SLO aide les équipes à prendre des décisions opérationnelles basées sur les données, ce qui augmente la vitesse de développement sans compromettre la stabilité. Le SLO peut également assurer l'harmonie des équipes chargées du développement et des opérations autour d'un seul objectif convenu. Le partage d'un seul objectif atténue les tensions naturelles mentionnées précédemment: l'objectif de l'équipe de développement de créer et d'effectuer des itérations sur les produits, et l'objectif de l'équipe chargée des opérations de maintenir l'intégrité du système.

Utilisez ce document et d'autres documents de fiabilité du framework d'architecture pour comprendre et développer les SLO. Une fois que vous avez lu et compris ces articles, accédez à des informations plus détaillées sur les SLO (et d'autres pratiques d'ingénierie SRE) dans le livre sur l'ingénierie SRE et le classeur d'ingénierie SRE.

Utiliser des SLO internes stricts

Il est recommandé de définir des SLO internes plus stricts que les contrats de niveau de service externes. Comme les violations du contrat de niveau de service nécessitent généralement l'émission d'un crédit financier ou de remboursements clients, vous souhaitez résoudre les problèmes avant qu'ils n'aient un impact financier.

Nous vous recommandons d'utiliser ces SLO internes plus stricts avec un processus rétrospectif irréprochable et un examen des incidents. Pour en savoir plus, consultez la section Créer un processus collaboratif de gestion des incidents dans la catégorie de fiabilité du Centre d'architecture.

Améliorer les SLO de manière itérative

Les SLO ne doivent pas être figés. Revoyez les SLO régulièrement (une fois par trimestre ou au moins une fois par an) et vérifiez qu'ils reflètent avec précision la satisfaction des utilisateurs et qu'ils sont corrélés aux interruptions de service. Assurez-vous qu'ils couvrent les besoins actuels de l'entreprise et les nouveaux parcours utilisateur critiques. Révisez et augmentez vos SLO si nécessaire après ces examens.

Gérez la vitesse de développement à l'aide des marges d'erreur.

Les marges d'erreur indiquent si votre service est plus ou moins fiable que nécessaire pendant une période donnée. Les marges d'erreur sont calculées sur la base de 100 % - SLO sur une période donnée, par exemple 30 jours.

Lorsqu'il vous reste de la capacité dans votre marge d'erreur, vous pouvez continuer à lancer rapidement des améliorations ou de nouvelles fonctionnalités. Lorsque la marge d'erreur est proche de zéro, ralentissez ou figez les modifications de service et consacrez des ressources techniques pour améliorer les fonctionnalités de fiabilité.

Google Cloud Observability inclut une surveillance des SLO afin de réduire les efforts de configuration des SLO et des marges d'erreur. La suite d'opérations comprend une interface utilisateur graphique pour vous aider à configurer manuellement les SLO, une API pour la configuration programmatique des SLO et des tableaux de bord intégrés pour suivre le taux d'utilisation de la marge d'erreur. Pour en savoir plus, consultez la page Créer un SLO.

Récapitulatif des recommandations de SLO

  • Définissez et mesurez des SLI centrés sur le client, tels que la disponibilité ou la latence du service.
  • Définissez une marge d'erreur centrée sur le client plus stricte que votre contrat de niveau de service externe. Incluez les conséquences en cas de non-respect des règles, comme le blocage de la production.
  • Configurez des SLI de latence pour capturer les valeurs aberrantes, telles que le 90e ou le 99e centile, afin de détecter les réponses les plus lentes.
  • Examinez les SLO au moins une fois par an et assurez-vous qu'ils sont corrélés à la satisfaction des utilisateurs et aux interruptions de service.

Étapes suivantes