Que sont les objectifs et les indicateurs de niveau de service (SLO/SLI) ? 

Quelle est la différence entre les objectifs de niveau de service (SLO) et les indicateurs de niveau de service (SLI) ?

Les objectifs de niveau de service (SLO) définissent des cibles pour certaines métriques, tandis que les indicateurs de niveau de service (SLI) sont le reflet continu de ces métriques. Comme les deux termes sont étroitement liés, ils sont souvent confondus. Très simplement, vous pouvez voir le SLO comme un objectif ou une condition idéale que vous aimeriez qu’un service atteigne : un centile, comme un temps de disponibilité de 99,999 % ou 0,0001 % de temps d’arrêt pour cause d’interruption de service, par exemple. Si un tableau de bord affiche un cadran de 0 à 100 %, une marque à 99,999 % peut matérialiser le SLO. Le SLI sera alors l’aiguille de ce cadran et se déplacera au fil du temps. Si cette aiguille descend sous la barre des 99,999 %, le seuil de performance est franchi. Une alerte se déclenche et oblige l’ingénieur de fiabilité du site à intervenir. Dans le cadre d’un écosystème plus large de gestion des niveaux de service, les SLO et SLI ne peuvent exister l’un sans l’autre.

Comment est calculé un SLI ?

Les SLI sont simplement le pourcentage du nombre total d’événements considérés comme acceptables. Pour mesurer le nombre total de requêtes HTTP exécutées avec succès, la formule du SLI correspondant sera :

(requêtes réussies / nombre total de requêtes) x 100

Prenons encore l’exemple d’un SLI conçu pour mesurer si un serveur devient trop lent. L’organisation peut fixer un seuil minimum de latence, disons 400 millisecondes, et calculer le SLI comme suit :

(requêtes traitées en moins de 400 millisecondes / nombre total de requêtes) x 100

Tout SLI doit être calculé sur une période donnée, par exemple toutes les minutes, sur une heure ou sur un mois entier. Les SLO sont généralement énoncés dans des termes assez longs. Par exemple, les services Amazon Compute promettent un minimum de 95 % de disponibilité mensuelle ; si le service ne respecte pas ce chiffre, les clients ont droit à un crédit de 100 % sur leur facture. Évaluer un SLI sur une période plus courte peut être utile pour résoudre les problèmes, mais s’il s’agit d’assurer le respect des SLA, l’entreprise aura besoin d’un SLI portant sur une période plus longue.

Qu’est-ce qu’un bon SLO ?

Les qualités d’un bon objectif de niveau de service ont été définies à l’origine par Rick Sturm, Wayne Morris et Mary Jander dans leur livre Foundations of Service Level Management, paru en 2000. Les auteurs établissent ces caractéristiques clés :

• Réalisme : un SLO de 100 % est inaccessible sur le plan fonctionnel et représente un objectif théorique, pas un SLO utile. Les SLO doivent représenter un niveau de performance minimum acceptable et ne jamais être considérés comme « impossibles ».
• Pertinence : de nombreuses organisations définissent des SLO pour des métriques qui n’ont pas réellement d’importance pour l’entreprise. L’utilisation du processeur est souvent donnée comme exemple de SLO inutile ; dans la plupart des entreprises, il n’a aucune importance pour les utilisateurs et les activités.
• Capacité de mesure : si une métrique ne peut pas être mesurée avec précision, elle ne sera pas utile en tant que SLO.
• Capacité de contrôle : un SLO qui fixe un seuil maximum au nombre de foudroiements sur le centre de données, par exemple, n’aurait pas de valeur.
• Intelligibilité : certaines mesures n’ont pas une pertinence immédiate pour la gestion informatique. Par exemple, le taux de « collision de paquets » est couramment utilisé pour évaluer les performances du système, mais il n’apporte pas réellement d’information pertinente aux utilisateurs et ne doit donc pas être utilisé comme un SLO.
• Rentabilité : une organisation a-t-elle vraiment besoin d’une disponibilité de 99,9999 % si 99,99 % est acceptable ? S’il faut investir dans plusieurs centres de données redondants, des protocoles de basculement et du personnel supplémentaire, le coût de l’investissement visant à garantir le SLO dépasse probablement de loin l’avantage apporté par ces 52 minutes de disponibilité supplémentaires.
• Acceptation mutuelle : les SLO doivent être acceptés par toutes les parties concernées, généralement le prestataire de services et le client.

