Back to top icon

Mesures DevOps

Même si le DevOps peut sembler être une simple intégration de deux rôles fonctionnels, la mesure des résultats d’une nouvelle initiative DevOps n’est pas toujours simple. Essentiellement, vous créez de nouvelles équipes avec de nouvelles responsabilités et cela peut accroître les risques et la frustration si vous ne gérez pas bien les choses.


C’est pour cela qu’il est crucial d’avoir une visibilité de bout en bout pour les applications, l’infrastructure, la fiabilité et la santé de l’équipe dans votre environnement DevOps. En partageant des indicateurs clés de performances avec tous les acteurs de votre entreprise numérique, vous permettez à chacun de suivre vos efforts DevOps et d’en prouver la réussite à chaque étape. Les leaders peuvent voir si tout le monde est sur la même longueur d’onde et partage les mêmes objectifs. Et les informations partagées permettent aux coéquipiers de collaborer plus facilement et plus rapidement.


Que mesurer

Pour que votre initiative DevOps soit vraiment un succès, vous devez accroître la rapidité et l’agilité de vos équipes afin de fournir des logiciels fiables et performants offrant une expérience client supérieure plus vite et plus fréquemment. Pour atteindre ces objectifs DevOps, il est essentiel de consulter et de partager des données historiques et en temps réel portant sur l’ensemble de la pile technologique, des performances de l’infrastructure et des applications à la fiabilité et la santé des équipes.    

Vous pouvez mesurer de nombreux indicateurs pour suivre votre parcours DevOps, mais commencez par les 17 que nous vous présentons ci-dessous et vous serez sur la bonne voie. Nous les avons regroupés en trois domaines fonctionnels clés :

  1. Mesures DevOps portant sur la santé élémentaire des applications et de l’infrastructure
  2. Mesures DevOps portant sur la fiabilité et la santé du système 
  3. Mesures portant sur les opérations DevOps et la santé de l’équipe DevOps 

Notez que l’ordre dans lequel la liste est organisée n’implique pas de séquence spécifique. Les mesures sont présentées des plus générales aux plus spécifiques et une initiative DevOps bien préparée doit suivre les indicateurs de ces trois groupes.

Mesures DevOps portant sur la santé élémentaire des applications et de l’infrastructure

Les équipes DevOps travaillent sans relâche pour repérer rapidement les problèmes, si possible avant qu’ils se manifestent et affectent les clients. Pour ce faire, ces équipes suivent et surveillent divers indicateurs clés des performances des applications et de l’infrastructure. Ces indicateurs sont pertinents pour les développeurs logiciels et les ingénieurs des opérations des organisations DevOps.

Apdex

Le score Apdex permet de mesurer la satisfaction de vos clients quant aux temps de réponses de vos services et de vos applications Web. Plus précisément, il mesure le rapport entre les temps de réponse satisfaisants et les pires temps de réponse. Le temps de réponse commence quand le client envoie une demande et prend fin quand la demande est terminée.

Pour mesurer le score Apdex d’une application, commencez par définir un seuil de temps de réponse en fonction des références de performances dans votre application, T.

Apdex suit et comptabilise trois types de réponses à trois niveaux différents :

  1. Satisfaisant : le temps de réponse est inférieur ou égal à T.

  2. Tolérable : le temps de réponse est supérieur à T mais inférieur ou égal à 4T.

  3. Frustrant : le temps de réponse est supérieur à 4T.

Par exemple, si T est égal à 1,2 seconde et si une réponse est fournie en 0,5 seconde, le temps de réponse est satisfaisant. On considère qu’avec un temps de réponse supérieur à 1,2 seconde, l’utilisateur n’est pas satisfait, et s’il dépasse 4,8 secondes, il est frustré.

Pour en savoir plus au sujet du suivi de cet indicateur, regardez ces vidéos, Comprendre Apdex et Apdex : comment mesurer la satisfaction des utilisateurs.

Temps de réponse moyen

Le temps de réponse est le temps qu’il faut à une application pour traiter une transaction. Cette mesure est un bon indicateur de l’expérience de vos clients sur votre site Web. Il est important de la tester à plusieurs endroits et avec les principaux types d’interactions que vos utilisateurs ont avec votre site Web ou votre application (par exemple, une demande de connexion aura des temps de réponse différents qu’un téléchargement de fichier, et vous devez vous assurer que ces deux opérations ont des temps de réponse acceptables pour ce type d’interaction).

Dans New Relic, la page d’aperçu par défaut d’APM montre le temps de réponse moyen pour toutes vos applications dans le graphique temporel des transactions Web. Vous pouvez aussi rédiger une requête NRQL pour créer un widget New Relic Insights et suivre le temps de réponse moyen de chaque application.

