Choisir vos objectifs de niveau de service (SLO)

Last reviewed 2024-03-29 UTC

Ce document du framework d'architecture Google Cloud définit 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 de la fiabilité des sites (SRE) valorise les services fiables et le bonheur des clients (ou satisfaction client). Sans niveau de service défini et sans méthode permettant de collecter des métriques, il est difficile (voire impossible) de déterminer où et combien investir dans des 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 se compose 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 basée sur le calendrier ou d'une période glissante.
  • Cible: valeur (ou plage de valeurs) que le SLI doit respecter 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 prévoyez pour votre service (99,9 %, par exemple).

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

Définir vos parcours utilisateur

Vos SLI et SLO sont idéalement 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 est réussi.

La satisfaction ou l'insatisfaction des clients détermine la fiabilité, qui est la caractéristique 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 parcours utilisateur les plus importants de votre entreprise, puis suivez ces étapes 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 toutes 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 complet) ne sont pas suivies, l'exécution d'un service fiable est difficile.

Définir la cible et la durée

Il peut être difficile de définir la cible et la 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. N'oubliez pas 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 insights sur la cible. Ces insights vous permettront de voir plus clairement ce qui est bon, mauvais ou acceptable pour vos cibles et 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 contribuer à 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 vitesse à laquelle votre service change affecte également la fiabilité. Les objectifs de fiabilité réalisables définissent le rythme et le champ d'application des modifications (appelé vitesse des fonctionnalités) 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 vous tourner vers des sources externes et une analyse comparative. 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 l'ensemble du système

Votre service peut faire partie d'une longue liste de services avec un traitement en amont et en aval. Mesurer les performances d'un système distribué de manière fragmentée (service par service) ne reflète pas exactement l'expérience de votre client et peut donner lieu à une interprétation trop sensible.

Au lieu de cela, vous devez mesurer les performances par rapport au SLO au niveau de 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 séparément les performances par rapport à l'objectif de niveau de service 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. Quiconque ayant une connaissance pratique des statistiques devrait pouvoir lire et comprendre votre SLO sans comprendre votre service ou votre mise en page organisationnelle sous-jacents, 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 à la stabilité opérationnelle à mesure que vous augmentez la vitesse de développement. 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 entre les équipes chargées du développement et les équipes opérationnelles autour d'un seul et même objectif convenu. Le partage d'un seul objectif atténue la tension naturelle mentionnée précédemment: l'objectif de l'équipe de développement est de créer et d'itérer sur les produits, et celui de l'équipe d'exploitation est de maintenir l'intégrité du système.

Utilisez ce document et les autres documents sur la fiabilité du framework Architecture pour comprendre et développer des 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 de rétrospective irréprochable et un examen des incidents. Pour en savoir plus, consultez la section Créer un processus collaboratif de gestion des incidents.

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 budgets d'erreur indiquent si votre service est plus ou moins fiable que nécessaire pour 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ésumé des recommandations concernant les 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