SLA vs. SLO vs. SLI : Comment choisir ce qui vous convient le mieux

Connaissez-vous le point commun de toutes les entreprises, notamment celles qui développent des solutions technologiques? Peu importe le service/produit proposé, l’expérience utilisateur est leur priorité. Vendre un service/produit technologique signifie servir les gens. Et les attentes de ces utilisateurs augmentent continuellement, que ce soit pour des services gratuits tels que les moteurs de recherches, ou pour des solution payantes comme les solutions de monitoring

Afin de faire face à ces exigences tout en prenant en compte les moyens dont dispose l’entreprise, trois concepts ont vu le jour: SLI (Service Level Indicator), SLO (Service Level Objective), SLA (Service Level Agreement). L’objectif de ces trois éléments est de faciliter l’entente entre l’entreprise et son client en ce qui concerne les performances du système vendu. 

À quelle fréquence les systèmes seront-ils disponibles ? Dans quel délai une équipe réagira-t-elle si le système tombe en panne ?  Quelles promesses peut-on faire concernant la vitesse et la fonctionnalité ? Aussi bien les utilisateurs que les développeurs de la solution veulent pouvoir répondre à ces questions. C’est pourquoi nous avons besoin de définir les SLIs, SLOs et SLAs. 

1. SLI: Service Level Indicator

Les SLIs mesurent des paramètres qui évoluent dans le temps tels que les latences des demandes, le débit, les échecs par demande, pour obtenir un seuil concret. Ce sont des mesures numériques permettant de définir la disponibilité d’une solution technologique.

Le défi des SLIs est de les garder simples, de choisir les bons paramètres à suivre, et de ne pas compliquer le travail des équipes IT en suivant trop de paramètres qui ne sont pas pertinents pour les clients.

Une fois les SLIs bien définis, ils deviennent des SLOs.

2. SLO: Service Level Objective

Les SLOs sont les objectifs internes qui permettent de tenir les engagements faits aux clients. Ils indiquent aux équipes informatiques et DevOps les résultats qu’elles doivent atteindre et sont définis à partir des SLIs. C’est un instrument de pilotage permettant de garantir et veiller à la qualité globale des systèmes et des services que l’entreprise rend aux utilisateurs. 

Mais pourquoi avoir besoin de fixer des SLOs, alors qu’un service devrait toujours être 100% fiable? Le problème est le suivant : le coût et la complexité technique de la fiabilisation des services augmentent de plus en plus à mesure que l’on se rapproche de la disponibilité à 100 %. C’est pourquoi il est préférable d’annoncer des résultats inférieurs à ce que le service et les équipes IT peuvent délivrer. Avec les SLOs:  “less is more”.

Afin de s’assurer que le service fonctionne à un niveau de fiabilité approprié pour les clients, la collaboration entre le ‘product owner’ et les SREs (Site Reliability Engineering) est primordiale.

Il est vivement conseillé de définir des SLOs simples et précis pour faciliter le travail des ingénieurs. Seuls les paramètres les plus importants doivent être pris en compte pour l’obtention du statut SLA et les objectifs doivent être énoncés dans un langage clair et compréhensible de toutes les parties prenantes. 

3. SLA: Service Level Agreement

Les SLAs sont un accord commercial précisant le niveau d’engagement de service entre les utilisateurs et le fournisseur de service basé sur les SLOs. Ils informent notamment des mesures prises par l’entreprise lorsqu’elle n’atteint pas le niveau de performance attendu. Ces mesures peuvent prendre la forme d’un remboursement ou de crédits gratuits en cas de non-respect de la disponibilité du service.

Cependant, ces accords sont généralement rédigés par des personnes ne faisant pas parties des équipes IT. Il est donc courant que les promesses soient difficiles à mesurer et qu’elles ne soient pas alignées avec les priorités des développements technologiques. 

La solution est assez évidente: les équipes IT et DevOps doivent être impliquées dans la rédaction des SLAs. Plus elles collaborent avec les services légaux et commerciaux pour élaborer les SLAs qui répondent à des scénarios réels, plus les SLAs reflèteront des problématiques essentielles.

4. SLA, SLO,SLI best practices

• Chaque partie de votre accord avec le client -SLAs- doit être conçue en fonction de ce qui compte pour lui. Un incident peut signifier qu’il faut aborder dix éléments différents. Mais pour le client, tout ce qui compte, c’est que le système fonctionne comme prévu. 

• Tous les paramètres ne sont pas essentiels pour le client, ce qui signifie que tous les paramètres ne devraient pas être pris en compte par les SLOs. Engagez-vous à avoir le moins de SLOs possible et concentrez-vous sur ceux qui comptent le plus pour les utilisateurs.

Vos SLAs et SLOs doivent refléter la réalité.

• Intégrez un budget d’erreur. Avoir une marge d’erreur ne protège pas seulement l’entreprise contre les violations de l’accord de niveau de service, mais laisse également de la place à l’agilité: l’équipe peut apporter des changements rapidement et avoir la possibilité d’essayer de nouvelles solutions innovantes. 

• Don’t shoot for the moon. Ce n’est pas parce que votre équipe peut probablement maintenir un temps de disponibilité de 99,99% que cela signifie que 99,99% doit être SLO. Il est toujours préférable de promettre ce qui est possible et de délivrer l’impossible.

5. Comment cela impacte-t-il les SREs?

Les équipes SREs font le lien entre les DevOps et les équipes opérationnelles. Les SLAs aident les équipes à fixer des limites et des budgets d’erreur. Les SLOs aident à établir des priorités de travail. Et les SLIs indiquent aux SREs quand ils doivent geler tous les lancements pour sauver un budget d’erreur en danger ou au contraire quand ils peuvent innover. 

Pour résumer:

Ces trois outils intéressent aussi bien les product managers que les product Devs, les SREs, les exécutifs et les clients. 

Ces concepts permettent ainsi de développer une approche centrée sur les utilisateurs car ils: 

• Mesurent efficacement, 
• Fixent des objectifs réalistes, 
• Permettent de communiquer et de prendre les bonnes décisions.

Maintenant à vous de jouer! Reliez la définition au bon terme 🙂 : 

PacketAI is the world’s first autonomous monitoring solution built for the modern age. Our solution has been developed after 5 years of intensive research in French & Canadian laboratories and we are backed by leading VC’s. To know more, book a free demo and get started today!

Follow @PacketSAS on Twitter or PacketAI Company page on LinkedIn to get the latest news!