Si vous voulez connaître le temps de réponse moyen de votre application pendant une période donnée, vous pouvez utiliser New Relic API Explorer (v2).

Pourcentage d’utilisation de l’unité centrale

L’utilisation de l’unité centrale est une mesure critique pour suivre la disponibilité de votre application. Dans un environnement sur site, quand l’utilisation de l’unité centrale augmente, les performances de votre application risquent de se dégrader et l’expérience client peut en pâtir. Cependant, pour une utilisation générale dans le cloud, si vous ne maximisez pas l’utilisation de l’unité centrale, vous ne profitez probablement pas des ressources pour lesquelles vous payez. Dans New Relic APM, le pourcentage d’utilisation de l’unité centrale mesure l’utilisation globale de l’unité centrale pour toutes les instances de votre application ou de votre service sur un serveur donné. Dans New Relic Infrastructure, il s’agit d’une mesure du pourcentage d’utilisation de l’unité centrale par hôte ou par processus. L’indicateur de pourcentage d’utilisation de l’unité centrale est recueilli par défaut et s’affiche dans New Relic Infrastructure dans un graphique des performances de l’hôte.

Vous pouvez aussi utiliser l’API REST New Relic (v2) afin d’obtenir l’utilisation moyenne de l’unité centrale pour votre application sur un seul hôte.

Taux d’erreur

En général, vous devriez considérer toute exception non gérée comme une erreur. Un indicateur du taux d’erreur suit le pourcentage de transactions débouchant sur une erreur pendant une période donnée. Par exemple, si pendant une période spécifique, votre application traite 1 000 transactions et que 50 d’entre elles renvoient une exception non gérée, votre taux d’erreur est de 50/1 000, soit 5 %.

New Relic fournit différentes façons de suivre les taux d’erreur, notamment le graphique de taux d’erreur APM et les analyses des erreurs JavaScript de New Relic Browser.

Charge moyenne

Utilisez cet indicateur pour mesurer le nombre moyen de processus, threads ou tâches système qui sont en attente et prêts pour l’unité centrale. Le suivi de la charge moyenne peut vous aider à savoir si votre système est surchargé ou si vous avez des processus qui consomment trop de ressources. Avec New Relic Infrastructure, vous pouvez suivre la charge moyenne par intervalles de 1, 5 ou 15 minutes. Les données s’affichent à la page des hôtes de New Relic Infrastructure.

Pourcentage d’utilisation de la mémoire

Une utilisation de mémoire excessive sur un hôte peut déboucher sur de mauvaises performances des applications, alors qu’une utilisation de mémoire constamment trop faible peut indiquer que vous n’exploitez pas des ressources coûteuses, en particulier dans le cloud.

Le pourcentage d’utilisation de la mémoire compare le nombre d’octets de mémoire libres au nombre d’octets de mémoire utilisés pour chaque hôte de votre infrastructure. L’indicateur de pourcentage d’utilisation de la mémoire est recueilli par défaut et s’affiche dans New Relic Infrastructure dans un graphique des performances de l’hôte.

Vous pouvez aussi utiliser l’API REST New Relic (v2) afin d’obtenir l’utilisation moyenne de la mémoire pour votre application sur un seul hôte.

Débit

Le débit est une mesure de l’activité des utilisateurs pour une application surveillée. Dans New Relic APM, le débit suit les requêtes par minute (RPM) envoyées à votre application. Le suivi du débit peut vous aider à déterminer, par exemple, si une nouvelle fonctionnalité, une amélioration ou une modification de l’architecture change la façon dont votre application traite les requêtes.

Vous pouvez aussi utiliser l’API REST New Relic (v2) afin d’obtenir le débit moyen pour votre application, y compris le débit des applications Web ou non. Ces valeurs s’affichent dans le graphique de débit de la page d’aperçu de votre application dans APM.

Mesures DevOps portant sur la fiabilité et la santé du système

Les équipes DevOps peuvent suivre la fiabilité, la qualité et la santé globale du système à l’aide de quelques indicateurs clés. Dans les organisations DevOps, les ingénieurs chargés de la fiabilité du site, les ingénieurs des opérations, les développeurs logiciels, les chefs de projet et les responsables de l’ingénierie profiteront tous de ces mesures.

Indicateurs de défauts

Les indicateurs de taux de défauts permettent de suivre le nombre de problèmes ou de bugs signalés pour vos logiciels en production ou les problèmes qui surviennent pendant leur déploiement. Il peut s’agir de problèmes d’infrastructure, d’application, d’application mobile ou de navigateur. Le suivi de ces défauts s’effectue généralement sous la forme de tickets de bug ou d’assistance.

Vous pouvez intégrer New Relic à un système de suivi des bugs, comme Atlassian JIRA, Lighthouse ou Pivotal Tracker pour rapidement créer des tickets, des dossiers ou des histoires pour les problèmes de performances que vous découvrez dans New Relic.  