Une fois un SLO choisi, il convient de définir sa valeur. Ce doit être le fruit d’une négociation entre le fournisseur de services et le client (qu’il soit interne ou externe), bien que dans de nombreux cas, les SLO puissent être présentés comme des valeurs « à prendre ou à laisser ».

En fin de compte, il est important de comprendre qu’un SLO ne doit jamais être considéré comme un chiffre idéal ou un seuil maximal pour une métrique, mais plutôt comme un niveau minimum acceptable pour que l’entreprise puisse atteindre ses objectifs commerciaux.

Qu’est-ce que le taux d’erreur d’un SLI ?

Le taux d’erreur d’un SLI est la proportion d’activité qui tombe en dessous du seuil minimum du SLO. En d’autres termes, le taux d’erreur est l’inverse du SLI : 1 – SLI = taux d’erreur.

Le taux d’erreur, parfois appelé budget d’erreur, est simplement une autre façon d’envisager la mesure des performances. Une disponibilité de 99 % par mois peut être plus facile à interpréter (et plus prudente) lorsqu’elle est exprimée sous la forme d’un taux d’erreur de 1 % de temps d’arrêt par mois, en particulier si le SLO est de l’ordre de 99,999 % de disponibilité (soit un taux d’erreur de 0,001 %). Cette notion peut également être exprimée sur une forme quantitative : par exemple, 7,2 heures d’indisponibilité par mois.

Le concept de budget d’erreur donne à la direction informatique les outils dont elle a besoin pour prendre des décisions plus stratégiques concernant les temps d’arrêt et la latence. Par exemple, si la direction sait qu’un serveur doit absolument être mis hors ligne sans sauvegarde disponible et qu’elle dispose d’un budget d’erreur de 7,2 heures par mois de temps d’arrêt autorisé, elle va s’efforcer d’inscrire l’intervention de maintenance dans cette fenêtre.

Comment définit-on les accords de niveau de service (SLA) ?

Les accords de niveau de service sont des contrats formels, entre une organisation et une partie externe, ou au sein de l’organisation. Ils spécifient les objectifs de niveau de service d’un service fourni. Les SLA formalisent les SLO et, dans le cas d’un fournisseur de services (généralement un fournisseur de services cloud), ils prévoient normalement des pénalités si un SLO n’est pas atteint.

Les SLA externes incluent également d’autres conditions contractuelles, comme le mécanisme requis pour demander des crédits ou des remboursements, des exclusions pour certaines actions (une erreur du client par exemple), une définition formelle des modalités de calcul des SLI et les processus de résiliation ou de modification du SLA.

Les équipes juridiques, de réponse aux incidents ou d’ingénierie peuvent utiliser des SLA internes pour mesurer, entre autres, l’efficacité des opérations du centre de services, les performances et la disponibilité du réseau interne, ou même la proportion de rétrofacturations dues à la fraude.

Quel est le lien entre les KPI et les SLA ?

Les indicateurs clés de performance (KPI) sont des métriques qui mesurent les performances d’un processus métier réel. Au sens large, le terme peut être appliqué aux processus, aux systèmes ou même à des collaborateurs. Dans le monde de l’informatique, les KPI sont couramment employés pour définir les performances du système sur un réseau interne ou externe. Idéalement, ils doivent être liés aux résultats de l’entreprise. Par exemple, la disponibilité d’un site web de commerce électronique est directement liée aux revenus que ce dernier peut générer ; les deux peuvent être utilisés comme KPI.

