SLO, SLI, SLA ? Qu'est-ce que tout cela ?

SLO, SLI, SLA ?
Qu'est-ce que tout cela ?

Les niveaux de service décrivent, en termes mesurables, les services proposés aux utilisateurs au cours d'une période donnée. Les objectifs de niveau de service (SLO) indiquent la disponibilité attendue d'un système. Les indicateurs de niveau de service (SLI) sont les mesures et métriques clés permettant de déterminer la disponibilité d'un système. Les accords de niveau de service (SLA) sont les contrats légaux qui expliquent ce qui a été convenu et ce qui adviendra si le système ne répond pas aux SLO.

Par exemple, un SLO pour une application web peut indiquer que les vidéos doivent démarrer en moins de 2 secondes 99 % du temps, au cours d'une période d'une semaine. Le SLI mesure alors la proportion des vidéos du site web dont la lecture commence en moins de 2 secondes. Le SLA inclut ce SLO particulier ainsi que d'autres SLO convenus par le client et le prestataire, l'étendue des services couverts et les SLI (c'est-à-dire les métriques utilisées pour mesurer les performances).

L'ingénierie de la fiabilité des sites (SRE) a popularisé les bonnes pratiques permettant d'assurer la disponibilité et la fiabilité continues des systèmes distribués. Elle se focalise sur la façon de mesurer les performances et la fiabilité des services. En mars 2016, Google a publié Site Reliability Engineering: How Google Runs Production Systems (Ingénierie de la fiabilité des sites : comment Google exécute les systèmes de production). Ce manuel décrit un cadre de modélisation, sélection et analyse des métriques qui commence avec les objectifs de niveau de service.

Comment les SLO, SLI et SLA sont-ils liés les uns aux autres et comment faut‑il gérer les niveaux de service auxquels s'attendent les utilisateurs ? Pour répondre à cette question, examinons chacun d'eux plus en détail.

An SLA is typically created by the business and legal teams, working with the customer (for specific contracts). Providers also present general SLAs for their services, such as cloud service providers for their different instance types. SLAs can include multiple SLOs, the scope of services that will be covered, and the SLIs used to measure performance.

SLOs, SLIs, and SLAs help ensure a quality of service from a set of technologies. All influencers of SLOs, SLIs, and SLAs should be consulted to help be sure goals are attainable and customers are satisfied.

Que sont les SLO ?

Les objectifs de niveau de service, ou SLO, sont les objectifs que vous définissez en termes de disponibilité attendue du système. Ils sont exprimés en pourcentage sur une période de temps donnée. 

Les SLO aident les équipes à mieux collaborer, car elles comprennent de la même façon ce que signifie le terme « disponibilité ». Les SLO sont alors utilisés en tant que standard permettant de mesurer la fiabilité et la disponibilité. Dans l'exemple plus haut, un des SLO indique que les vidéos de l'application web doivent démarrer en moins de 2 secondes 99 % du temps, au cours d'une période d'une semaine.

Que sont les SLI ?

Les SLI sont les mesures quantitatives de l'expérience utilisateur en ce qui concerne la disponibilité du système. Ils représentent le coefficient de réussite d'un niveau de service, exprimé en pour cent. 

La description de ces indicateurs de niveau de service dépend des SLO, mais les signaux en temps réel qu'ils fournissent impliquent la fiabilité du système. Les SLI peuvent mesurer le taux des requêtes qui ont été plus rapides que le seuil défini ou celui des enregistrements passant dans un pipeline qui ont la valeur correcte à la sortie. Dans l'exemple ci-dessus, le SLI mesure le taux de vidéos sur le site web dont la lecture commence en moins de 2 secondes. Vous pouvez ainsi voir si vous êtes près ou loin de l'objectif requis dans le SLO.

Que sont les SLA ?

Les SLA définissent le niveau de service attendu par vos clients lorsqu'ils utilisent votre service.

Ces accords de niveau de service sont des contrats entre les prestataires et les clients. Ils documentent les services que le prestataire fournira et établissent les normes de service que le prestataire doit respecter. Les SLA décrivent les recours ou pénalités imputables en cas de non-respect des engagements pris dans le SLO.

Dans notre exemple, le SLA inclut tous les SLO pour l'application web, ainsi que l'étendue des services couverts et tous les SLI (c'est‑à‑dire les métriques utilisées pour mesurer les performances en fonction des SLO). Ils comprennent également les responsabilités incombant au prestataire de service et au client.

Voici quelques exemples supplémentaires de SLI mesurant l'expérience utilisateur en temps réel en fonction des SLO :

Qui utilise les niveaux de service SLO, SLI et SLA ?

Les équipes SRE et transfonctionnelles peuvent souvent avoir du mal à définir et mesurer la fiabilité des services. Elles ont besoin d'une vue agrégée et complète des métriques importantes pour tous les aspects d'un service ou système afin de pouvoir facilement mesurer et optimiser la disponibilité et les performances.

Les niveaux de service sont importants pour aider les équipes SRE et les ingénieurs de la fiabilité des sites à identifier les composants essentiels de leurs applications et infrastructure. En particulier, il est nécessaire de savoir quand un ou plusieurs composants nuisent à la fonctionnalité pour les clients externes. Nous appelons ces points d'intersection les limites du système. C'est au niveau de ces limites que les ingénieurs SRE doivent appliquer des indicateurs et objectifs de niveaux de service aux métriques afin de révéler ce qui se passe vraiment en termes de performances et de fiabilité du système. 

L'établissement des limites de service, des métriques qui doivent être des SLI, et des exigences de conformité pour les SLO exige beaucoup de travail et de réflexions en amont. Face à cette complexité, il arrive souvent que les équipes abandonnent tout effort. Afin de pouvoir rapidement définir une base de disponibilité de référence sur tout le stack et pour toutes les équipes, les ingénieurs de la fiabilité des sites et les équipes SRE ont besoin de SLI et de SLO précis et personnalisés qui sont ancrés sur les performances historiques du système.

Si les équipes SRE et les ingénieurs de la fiabilité des sites ne sont pas toujours chargés de la gestion des niveaux de service, ceux-ci relèvent quand même souvent de leur compétence. En faisant le suivi des SLI et en les associant aux SLO, il est possible de définir les objectifs de performance d'un système. Le manuel de Google sur les SRE établit les quatre signaux dorés des niveaux de service, soit : la latence, le trafic, les erreurs et la saturation. À titre d'exemple, vous pourriez observer un appel d'API et faire le suivi du nombre de requêtes réussies ou pas (SLI) par rapport au pourcentage global de requêtes devant être réussies (SLO, 95 % par exemple) pour que l'expérience client soit bonne.

Les équipes SRE définissent souvent des SLO stricts sur les composants essentiels de leurs applications et services afin de mieux comprendre le degré d'exigence acceptable dans le SLA avec leurs clients. À partir de là, l'équipe peut appliquer des budgets d'erreur afin de comprendre à quelle vitesse ils doivent résoudre les erreurs afin d'assurer le respect des SLO établis. Les niveaux de service permettent aux équipes d'agréger les métriques et de créer une vue transparente de la disponibilité, des performances et de la fiabilité dans toute l'organisation. Les cadres de l'organisation peuvent alors utiliser ces niveaux de service pour monitorer en un coup d'œil le respect de la conformité par les équipes, les applications, les services, etc. et ainsi mieux comprendre l'intégrité du système dans sa globalité.

Qu'est-ce que la gestion des niveaux de service ?

La gestion des niveaux de service vise à assurer que tous vos processus et accords opérationnels sur le niveau des services que vous proposez à vos clients sont acceptables. Cela comprend le monitoring et les rapports sur les niveaux de service, la mise en place et l'ajustement des SLO, l'établissement des SLI, le respect du SLA, et des comptes rendus avec le client. 

Le point focal est vraiment d'avoir la même définition du terme « disponibilité » entre les équipes et dans les SLO, mais aussi de l'intégrer dans les SLA avec les clients. Pour respecter ou dépasser ces accords de niveau de service, il est important pour les équipes transfonctionnelles de gérer des SLO en interne. 

Cette vidéo montre comment les équipes peuvent utiliser la gestion des niveaux de service avec New Relic.

Les avantages de la gestion des niveaux de service

La mise en place dans toutes les équipes des bonnes pratiques pour les SLO n'est pas simple. Vous avez besoin de données adéquates pour établir le langage qui sera commun à toutes les équipes.

Les ingénieurs de la fiabilité doivent rapidement mettre en place la base de disponibilité de référence pour tout le stack et l'équipe. Il est nécessaire d'avoir des SLO et des SLI permettant de déterminer les limites de services et d'obtenir une vue unifiée, uniformisée et transparente de la fiabilité de ces services afin de mieux respecter la conformité avec les SLA côté client. Il est vital de pouvoir générer des rapports sur la fiabilité, sur les métriques de conformité des SLO et sur les budgets d'erreur afin de pouvoir apporter des améliorations sur tout l'environnement.

Une fois que les bonnes pratiques sont établies pour les SLI, SLO et SLA, et qu'une plateforme de gestion des niveaux de service est mise en place, vous bénéficiez des avantages suivants :

• Une configuration simple : établissement automatique d'une base de référence pour les performances et la fiabilité de tous les services avec configuration en un clic, et recommandations et personnalisations fournies dans un flux guidé et simple.
• Une définition de ce qu'est la « fiabilité » pour toutes les équipes : évitez les processus d'alignement pénibles grâce à des recommandations de SLO et de SLI qui vous aident à déterminer les limites de service. Définissez automatiquement les bases de référence en fonction des métriques de performance récentes dans n'importe quelle entité.
• L'itération et l'amélioration en continu : avec la contextualisation et l'automatisation full-stack via des outils open source d'infrastructure en tant que code comme Terraform, les équipes obtiennent des informations détaillées sur l'impact de nœuds ou services particuliers sur la fiabilité du système et peuvent rapidement prendre le contrôle des performances. Les vues personnalisées pour les propriétaires de services et les cadres permettent d'améliorer l'efficacité opérationnelle et d'obtenir de meilleurs rapports, alertes et processus de gestion des incidents.
• La normalisation de la fiabilité : les équipes transfonctionnelles disposent d'une vue unifiée, uniformisée et transparente de la fiabilité des services et peuvent mieux se conformer aux SLA côté client. Les métriques de conformité des SLO et les budgets d'erreur permettent aux organisations d'obtenir des rapports sur la fiabilité et d'apporter des changements homogènes sur toutes les applications, sur l'infrastructure et dans les équipes.

Pour plus de conseils, consultez les articles Best practices for setting SLOs and SLIs for modern, complex systems (Les bonnes pratiques pour établir les SLO et les SLI avec des systèmes modernes complexes) et Introducing service level management (Présentation de la gestion des niveaux de service) de notre blog.