Temps moyen de détection

Cet indicateur suit le temps qui s’écoule entre le début d’un problème et sa détection, moment auquel, idéalement, sont prises des mesures. Les équipes DevOps doivent tout faire pour que leur temps moyen de détection soit le plus court possible. Si toutes vos équipes disposent des bons instruments, des bonnes alertes et des bons canaux de notification, vous pourrez réagir plus rapidement quand une erreur est détectée.  

Attention, le temps moyen de détection n’inclut pas le temps nécessaire à la résolution du problème.

Utilisez les alertes New Relic et définissez vos conditions et vos politiques d’alertes de façon à ce que les développeurs, le personnel des opérations et les propriétaires de logiciels soient toujours mis au courant en cas de problème et puissent ainsi agir sans délai. Pour des alertes encore plus efficaces, associez-les à des solutions de notification comme Slack ou PagerDuty, qui peuvent contribuer aux communications aux fins de détection d’erreurs et de prévention des problèmes.

Délai moyen de résolution

Le délai moyen de résolution suit le temps moyen nécessaire pour réparer un composant défaillant dans votre système, de la détection de la panne au moment où le système recommence à fonctionner normalement. Utilisez cet indicateur pour mesurer et améliorer les mécanismes de communication de votre processus de récupération. Quand vous avez des canaux de communication directs, les correctifs peuvent être identifiés, validés et déployés plus vite, ce qui minimise les temps d’indisponibilité du système.

Par exemple, New Relic Infrastructure recueille des indicateurs en temps réel pour vous aider à réduire votre délai moyen de résolution en mettant en relation les changements dans les performances de l’hôte aux changements de configuration de votre infrastructure. Configurez les alertes New Relic pour les indicateurs d’Infrastructure que vous recueillez afin d’être mis au courant des problèmes potentiels avant qu’ils n’affectent vos systèmes.

Accords sur les niveaux de service (SLA)

Que vous gériez une simple équipe de développement ou toute une organisation, les accords sur les niveaux de service sont le contrat (qui a parfois une valeur légale) passé entre vous et vos utilisateurs ou clients.

Plusieurs des mesures et indicateurs abordés dans ce guide devraient être intégrés aux accords sur les niveaux de service, comme l’Apdex et le délai de réponse moyen. New Relic APM fournit des rapports SLA qui suivent les indisponibilités et les tendances des applications dans le temps pour vous aider à mieux comprendre les performances de vos applications. Vous pouvez aussi obtenir des rapports SLA pour les transactions clés dans APM et pour les moniteurs Synthetics.

Objectifs de niveau de service (SLO)

Les SLO sont les objectifs que fixent vos équipes au sujet de ce que vous, et vos clients, pouvez attendre de votre système en termes de disponibilité, de performances, de taux d’erreur et de tout autre facteur que vous décidez de mesurer. Vos objectifs de niveau de service doivent refléter ce que votre équipe s’engage à prendre en charge, ce que votre organisation s’engage à prendre en charge et ce que vous pouvez prendre en charge de façon réaliste d’un point de vue technique. Un exemple d’objectif de niveau de service pour une équipe qui fournit un service API pourrait être d’accepter 99,99 % des charges bien formées.

Bien sûr, vos objectifs de niveau de service peuvent évoluer. Par exemple, si votre système est relativement jeune, vous devriez envisager de commencer avec des SLO modestes, puis de les accroître au fil du temps.

New Relic est un excellent moyen pour vos équipes de mesurer les indicateurs de santé élémentaires de vos applications et de votre infrastructure par rapport à des SLO couvrant le pourcentage d’utilisation de l’unité centrale, la disponibilité, le taux d’erreurs, le délai moyen de réponse, etc.

Mesures DevOps portant sur la santé de l’équipe

Les organisations DevOps efficaces ne se contentent pas de suivre les indicateurs techniques, elles analysent aussi les mesures de santé et de performances des équipes. Ces mesures sont particulièrement importantes pour les développeurs de logiciels, les ingénieurs des opérations, les chefs de projet et les responsables de l’ingénierie des organisations DevOps.

Validations du code

En suivant les validations d’un artefact effectuées par une équipe au cours du cycle de développement avant que cet artefact ne puisse être déployé dans l’environnement de production, cet indicateur peut être représentatif de la rapidité de l’équipe et de la qualité du code. Trop, ou pas assez, de validations peuvent indiquer que les membres de l’équipe ne gèrent pas bien le projet. Par exemple, un grand nombre de validations peut indiquer que les membres de l’équipe ne savent pas vraiment comment s’y prendre pour résoudre un problème et qu’ils avancent à tâtons. Un nombre de validations insuffisant peut indiquer qu’ils sont distraits par d’autres obligations.

