Comprendre les SLO pour surveiller les applications

Pour gérer correctement et suivre une application, vous avez besoin d’un objectif pour spécifier où vous êtes et comment vous le faites afin que vous puissiez changer et vous améliorer dans le temps. Ce point de recommandation est appelé objectif de niveau de service (SLO). Prendre le temps de définir des SLO clairs facilitera la vie des propriétaires de services ainsi que des utilisateurs internes ou externes qui dépendent de vos services.

Avant de pouvoir spécifier un SLO, vous avez besoin d’une métrique quantitative objective que vous pouvez consulter pour identifier les performances ou la fiabilité de votre application. Ces métriques sont appelées signes de niveau de service (SLI).

Indication de niveau de service– SLI

Un Un excellent moyen d’identifier les métriques que vous devez utiliser pour vos SLI est de réfléchir à ce qui a un impact direct sur la joie de votre utilisateur en ce qui concerne l’efficacité de votre application. Cela peut comprendre des éléments tels que la latence, le calendrier et la précision de l’application. D’un autre côté, l’utilisation du processeur serait un mauvais SLI car vos utilisateurs ne se soucient pas vraiment de l’état du processeur de votre serveur, tant que cela n’affecte pas leur expérience avec votre application.

En outre , les SLI que vous sélectionnez dépendent du type d’application que vous exécutez. Pour une application de type demande/réponse courante, vous vous concentrerez probablement sur la disponibilité, la latence de la demande et les demandes réussies par deuxième capacité. Vous pouvez consulter le calendrier et la cohérence des données fournies pour le stockage des informations. Pour un pipeline d’informations, vos SLI peuvent être de savoir si les données attendues sont renvoyées et combien de temps il considère que les informations doivent être traitées, en particulier dans une conception de cohérence ultime.

Objectif de niveau de service– SLO

Un SLO est une limite d’efficacité déterminée pour un SLI sur une période de temps. Il s’agit de la barre par rapport à laquelle le SLI est mesuré pour identifier si les performances répondent aux attentes. Un bon SLO spécifiera le niveau d’efficacité requis par votre application, mais pas plus que nécessaire. Ceci est un point critique et nécessitera un certain dépistage avec le temps. Si vos utilisateurs sont doués avec une accessibilité de 99 %, il n’y a aucune raison de faire l’énorme investissement qui serait nécessaire pour atteindre une disponibilité de 99,999 %.

Certains exemples de SLO pour la latence pourraient être les latences du 95e centile, ce qui indiquerait vous la latence pour les 5 % des demandes les plus lentes des utilisateurs. C’est bien mieux que de simples moyennes de latence qui pourraient être facilement faussées par des valeurs aberrantes.

Un autre choix pour fournir encore plus de granularité serait de mesurer le nombre total de demandes et la variété de demandes prenant plus qu’un raisonnable limite comme une seconde. Le pourcentage de demandes dépassant votre référence aidera à déterminer la fréquence à laquelle vos utilisateurs attendent avec impatience le retour des données, l’affichage d’une page ou la fin d’une action.

Une fois que vous avez défini votre objectif de performance raisonnable, vous devez déterminer la durée que vous utiliserez pour la mesure. Deux périodes courantes pour les SLO sont des procédures basées sur un calendrier d’une date fixe à une autre date comme le début et la fin d’un mois. L’autre style est une fenêtre glissante qui rappelle la date actuelle par un nombre de jours défini.

Accord de niveau de service — QUARTIER DÉCROCHÉ

Un accord de niveau de service (SLA) est simplement un SLO avec un accord supplémentaire entre l’entreprise et le consommateur qui développe une sorte d’effets si un SLO n’est pas atteint. Cela se produit normalement entre 2 entreprises différentes en tant que fournisseur et client, avec des conséquences financières en cas de violation du SLA. Un quartier délabré peut également être utilisé à l’intérieur d’une entreprise où des services particuliers peuvent dépendre d’autres services gérés par différentes équipes pour que le produit fonctionne.

Pourquoi utiliser des SLO ?

Maintenant que vous avez une bonne compréhension de ce que sont les objectifs de niveau de service, vous vous demandez peut-être pourquoi vous devez prendre le temps de les créer et de les utiliser. La raison la plus apparente est que faire l’effort de découvrir ce qui compte réellement en matière d’efficacité peut simplifier la vie de votre équipe et révéler clairement vos normes dans l’ensemble de l’entreprise. Il existe des milliers de méthodes différentes pour suivre les métriques produites par vos applications, mais si vous les décomposez en ce qui a en fait une influence visible sur les utilisateurs, vous pouvez éliminer une grande partie des interruptions et du bruit.

Chez InfluxData, nous nous concentrons sur les données de séries chronologiques. En conséquence, nous avons de grandes quantités d’informations couvrant une myriade d’éléments de nos systèmes. Bien qu’il y ait une valeur opérationnelle dans les métriques hautement granulaires, ces métriques ne parlaient pas bien de l’expérience du consommateur et laissaient définitivement les propriétaires de services en redemander. Nous avons donc adopté la méthode consistant à examiner chaque microservice et ses clients, en établissant des critères de réussite abordables et des objectifs réalisables.

Les résultats obtenus sont des mesures cohérentes que nous pouvons utiliser sur l’ensemble de notre flotte, fournissant un aperçu du calendrier et taux d’erreur qui sert de proxy à l’expérience client. Cela est non seulement utile pour les propriétaires de services comme moyen d’atteindre la qualité opérationnelle et de notifier les budgets d’erreurs, mais cela permet également d’avoir un aperçu de notre organisation d’ingénierie pour tous les niveaux d’activité.

C’étaient les objectifs derrière le tableau de bord ci-dessous pour un service que nous gérons. Vous verrez qu’il est facile à comprendre en un coup d’œil, offre des mesures importantes qui peuvent être utilisées pour l’information et la budgétisation des erreurs, et montre que ce service a un objectif d’accessibilité de 99,9 %. En offrant ces informations dans l’ensemble de l’entreprise, nous pouvons accélérer la prestation de services. À son tour, cela conduit à un « temps jusqu’à remarquable » à grande vitesse pour les clients qui développent leurs applications sur notre plate-forme.

InfluxData

Une chose essentielle à noter est que les SLO n’ont pas besoin d’être les meilleurs du premier coup. la mise en oeuvre. Un SLO est toujours un travail de développement qui peut être répété à mesure que vous obtenez plus de données et en savoir plus sur les besoins et les attentes des utilisateurs. N’oubliez pas que l’aspect le plus précieux de la mise en œuvre des SLO est le changement d’état d’esprit de base dans la surveillance de vos applications.

Tim Yocum est directeur des opérations chez InfluxData, où il est responsable de l’ingénierie de la fiabilité du site Web et des opérations pour l’infrastructure multi-cloud d’InfluxData. Il a en effet occupé des fonctions de direction dans des startups et des entreprises au cours des 20 dernières années, mettant en évidence le facteur humain dans l’excellence du groupe SRE.

— Nouveau

Tech Online offre un emplacement pour découvrir et discuter des technologies d’entreprise émergentes avec une profondeur et une ampleur inégalées. La sélection est subjective, basée sur notre sélection d’innovations que nous jugeons essentielles et présentant le plus d’intérêt pour les lecteurs d’InfoWorld. InfoWorld décline la sécurité marketing pour la publication et se réserve le droit de modifier tout le contenu contribué. Envoyez toutes vos questions à newtechforum@infoworld.com.