Les KPI sont étroitement liés aux SLI, et les termes sont souvent utilisés de manière interchangeable dans les accords SLA. Selon certaines opinions, toutefois, si les KPI devraient être purement quantitatifs, les SLI devraient être un peu plus abstraits et apporter un certain niveau de réflexion sur l’expérience client ainsi qu’une perspective plus stratégique, au lieu de simplement mesurer les performances.

Comment un SRE définit-il les SLO, les SLI et les SLA ?

Un ingénieur de fiabilité des sites (SRE) aura un point de vue distinct sur les SLO, les SLI et les SLA. Comme les SRE sont principalement chargés d’assurer la disponibilité du réseau et des services, ils axent fortement ces mesures de niveau de service sur la disponibilité et la fiabilité. Un système qui n’est pas disponible n’est pas fiable, et c’est pourquoi les SLA sont conçus pour garantir une disponibilité maximale. Les SLI sont examinés en temps réel pour superviser les conditions du système, et les SLI historiques sont analysés par un SRE pour déterminer si et quand un système est susceptible de subir une interruption de service à l’avenir. Les outils d’IA peuvent être particulièrement utiles dans cette analyse.

Comme pour tout SLO, l’augmentation de l’exigence de disponibilité se traduit par une augmentation des coûts. Les SRE sont bien conscients qu’il est impossible d’assurer 100 % de disponibilité. Dans bien des cas, d’ailleurs, il n’est ni approprié ni souhaitable de garantir une disponibilité de 100 %. Pour de nombreux services, les temps d’arrêt planifiés sont intentionnels. Ils évitent d’exagérer la dépendance ou les attentes vis-à-vis de la disponibilité d’un seul service, et peuvent également contribuer à découvrir et à prévenir les utilisations inappropriées et les violations de la sécurité.

Quelles sont les applications des SLO et des SLI ?

Les SLO et les SLI sont utilisés dans un large éventail d’applications commerciales et technologiques, à la fois internes et externes. Les SLO sont largement utilisés pour mesurer les performances et la fiabilité de divers produits SaaS, comme la disponibilité de l’hébergement web ou du stockage cloud, et la latence ou la réactivité de divers services d’hébergement d’applications cloud. Si les SLO sont généralement décrits dans les contrats des fournisseurs de services cloud, il incombe souvent au client de superviser les SLI pour contrôler la conformité aux SLO indiqués.

Voici les applications classiques des SLI que vous êtes susceptible de rencontrer :

• Disponibilité du serveur : dans quelles proportions un serveur ou un service web est-il disponible et réactif ?
• Latence du serveur : combien de temps a-t-il fallu au serveur ou au service pour répondre à une requête ?
• Taux d’erreur : à quelle fréquence une requête (à un serveur web, par exemple) entraîne-t-elle une réponse d’erreur ?
• Débit/performance : à quelle vitesse les données sont-elles livrées sur un canal donné ?
• Utilisation : à quelle fréquence un certain service est-il utilisé ?
• Fraîcheur des données : dans quelles proportions les données fournies aux utilisateurs correspondent bien à la version la plus récente ?

Les SLI servent également à évaluer les performances humaines. Par exemple :

• Réactivité du centre de services : à quelle vitesse les appels du centre d’assistance sont-ils pris en charge (ou résolus) ?
• Niveau d’escalade : à quelle fréquence les appels au service d’assistance sont-ils transmis au niveau supérieur ?

Pour être utile, chacun de ces SLI doit être mesuré sur une période définie et comparé au SLO correspondant afin d’établir un seuil minimum.

Pourquoi avons-nous besoin de SLO ?

Les SLO sont essentiels pour s’assurer qu’une entreprise reçoit bien les services pour lesquels elle paie. Les SLO évaluent les performances de vos systèmes internes et celles de vos employés, et ils peuvent même quantifier les attentes et la satisfaction des clients. Sans SLO, une organisation n’a aucun moyen de superviser ces indicateurs de performance et ne saura pas si les conditions sont bonnes ou mauvaises, si elles s’améliorent ou se dégradent.

