Close

La voie vers une meilleure gestion des incidents
débute ici

SLA vs. SLO vs. SLI: What’s the difference?

Les sociétés informatiques ont toutes une caractéristique en commun : les utilisateurs.

Qu'il s'agisse du moteur de recherche Google, qui compte un milliard d'utilisateurs réguliers mensuels pour un service gratuit, ou de Salesforce, qui compte 3,75 millions d'abonnés aux services payants, tous les produits technologiques sont des services aux personnes.

Dans un monde perpétuellement connecté, les attentes des utilisateurs sont élevées, que les services soient payants ou gratuits. Vitesse. Temps d'activité. Utilité de l'expérience utilisateur. Aujourd'hui, les utilisateurs s'attendent à des standards élevés partout.

Logo Looker

Looker fait confiance à Opsgenie pour fournir, chaque jour, un service disponible en continu à 200 000 utilisateurs.

C'est pourquoi les entreprises doivent bien comprendre et respecter les SLA, SLO et SLI, trois acronymes qui correspondent aux promesses faites aux utilisateurs, aux objectifs internes qui permettent de tenir ces promesses, et aux mesures traçables qui indiquent notre niveau de performance.

L'objectif de ces trois éléments est de s'assurer que tout le monde, le prestataire et le client, s'entend sur les performances du système. Quelle est la disponibilité de vos systèmes ? Quel est le délai de réponse de votre équipe en cas de panne du système ? Quelles sont vos promesses en termes de vitesse et de fonctionnalité ? Les utilisateurs veulent savoir, c'est pourquoi vous avez besoin des SLA, SLO et SLI.

Différences entre SLA, SLO et SLI

Accords de niveau de service (SLA)

Qu'est-ce qu'un SLA ?

Un accord de niveau de service (SLA) est un accord passé entre un prestataire et un client sur des indicateurs mesurables comme le temps d'activité, la réactivité et les responsabilités.

Ces accords sont généralement rédigés par les équipes juridiques et commerciales de l'entreprise. Ils actent les promesses que vous faites aux clients, ainsi que les conséquences si vous manquez à ces promesses. Ces conséquences sont en général des pénalités financières, des crédits de service ou des extensions de licence.

Défi des SLA

Les SLA sont connus pour être difficiles à mesurer, à contrôler et à respecter. Ces accords, souvent rédigés par des personnes qui ne maîtrisent pas les technologies, font souvent des promesses difficiles à mesurer, qui ne s'harmonisent pas toujours avec les priorités actuelles et changeantes de l'entreprise, et qui ne prennent pas en compte les nuances.

Par exemple, un SLA peut promettre la résolution d'un ticket signalé sur le produit X dans les 24 heures. Mais ce même SLA ne dit pas ce qui se produit si le client n'envoie pas dans les 24 heures les réponses ou les captures d'écran qui permettront à votre équipe de diagnostiquer le problème. La fenêtre de 24 h accordée à votre équipe a-t-elle été absorbée par le client, ou bien l'horloge commence-t-elle à tourner une fois que le client a répondu ? Les SLA doivent répondre à ces questions, mais comme c'est rarement le cas, beaucoup de responsables informatiques en sont venus à les détester.

For many experts, the answer to this challenge is, first and foremost, that tech should be involved in the creation of SLAs. The more IT and DevOps collaborate with legal and business development to develop SLAs that address real-world scenarios, the more SLAs will start to reflect key realities, such as clients delaying their own issue resolution.

Qui a besoin d'un SLA ?

