Indicateurs de niveau de service (SLI) et objectifs de niveau de service (SLO)
Dans ce module, nous avons jusqu’à présent découvert comment améliorer notre sensibilisation opérationnelle, développer notre compréhension et notre cadrage de la fiabilité, ainsi qu’abordé les outils Azure Monitor nécessaires pour notre travail. Nous allons à présent découvrir l’une des idées essentielles de ce module, ainsi que les processus permettant de l’implémenter.
Essayons de répondre à la question « comment utiliser tout cela pour améliorer la fiabilité de mon organisation ? »
Abordons la boucle de commentaires
Voici la grande idée qui peut débloquer la situation pour nous :
Les bonnes boucles de commentaires améliorent la fiabilité de votre organisation.
L’amélioration de la fiabilité dans votre organisation est un processus itératif. Dans cette leçon, nous allons aborder une pratique très efficace du monde de l’ingénierie pour la fiabilité des sites afin de créer et d’entretenir le type de boucle de commentaires dans une organisation qui permet d’améliorer la fiabilité. Au minimum, cela engendrera des conversations concrètes dans votre organisation à propos de la fiabilité basée sur des données objectives.
Plus haut dans ce module, nous avons évoqué cela comme une définition de l’ingénierie de la fiabilité du site :
L’ingénierie de fiabilité de site est une discipline d’ingénierie ayant pour vocation d’aider une organisation à atteindre durablement le niveau de fiabilité approprié dans ses systèmes, produits et services.
C’est ici que le concept de niveau de fiabilité approprié entre en jeu.
Indicateur de niveau de service (SLI)
Les indicateurs de niveau de service sont liés à notre précédente discussion sur une compréhension étendue de la fiabilité. Vous vous souvenez de ce diagramme ?
Les indicateurs SLI spécifient la manière dont nous allons mesurer la fiabilité de notre système. Quel est l’indicateur indiquant que notre service se comporte de manière fiable (comme nous nous y attendons) ? Que pouvons-nous mesurer pour répondre à cela ?
Exemple : disponibilité et latence du serveur web
Imaginons que nous utilisons un serveur web et ses données de disponibilité. Il peut être intéressant de connaître le nombre de requêtes HTTP reçues et le nombre de requêtes HTTP bien traitées par le serveur. Nous souhaitons plus précisément comprendre le niveau de réussite du serveur web grâce au rapport entre les requêtes réussies et le nombre total de requêtes.
Si nous divisons le nombre de requêtes réussies par le nombre total de requêtes, nous obtenons un rapport. Nous pouvons multiplier ce taux par 100 pour obtenir un pourcentage. Pour prendre un exemple avec des valeurs arrondies, si notre serveur web a reçu 100 requêtes et a répondu correctement à 80 d’entre elles, nous aurions un rapport de 0,8. Multipliez ce rapport par 100 et nous pouvons indiquer que le serveur a été à 80 % disponible.
Essayons avec autre chose. Indiquons cette fois une mesure associée à la latence de notre service web. Il peut être intéressant de connaître le rapport entre le nombre d’opérations terminées en moins de 10 millisecondes et le nombre total d’opérations. Effectuons les mêmes calculs : pour 80 requêtes sur 100 terminées plus rapidement que notre seuil, nous calculons à nouveau un taux de 0,8. Multipliez cette valeur par 100. Nous pouvons affirmer que nous avons respecté à 80 % les exigences de latence en ce qui concerne cette mesure.
Petite précision : cela ne concerne pas uniquement les sites web. Si nous choisissons un service de pipeline qui traite des données, nous pouvons mesurer la couverture (par exemple la quantité de données que nous avons traitées). Les systèmes sont très différents, mais les calculs de base restent identiques.
SLI : où mesurer
Pour que les indicateurs SLI soient utiles dans des discussions concrètes basées sur des données objectives, un autre élément doit être spécifié en plus des mesures. Quand nous créons un indicateur SLI, nous devons noter non seulement ce qui est mesuré, mais également où la mesure est effectuée.
Par exemple, lorsque nous avons spécifié ce que nous mesurions la disponibilité du serveur web mentionné précédemment, nous n’avons pas indiqué où nous récupérions les nombres de requêtes HTTP totales et réussies. Si vous discutez de la fiabilité de ce serveur web avec des collègues en examinant les statistiques de requête collectées au niveau d’un équilibreur de charge en amont du serveur, alors que vos collègues examinent les statistiques du serveur lui-même, la conversation risque de ne pas être très fructueuse. Les chiffres peuvent être radicalement différents, car l’équilibreur de charge peut voir toutes les requêtes entrantes du réseau, mais s’il existe un problème au niveau du réseau ou de l’équilibreur de charge lui-même, toutes les requêtes n’atteindront pas nécessairement le serveur. Nous tirons donc des conclusions en nous basant sur deux jeux de données différents.
Le moyen le plus simple de remédier à ce problème est de spécifier la source des données dans l’indicateur SLI. Pour le serveur web, nous indiquons « le rapport entre les requêtes réussies et le total, mesuré au niveau de l’équilibreur de charge » pour la disponibilité. Pour la latence, on peut indiquer « le taux représentant le rapport entre le nombre d’opérations terminées en moins de 10 millisecondes et le nombre total d’opérations, tel que mesuré au niveau du client ».
Une question logique se pose : quel est le meilleur emplacement pour mesurer les indicateurs SLI ? Malheureusement, il n’existe pas de « bonne » réponse universelle. C’est une décision que vous devez prendre en sachant que vous devez faire des compromis dans tous les cas. L’un des conseils que nous pouvons donner se rapporte à notre discussion précédente sur la fiabilité : essayez d’effectuer les mesures à l’emplacement qui reflète le plus précisément l’expérience de vos clients.
Objectifs de niveau de service (SLO)
Le choix de la mesure (et de l’emplacement de mesure) est un excellent point de départ, mais cela ne constitue que la moitié de notre objectif. Imaginons que nous récupérons les mesures nécessaires pour l’indicateur SLI de disponibilité de notre serveur web et que nous constatons qu’il est à 80 % disponible.
S’agit-il d’un bon ou d’un mauvais chiffre ? Est-ce le « niveau de fiabilité approprié » ?
Pour répondre à ces questions, nous devons définir un objectif pour cet indicateur SLI : un objectif de niveau de service (SLO, Service Level Objective). Cet objectif indique clairement l’objectif de ce service.
La recette de base pour la création d’un SLO est constituée de ces ingrédients :
L’« élément » que vous allez mesurer : nombre de requêtes, contrôles de stockage, opérations ; l’objet de la mesure.
La proportion souhaitée : par exemple, « réussite 50 % du temps », « lecture possible 99,9 % du temps », « retour en moins de 10 ms 90 % du temps ».
Plage de temps : quelle est la période prise en compte pour l’objectif : les 10 dernières minutes, le dernier trimestre, un cycle de 30 jours ? Les objectifs SLO sont plus souvent spécifiés sur une fenêtre dynamique plutôt qu’une unité de calendrier, comme « un mois », pour nous permettre de comparer des données de différentes périodes.
En associant ces composants, ainsi que les informations sur l’emplacement de la mesure, un objectif SLO peut se présenter comme suit :
« 90 % des requêtes HTTP rapportées par l’équilibreur de charge ont réussi dans la dernière fenêtre de 30 jours. »
De la même manière, un SLO de base mesurant la latence peut se présenter comme suit :
Comme signalé par le client, 90 % des requêtes HTTP ont été renvoyées en moins de 20 ms dans la fenêtre des 30 derniers jours.
Commencez avec des objectifs simples et de base comme ceux-ci lorsque vous appliquez la pratique dans votre organisation. Vous pouvez créer des objectifs plus complexes ultérieurement si nécessaire.
SLI et SLO sur Azure Monitor
Pour finir, voyons comment nous pouvons représenter un SLI/SLO simple dans Azure Monitor à l’aide de Log Analytics. Pour poursuivre dans la même lignée, revenons à l’exemple du serveur web.
Nous avons découvert dans la dernière unité que nous pouvions créer des requêtes dans Log Analytics en utilisant le langage de requête Kusto (KQL). Voici une requête KQL qui affiche un SLI de disponibilité pour un service web :
requests
| where timestamp > ago(30d)
| summarize succeed = count (success == true), failed = count (success == false), total = count() by bin(timestamp, 5m)
| extend SLI = succeed * 100.00 / total
| project SLI, timestamp
| render timechart
Comme précédemment, nous commençons par spécifier la source des données : la table requests. Nous allons ensuite affiner les données utilisées pour sélectionner les informations des 30 derniers jours. Nous collectons ensuite le nombre de requêtes réussies, le nombre de requêtes ayant échoué et le nombre total de requêtes (par intervalles de cinq minutes). L’indicateur SLI est créé à l’aide de formules mathématiques simples comme nous l’avons vu précédemment. Nous indiquons à KQL que nous souhaitons tracer cet indicateur SLI avec des horodateurs, puis nous créons un graphique de ce type :
À présent, nous allons nous pencher sur une représentation simple d’un SLO :
requests
| where timestamp > ago(5h)
| summarize succeed = count (success == true), failed = count (success == false), total = count() by bin(timestamp, 5m)
| extend SLI = succeed * 100.00 / total
| extend SLO = 80.0
| project SLI, timestamp, SLO
| render timechart
Deux lignes ont été modifiées dans cet exemple par rapport au précédent. La première définit le nombre utilisé pour l’objectif SLO. La seconde indique à KQL que l’objectif SLO doit être inclus dans le graphique. Le résultat ressemble à ceci :
Sur ce graphique, il est facile de déterminer les périodes au cours desquelles notre objectif de disponibilité n’est pas atteint.
Utilisation de SLI/SLO
Vous devez systématiquement procéder à un réglage des indicateurs SLI et des objectifs SLO (en effet, il s’agit d’un processus itératif). Mais une fois ces opérations effectuées, que faire des informations ?
Bonne nouvelle : vous allez probablement remarquer que le simple fait d’établir des indicateurs SLI et des objectifs SLO a des effets positifs sur l’organisation. Cela nécessite des discussions avec les parties prenantes et d’autres communications qui orientent les choses dans le bon sens. Les discussions suivantes sur ce qu’il convient de faire pourront également être utiles.
En fin de compte, les SLI et les SLO sont des outils de planification du travail. Ils peuvent vous aider à prendre des décisions en matière d’ingénierie, comme « devrions-nous travailler sur de nouvelles fonctionnalités pour le service ou devons-nous au contraire nous concentrer sur sa fiabilité ? ». Ils peuvent vous aider lors des boucles de commentaires que nous avons abordées précédemment.
Une utilisation secondaire mais assez courante pour les SLI et SLO s’inscrit dans le cadre d’un système de supervision/réponse plus immédiat. En plus de l’aspect de planification du travail (sur lequel vous devez vous concentrer en premier), de nombreuses personnes les utilisent comme des signaux d’alerte pour l’exploitation. Certains peuvent par exemple choisir d’alerter le personnel si le service reste en dessous de l’objectif SLO pendant une période prolongée. Ce type d’alerte nous amène à notre prochaine unité dans ce module.