Dans New Relic, vous pouvez utiliser l’API Insights pour créer un événement personnalisé pour chaque validation GIT, la suivre à l’aide d’une requête NRQL et afficher les résultats dans un tableau de bord. En outre, vous pouvez suivre les validations en enregistrant les déploiements avec l’ API Rest New Relic v2.

Délai et fréquence de déploiement

Une itération rapide et une livraison continue (en gros, le temps qu’il vous faut pour déployer vos logiciels et la fréquence à laquelle vous les déployez) sont souvent considérées comme des indicateurs clés de la réussite DevOps. Les experts DevOps comme Gene Kim, coauteur de DevOps Handbook, pensent que ces indicateurs ont un rapport étroit avec des résultats positifs pour les organisations DevOps.

Avec l’API Rest New Relic v2, vous pouvez enregistrer les nouveaux déploiements, récupérer une liste des déploiements précédents et supprimer les anciens déploiements. Certains agents ont aussi des méthodes qui leur sont spécifiques pour enregistrer les déploiements automatiquement. Une fois les déploiements enregistrés, vous pouvez les voir à la page des déploiements APM et dans la liste des événements récents de la page d’aperçu. La page des déploiements de New Relic APM répertorie les déploiements récents et leur impact sur les scores Apdex, les temps de réponse, le débit et les erreurs de vos utilisateurs et de votre serveur d’applications. Vous pouvez afficher et explorer des détails, utiliser les options de recherche et de tri, masquer ou supprimer l’erreur, la partager avec d’autres ou envoyer un ticket à ce sujet.

Durée d’itération

Utilisez cet indicateur pour suivre le temps écoulé entre les cycles de développement pendant l’exécution d’un projet. Dans les workflows agiles modernes, les cycles de développement durent généralement une ou deux semaines, et chaque cycle est ponctué d’étapes de préparation et de rétrospectives. (L’équipe peut être à même ou non d’avoir un artefact prêt au déploiement après chaque cycle.) Le suivi de la durée d’itération peut vous aider à mieux comprendre les changements de la portée du projet, la rapidité et la charge de travail de l’équipe, et votre capacité à vous adapter aux changements au fil de l’évolution du projet.

Réussite/échec des tests d’unité

Une unité est le plus petit composant de votre logiciel pouvant être testé. Le suivi du nombre de tests d’unité qui se soldent par une réussite ou un échec pendant un cycle de développement est un indicateur de la qualité du code que rédigent vos équipes.

Par exemple, si vous utilisez PHPUnit pour gérer et exécuter vos tests d’unité, l’agent New Relic PHP peut automatiquement capturer le récapitulatif des résultats du test et l’envoyer à Insights sous la forme d’un événement, vous permettant d’interroger et de visualiser les données de test en un coup d’œil.

Une autre approche consiste à utiliser une requête NRQL pour créer un widget de tableau de bord pour suivre les tests d’unité s’étant soldés par une réussite/un échec.

Délai d’exécution du projet

Parfois appelé délai moyen de changement, cet indicateur capture le temps écoulé du début d’un projet au déploiement de l’artefact de ce projet dans l’environnement de production. Cela peut vous aider à mesurer la capacité de votre équipe à s’adapter aux changements au fil de l’évolution de votre entreprise.

Vous pouvez notamment suivre le délai d’exécution du projet en utilisant l’API Insights pour créer un événement personnalisé pour chaque validation GIT, puis en créant un widget de tableau de bord à l’aide d’une requête NRQL. 

Prêt à mesurer votre parcours DevOps ?

Où que vous soyez dans votre transition DevOps (que vous soyez tout juste en train de commencer, ayez mené à bien de petits projets pilotes ou soyez à la tête d’une initiative DevOps complète), la plateforme New Relic peut vous aider à suivre vos progrès et optimiser vos efforts DevOps. Pour en savoir plus, consultez nos guides sur l’évaluation de la réussite DevOps, une série de didacticiels qui expliquent comment utiliser New Relic pour mesurer votre parcours DevOps.


 

 

Vos outils DevOps modernes

New Relic n’est qu’une des nombreuses technologies clés dont vous aurez besoin dans le cadre de vos efforts DevOps.

Afficher les outils >

ARTICLE

Présentation du guide New Relic sur l’évaluation de la réussite DevOps

eBook

Sans mesures, une initiative DevOps est vouée à l’échec : comment mesurer et suivre les 5 facteurs clés de la réussite DevOps

ARTICLE

Tableaux de bord DevOps : exemples de ce qu’il faut mesurer

Étude de cas

Riskified comprend l’étendue et la propagation des fraudes dans le secteur du commerce électronique grâce à New Relic