Un SLA est un accord passé entre un prestataire et un client payeur. Les entreprises fournissant un service gratuit aux utilisateurs sont peu susceptibles de vouloir un SLA pour cette utilisation gratuite (ou d'en avoir besoin).

Objectifs de niveau de service (SLO)

Qu'est-ce qu'un SLO ?

Un objectif de niveau de service (SLO) est un accord interne à un SLA concernant un indicateur spécifique, comme le temps d'activité ou le délai de réponse. Donc, si le SLA est l'accord formel entre vous et votre client, les SLO sont les promesses individuelles que vous lui faites. Les SLO établissent les attentes du client. Ils indiquent aux services informatique et DevOps quels sont les objectifs de référence à atteindre.

Défi des SLO

Les SLO sont plus appréciés que les SLA, mais peuvent susciter autant de problèmes s'ils sont vagues, trop compliqués ou impossibles à mesurer. Pour éviter que les ingénieurs s'arrachent les cheveux, il est essentiel que les SLO soient à la fois simples et clairs. Seuls les indicateurs les plus importants sont admissibles au statut de SLO. Les objectifs doivent être formulés dans un langage clair, et, à l'instar des SLA, doivent toujours prendre en compte d'éventuels problèmes comme les retards côté client.

Qui a besoin de SLO ?

Contrairement aux SLA, pertinents uniquement si la prestation est payante, les SLO sont utiles à la fois pour les comptes gratuits et payants, et pour les clients internes ou externes.

Les systèmes internes, comme les CRM, les dépôts de données client ou les intranets peuvent être aussi importants que les systèmes externes. Établir des SLO pour ces systèmes internes est important à la fois pour atteindre des objectifs commerciaux, mais aussi pour permettre aux équipes internes de répondre à leurs propres objectifs de clientèle.

Indicateurs de niveau de service (SLI)

Qu'est-ce qu'un SLI ?

Un indicateur de niveau de service (SLI) mesure la conformité à un SLO. Par exemple, si un SLA stipule que vos systèmes doivent être disponibles 99,95 % du temps, le SLO est probablement un temps d'activité de 99,95 %, votre SLI étant la mesure effective de ce temps d'activité. Il est peut-être de 99,96 %. Ou bien de 99,99 %. Pour être en conformité avec votre SLA, les SLI doivent respecter ou dépasser les promesses faites dans ce document.

Défis des SLI

Comme pour les SLO, le défi est de formuler des SLI simples, de choisir les bons indicateurs et de ne pas compliquer le travail du service informatique en définissant trop d'indicateurs qui n'ont pas de véritable importance pour le client.

Créez un plan de reprise d'activité détaillé

Que ferez-vous en cas de temps d'arrêt ? Si vous n'avez pas encore la réponse à cette question, la réponse par défaut sera « perdre un temps précieux à déterminer la marche à suivre ».

Plus votre plan de réponse aux incidents est efficace, plus vos équipes les traiteront rapidement et efficacement. C'est pourquoi le traitement et la planification devraient constituer la première étape de tout nouveau programme de gestion des incidents.

Qui a besoin de SLI ?

Toute entreprise mesurant ses performances à l'aide de SLO a besoin de SLI pour réaliser ces mesures. Il n'est pas vraiment possible d'appliquer des SLO sans SLI.

SLA : promesses faites aux clients. SLO : objectifs internes. SLI : avons-nous été bons ?

Bonnes pratiques relatives aux SLA, SLO et SLI

Créez des SLA à partir des attentes des clients

Chaque élément de votre accord client doit être basé sur les critères qui importent pour votre client. En bout de chaîne, un seul incident peut nécessiter d'étudier 10 composants différents. Mais pour le client, tout ce qui compte est que le système fonctionne comme prévu.

Vos SLA et vos SLO doivent refléter cette réalité. Ne compliquez pas les choses avec des accords ultra-détaillés ou des promesses formulées pour chacun de ces 10 composants. Les promesses doivent se limiter aux fonctionnalités générales de l'interface utilisateur. Les clients seront plus satisfaits et moins confus ; le travail des experts informatiques chargés de tenir les promesses du SLA sera simplifié.

Rédigez les SLA dans un langage simple

Les clients ne demandent pas toujours des clarifications, donc si le langage de votre SLA est compliqué, attendez-vous à quelques malentendus qui peuvent vous porter préjudice. Plus la formulation est simple, plus le risque de conflit futur avec le client est faible.

Dans les SLO, moins c'est mieux

Tous les indicateurs ne sont pas essentiels à la réussite de votre client. Ils ne doivent pas tous devenir des SLO. Tenez-vous-en à un nombre de SLO minimum, en ciblant les objectifs essentiels de vos clients.

Toutes les mesures traçables ne doivent pas être des SLI

De même, le suivi des performances de 10 composants pour chacun des 10 SLO peut rapidement devenir fastidieux. Faites plutôt un choix stratégique en sélectionnant les mesures importantes pour vos SLO clés, et appliquez-vous à les suivre rigoureusement.

Incluez des facteurs qui ne dépendent pas du service informatique

Que se passe-t-il lorsque le client freine la résolution du problème ? Si cela n'est pas clair dans votre SLA, votre équipe est tenue à l'impossible : résoudre les tickets du client sans que celui-ci s'implique.

Prévoyez un budget d'erreur

Laisser une marge d'erreur protège non seulement votre entreprise contre le non-respect des SLA et ses lourdes conséquences, mais permet aussi d'être plus agile : votre équipe peut ainsi faire des changements rapides et essayer de nouvelles solutions susceptibles d'échouer.

D'ailleurs, Google recommande d'utiliser le budget d'erreur restant pour des temps d'arrêt planifiés ; cela peut vous aider à identifier des problèmes imprévus (p. ex. des services utilisant des serveurs de façon non adaptée) et à maintenir le degré de satisfaction de vos clients.

Ne visez pas la lune

Même si votre équipe peut certainement assurer 99,99 % de temps d'activité, cela ne doit pas être votre objectif SLO. Il vaut toujours mieux faire des promesses moindres, et aller au-delà. C'est particulièrement vrai pour les équipes agiles qui souhaitent des départs rapides, et qui ont souvent besoin d'un budget d'erreur pour tenir le rythme.

Quel est l'impact sur les équipes SRE ?

Pour ceux d'entre vous qui adoptent le modèle Google et qui font appel à des équipes d'ingénierie de la fiabilité des sites (SRE) pour combler l'écart entre le développement et les opérations, les SLA, les SLO et les SLI sont les clés de la réussite. Les SLA aident les équipes à fixer des limites et à affecter des budgets d'erreur. Les SLO aident à hiérarchiser les tâches. Et les SLI indiquent aux équipes SRE à quel moment les lancements doivent être gelés pour préserver le budget d'erreur, et à quel moment lâcher les rênes.