La différence entre les SLOs, les SLIs, et les SLAs
Comme nous l'avons mentionné précédemment, les ingénieurs chargés de la fiabilité des sites utilisent trois paramètres pour surveiller et mesurer les performances des systèmes informatiques et, en définitive, accroître leur fiabilité : Ils rédigent des contrats de niveau de service (SLA), des indicateurs de niveau de service (SLI) et des objectifs de niveau de service (SLO). Ces paramètres de niveau de service connexes aident non seulement les entreprises à créer un système plus fiable, mais aussi à gagner la confiance des clients.
Découvrez ce que ces différents concepts signifient dans la pratique, comment ils dépendent les uns des autres et pourquoi ils sont si importants pour une ingénierie de fiabilité des sites réussie.
Que sont les SLI ?
SLI signifie indicateur de niveau de service. Le manuel SRE de Google le définit comme « une mesure quantitative soigneusement définie de certains aspects du niveau de service fourni ». Autrement dit, les SLI servent à mesurer les caractéristiques d'un service pour en tirer des enseignements pour l'objectif d'un fournisseur de services.
Les SLI centrés sur le produit évaluent les comportements qui ont un impact important sur l'expérience client. En fait, il existe quatre signaux d'or utilisés comme les SLI les plus courants : latence, trafic, taux d'erreur et saturation.
Lorsque les équipes SRE mettent en place des SLI pour mesurer un service, elles les définissent généralement en deux étapes.
- elles déterminent les SLI qui ont un impact direct sur les clients.
- elles déterminent les SLI qui ont une influence directe sur la disponibilité ou la latence, ou la performance du service.
La formule utilisée pour calculer les SLI est la suivante SLI = bons évènements * 100 / évènements valides – une valeur SLI de 100 est idéale, tandis qu'une chute à 0 signifie qu'un système est en panne.
Il est important de créer des SLI qui correspondent au parcours des utilisateurs. En d’autres termes, un seul SLI ne peut pas faire état de l'ensemble de l'expérience du client, car un utilisateur type peut se préoccuper de plusieurs choses lorsqu'il utilise le service. En même temps, il n'est pas conseillé de créer des SLI pour chaque mesure possible, car vous perdriez de vue ce qui est vraiment important.
En règle générale, les ingénieurs chargés de la fiabilité des sites essaient de trouver les points de douleur les plus importants tout au long du parcours de l'utilisateur, qui pourraient ensuite conduire à une refonte totale du système.
Une fois les SLI configurés, un SRE les relie aux SLO, qui sont des valeurs seuils clés par rapport à chaque SLI quantifiant la disponibilité et la qualité du service.
Que sont les SLO ?
Les SLO ou objectifs de niveau de service sont utilisés comme une mesure objective pour les objectifs de fiabilité ou de performance d'un service. Le manuel SRE de Google indique qu'ils « précisent un niveau cible pour la fiabilité de votre service » et « parce que les SLO sont essentiels pour prendre des décisions fondées sur des données en matière de fiabilité, ils sont au cœur des pratiques SRE ».
Alors que les SLI sont axés sur le produit, les SLO sont axés sur le client. Les SLO sont mesurés par les SLI, les deux ont donc une dépendance complexe. La structure naturelle de leur relation est définie comme suit : Limite inférieure des SLO ≤ SLI ≤ Limite supérieure des SLO.
Cependant, choisir les bons SLO est une tâche complexe. En général, les objectifs ne doivent pas être basés sur les performances actuelles, mais sur les performances historiques du système. Parfois, les équipes SRE commettent également l'erreur de viser la perfection en fixant des objectifs beaucoup trop élevés. Il n'est pas non plus nécessaire de préciser des valeurs absolues. Cependant, il est bon de garder une marge de sécurité dans les SLO en fixant une moyenne historique. Lorsque vous adoptez des SLO, il est important de commencer lentement et d’avancer progressivement, car leur adoption nécessite un changement culturel.
Les SLO doivent être considérés comme un outil d’harmonisation qui crée un langage commun et des objectifs partagés par les différentes équipes. Et vous avez beaucoup plus de chances de réussir si toutes les parties prenantes clés sont impliquées. Cependant, de nombreuses entreprises se concentrent sur l'innovation des produits et ne saisissent pas le lien entre la performance de l’entreprise et la fiabilité. Les obstacles les plus courants sont le cloisonnement des données et l'idée fausse selon laquelle les SLO ne nécessiteraient aucune réévaluation ni aucun réajustement une fois créés.
Que sont les SLA ?
Les SLA ou contrats de niveau de service sont des contrats sur la disponibilité et la performance des services. Tout comme les SLO, les SLA sont une mesure centrée sur le client. Dans le manuel SRE de Google, un SLA est défini comme « un contrat explicite ou implicite avec vos utilisateurs qui indique ce qu’il se passe si les niveaux de service en question sont atteints (ou pas) ».
Un SLA entre en vigueur dès qu'un SLO échoue. En général, vous pouvez vous attendre à des pénalités et à des sanctions financières en cas de non-respect des résultats escomptés. Si votre entreprise ne respecte pas une condition convenue dans le contrat de niveau de service, elle doit généralement rembourser ses clients.
Les SLA favorisent la transparence et la confiance entre le service et ses utilisateurs. D'une certaine manière, ils ressemblent beaucoup aux SLO, mais pour un usage externe et non interne. Par rapport aux SLO, les SLA ne sont pas aussi conservateurs, ce qui signifie que la valeur de la fiabilité est toujours légèrement inférieure à la moyenne historique d'un SLO de disponibilité. Cela peut être considéré comme une mesure de sécurité dans le cas où la moyenne serait trop élevée en raison de la rareté des incidents.
En conclusion, les ingénieurs chargés de la fiabilité des sites doivent travailler avec ces trois paramètres pour créer une infrastructure stable et fiable. Après avoir collecté les SLI (les métriques dans le système de surveillance), ils définissent les seuils de ces métriques sur la base des SLO internes afin de prévenir une violation des SLA externes.
La différence entre l’ingénierie en fiabilité des sites et l’ingénierie de plateforme
Les ingénieurs chargés de la fiabilité des sites et les ingénieurs de plate-forme ont des rôles très similaires et des objectifs qui se chevauchent. Dans les petites entreprises, il est même possible que les deux soient interchangeables. Toutefois, à mesure que le nombre de développeurs augmente, la frontière entre les équipes SRE et les équipes chargées des plateformes devient un peu moins floue.
En effet, un ingénieur de plate-forme se concentre davantage sur l'optimisation du flux de travail en déployant certains composants d'infrastructure. Ainsi, les ingénieurs produits peuvent concevoir et livrer des applications plus rapidement. Afin d'éviter les goulets d'étranglement, les ingénieurs de plate-forme doivent également recalibrer les flux de travail existants et s'assurer que les bonnes personnes peuvent y accéder.
Un ingénieur en fiabilité de site s'intéresse quant à lui à la santé globale d'un système, en mesurant sa fiabilité et en fixant des objectifs de fiabilité (SLO).
L'étroite collaboration de ces deux équipes avec les équipes de développement, d'exploitation et d'assistance permet d'obtenir d’améliorer les produits, d’accélérer les livraisons, de réduire les incidents et de rendre les développeurs et les clients plus heureux.
Les avantages de l’ingénierie en fiabilité de sites
Il ne fait aucun doute que l'adoption d'une culture DevOps aide les équipes d'ingénieurs à collaborer de manière plus productive et à livrer des logiciels beaucoup plus rapidement. Cependant, cela n'augmente pas nécessairement la fiabilité et les performances du site. C'est pourquoi de nombreuses entreprises cherchent à pourvoir des postes de SRE. Mais comment votre entreprise peut-elle tirer parti de l'ingénierie de la fiabilité des sites au juste ? Voici les 6 arguments les plus convaincants qui plaident en faveur du recrutement d'une équipe SRE.
- Amélioration des rapports sur les indicateurs : Les SRE apportent plus de clarté en contrôlant et en mesurant la productivité, la santé du service et l'apparition de bugs. Ils sont capables de traduire les mesures en éléments tangibles (comme la durée moyenne des temps d'arrêt) et leur relation avec la perte de revenus pour l'entreprise. Une fois que les domaines d'amélioration sont exposés, il est plus facile de les aborder avec des solutions appropriées.
- Dépannage proactif : de nombreuses entreprises se concentrent sur l'innovation et le déploiement de nouvelles fonctionnalités pour rester en tête. Cependant, un développement et une livraison rapides accentuent également les risques de bogues et de vulnérabilités non détectées. Comme les SRE travaillent de manière proactive, ils peuvent trouver et résoudre les problèmes avant qu'ils n'atteignent l'utilisateur final, ce qui permet à l'entreprise d'économiser du temps et de l'argent.
- Plus de temps pour créer de la valeur : travailler avec un système plus fiable et ne pas avoir à résoudre les problèmes une fois qu'ils ont atteint l'utilisateur final permet de libérer du temps pour les équipes de développement, qui peuvent donc se concentrer sur la création de nouvelles fonctionnalités. Et le fait que les SRE détectent les problèmes potentiels signifie que les développeurs peuvent les résoudre à l'avance et obtenir de meilleurs résultats.
- Amélioration culturelle : l'ingénierie de la fiabilité des sites permet de surveiller en permanence la santé du système et ses vulnérabilités. Le processus de recherche continue des meilleures solutions génère des avantages pour les équipes, les départements et les services et encourage la collaboration. Ce sens partagé de la responsabilité améliore non seulement la culture d'entreprise mais aussi le produit lui-même.
- Automatisation accrue : un ingénieur chargé de la fiabilité des sites cherchera toujours le meilleur moyen de moderniser et d'automatiser les flux de travail des ingénieurs produits. Cependant, ils améliorent également leur propre flux de travail pour détecter les vulnérabilités des systèmes à l’aide d’outils et de systèmes d'alerte modernes. Cela réduit le temps nécessaire pour trouver, mettre en évidence et réparer les bogues. Ainsi, au fil du temps, le système devient de plus en plus fiable grâce à l'automatisation.
- Répondre aux attentes des clients : alors que DevOps se préoccupe davantage des processus internes, les SRE se concentrent sur l'amélioration de l'expérience des clients et des consommateurs. En utilisant des mesures telles que les SLA, SLO et SLI, un ingénieur en fiabilité de site fixe des objectifs clairs pour répondre aux attentes des clients. Il en résultera des produits plus fiables et des améliorations significatives en termes de retour sur investissement.
Conclusion
De nombreuses raisons expliquent pourquoi les entreprises natives de l'informatique dématérialisée ont tout intérêt à recruter un ingénieur en fiabilité des sites ou une équipe SRE complète. Ils constituent un complément précieux à toute culture DevOps, car ils comblent le fossé entre les développeurs et l'infrastructure informatique.
En surveillant et en analysant en permanence les performances des applications, ils détectent les problèmes à un stade précoce du processus et contribuent à la feuille de route globale des produits. De plus, les équipes de développement passent beaucoup moins de temps à traiter les problèmes et peuvent se consacrer davantage à la création de nouvelles fonctionnalités et de nouveaux services.
LeanIX is now part of SAP
En savoir plus
/FR/Poster/FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png?width=360&height=255&name=FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png)
/FR/Poster/FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png?width=500&height=355&name=FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png)
/FR/Poster/FR-Log4j-Use-Case-Thumbnail.png?width=260&height=171&name=FR-Log4j-Use-Case-Thumbnail.png)
/EN/Reports/EN-LX-DevOp-Exp-Survey-Resource-Page-Thumbnail.png?width=260&height=171&name=EN-LX-DevOp-Exp-Survey-Resource-Page-Thumbnail.png)
/FR/Poster/FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png?width=300&name=FR-Cloud-Microservice-Catalog-Poster_Resource_Page_Thumbnail.png)