Les utilisateurs finaux attendent aujourd’hui beaucoup des services et des applications web. De brèves périodes d’indisponibilité et des problèmes de latence mineurs peuvent sembler négligeables, mais ils sont vivement ressentis par l’utilisateur en ligne chevronné. En effet, une latence de plus d’une seconde peut faire perdre aux utilisateurs leur concentration sur la tâche qu’ils accomplissent. Après 10 secondes, la frustration peut être telle qu’ils abandonnent entièrement la tâche en question.

Dans toutes les entreprises, garantir une expérience réactive et sans erreur devient une fonction essentielle. Superviser les SLI et les évaluer par rapport aux SLO est le moyen le plus efficace d’obtenir des informations quantifiables et indispensables sur l’environnement de service en contact avec le client.

Comment mettre en œuvre des SLO et des SLI ?

Les SLO et les SLI sont essentiels dans presque toutes les entreprises. Pour commencer, vous devez comprendre en profondeur le fonctionnement de vos différents systèmes et la manière dont les employés et les clients interagissent avec eux. Vous devez avoir une vision claire de votre architecture et de son impact sur l’expérience client.

En général, le mieux est de commencer par les bases. Les SLO simples axés sur la disponibilité et la latence du réseau et des services sont les plus courants pour une bonne raison : ils sont faciles à calculer et à interpréter, et ils ont un impact significatif et évident sur l’utilisateur. Certains SLO spécifiques peuvent être plus difficiles à cerner, mais en supervisant les SLI et en procédant par itérations, les analystes peuvent affiner les SLO afin de déterminer le niveau offrant la valeur maximale à l’organisation.

Notez également que, dans de nombreuses organisations, les SLO et les SLI ne sont pas créés en interne. Ils sont intégrés aux SLA présentés par les fournisseurs. Pour les petites entreprises, ces SLO ne seront sans doute pas négociables, mais ils représentent tout de même des mesures importantes et il convient de les superviser.

Quelles sont les directives et bonnes pratiques qui encadrent les SLO/SLI ?

Quelques bonnes pratiques orientent la définition et la gestion des SLO et des SLI :

• Concentrez-vous sur les métriques qui comptent : les SLO doivent être pertinents et exercer un impact réel sur le client.
• La compréhension est essentielle : les objectifs de niveau de service doivent être facilement compris par les parties prenantes extérieures au service informatique. Choisissez donc ceux qui correspondent bien aux besoins de l’entreprise et des clients.
• Les SLI doivent être vérifiables : vous devrez peut-être contrôler périodiquement les SLI pour vérifier qu’ils sont mesurés correctement. Si vos tableaux de bord indiquent que le SLO de disponibilité est atteint, mais que les utilisateurs se plaignent que des services sont inaccessibles, vous devez inspecter les modalités de production des métriques.
• Minimisez le nombre total de SLO : ne submergez pas votre tableau de bord de SLO ; veillez à suivre uniquement les métriques les plus pertinentes et non redondantes afin que le système reste simple et utile.
• Agissez lorsque les SLO ne sont pas conformes : agissez immédiatement pour déterminer pourquoi le SLI est inférieur aux attentes et travaillez sans attendre à un plan de remédiation.
• Examinez périodiquement tous les SLO : les entreprises et les technologies changent parfois de façon spectaculaire. Le SLO qui était pertinent l’année dernière peut être obsolète, voire inutile, aujourd’hui.

Les clients sont plus exigeants que jamais, et l’un des moyens les plus clairs de mesurer la qualité de leur expérience consiste à utiliser les SLO et les SLI. En accordant une attention particulière aux SLO et aux SLI correspondants, une entreprise peut s’assurer que ses systèmes fonctionnent conformément aux attentes, gage d’une meilleure satisfaction des clients et de profits maximisés.