SLA, SLO et SLI : quelle est la différence ?

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.

Pour de nombreux partenaires, la solution consiste en premier lieu à impliquer les équipes technologiques dans la rédaction des SLA. Plus les services informatiques et DevOps collaborent avec les équipes juridiques et commerciales pour créer des SLA d'après des scénarios réels, plus les SLA prennent en compte des réalités essentielles, comme des clients qui freinent la résolution de leur ticket.

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).

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.

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.

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

Just because your team can probably maintain 99.99% uptime doesn’t mean that 99.99% should be your SLO number. It’s always better to under-promise and overdeliver. This is especially true for agile teams who want to launch early and often and need an error budget to keep up that quick pace.

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.

Maîtrisez les SLA pour résoudre les demandes en fonction des priorités et utilisez des règles de remontée automatisées pour avertir les membres de l'équipe concernés et éviter toute violation des SLA grâce à Jira Service Management.