Les métriques DevOps

Découvrir les différents métriques DevOps

DevOps est certes une histoire de culture, facilitée par la mise en place de « best practices » et d’outils appropriés. Cette démarche vise à améliorer la conception de produits et services logiciels, grâce à des feedbacks régulier et du contrôle continu. Mais pour s’assurer de l’efficacité de cette démarche, il vaut mieux savoir quelles métriques évaluer.

Métriques d’incidents

MTT-R Mean Time to R-

Commençons par le métrique qui est sans doute le  plus délicat. En effet le MTTR peut représenter 4 mesures différentes puisque le R peut signifier « repair », « recovery », « respond » ou « resolve » et bien que ces mesures puissent sembler proches, elles ont chacun leurs significations proches.
Il est donc important pour cette mesure précise, d’avoir bien intégré le principe de communication mis en avant par le DevOps est de clarifier de quel MTTR il s’agit. Avant de commencer à évaluer votre MTTR, vos équipes doivent être d’accord sur ce qui va être suivi et s’assurer que chacun parle de la même chose.

Mean Time to Repair

Le MTTR (mean time to repair) est le temps moyen nécessaire pour réparer un système. Le MTTR est une mesure critique de la maintenabilité des systèmes, qu’il s’agisse d’applications ou d’infrastructures. Le MTTR est la valeur qui est utilisée pour vérifier l’efficacité de la réparation de ces systèmes lorsqu’un incident informatique se produit. Le MTTR est d’autant plus précieux que près de 90% du MTTR de réparation est dédié à l’identification du problème.

Calcul du temps moyen de réparation
Le MTTR s’obtient en additionnant le temps total consacré aux réparations pendant une période donnée, puis en divisant ce temps par le nombre de réparations.

Mean time to recovery – Temps moyen de récupération

Dans les indicateurs DevOps, le MTTR (mean time to recovery) est le délai moyen de récupération après une défaillance produit ou système.
Il couvre toute la durée de la panne, depuis le moment où le système ou le système tombe en panne jusqu’au moment où il est à nouveau totalement opérationnel.

Calcul du temps moyen de rétablissement

Le délai moyen de rétablissement est calculé en additionnant tous les temps d’arrêt pendant une période spécifique et en le divisant par le nombre d’incidents.
Il est généralement mesuré en heures et peut se référer aux heures ouvrables, et non aux heures d’horloge.

Mean time to Resolve – Temps moyen de resolution

Le MTTR (mean time to resolve) est le délai moyen entre la détection d’un incident et le moment où le système ou le composant concernés sont de nouveau disponibles pour les utilisateurs.  Cela englobe le temps nécessaire pour détecter la panne, diagnostiquer le problème et le réparer, mais aussi le temps passé à faire en sorte que la panne ne se reproduise pas. Cet indicateur est fortement corrélé à la satisfaction client.

Calcul du délai moyen de résolution

Pour calculer ce MTTR, il faut additionner le temps total de résolution pendant une période donnée et le diviser par le nombre d’incidents.

Mean time to respond – Temps moyen de réponse

Le MTTR (mean time to respond) est le temps moyen nécessaire pour se remettre d’une panne de produit ou de système à partir du moment où vous êtes alerté pour la première fois de cette panne. Ce délai n’inclut pas le temps de latence de votre système d’alerte. Le temps moyen de réponse est utile en cybersécurité, associé au MTTD (Mean Time to Detect).

Calcul du temps moyen de réponse

Pour calculer ce temps moyen de réponse, il faut additionner le temps de réponse complet entre l’alerte et le moment où le service ou le produit est à nouveau pleinement fonctionnel. Divisez ensuite par le nombre d’incidents.

MTTD – Mean Time to Detect

Le MTTD est le temps moyen qu’il faut aux équipes pour identifier les problèmes. C’est une métrique très importante à surveiller en matière de cybersécurité.

Calcul du Mean Time to Detect
Pour trouver le MTTD, il suffit d’additionner tous les temps de détection des incidents pour le membre de l’équipe ou la période donnée et de diviser par le nombre d’incidents.

Taux d’échappement des bugs

Il est évident que, dans un monde idéal, tous les bugs sont trouvés pendant la phase de test sur le serveur de développement. Cependant, dans la vie réelle, et parce que DevOps vise à livrer du code rapidement, il est important de suivre cette métrique pour minimiser le nombre et la gravité des défauts qui arrivent en production.

Le pourcentage de défauts critiques et échappés est un KPI important, il garantit que l’équipe et ses efforts de test se concentrent sur la rectification des problèmes et des défauts critiques du produit, ce qui les aide à assurer la qualité de l’ensemble du processus de test ainsi que du produit.

Métriques de fiabilité et de maintenance

MTBF – Mean time between failures – Temps moyen entre les défaillances

Le MTBF (mean time between failures) désigne le temps moyen entre les pannes d’un système. Cette mesure est utilisée pour suivre à la fois la disponibilité et la fiabilité d’un produit. Le MTBF est une mesure de maintenance incontournable pour évaluer les performances, la sécurité des actifs critiques ou complexes. Il s’agit de l’un des rares KPI qui se doivent d’être augmenté : plus le temps entre les défaillances est élevé, plus le système est fiable.

Calcul du temps moyen entre les défaillances

Il s’agit de la somme des heures d’Uptime selon une période diviser par le nombre de défaillances survenues au cours de cette même période. Le MTBF est généralement mesuré en heures, mais si vous avez la chance de pouvoir la mesurer en jours : Félicitations !

MTTF – Mean Time to Failure ou Temps moyen avant défaillances

Cette métrique est souvent confondue et employée de manière interchangeable avec le temps moyen entre les défaillances (MTBF).
La principale différence entre MTBF et MTTF est que le MTTF concerne les équipements non réparables, alors que le MTBF s’applique aux systèmes réparables.
Les logiciels peuvent être réparés et subiront de multiples défaillances au cours de leur durée de vie, et auront donc des périodes de temps entre les défaillances, alors que les éléments non réparables, tels que les disques SSD, fonctionneront correctement pendant un certain temps avant de tomber définitivement en panne, et n’auront donc qu’une seule défaillance au cours de leur durée de vie.

Comment calculer le MTTF

Pour calculer le MTTF, il faut diviser le nombre total d’heures de fonctionnement par le nombre total de ressources utilisées. Le MTTF représente le temps moyen avant défaillance.

Test automatisé (%)

DevOps se base en grande partie sur l’automatisation, par conséquent le suivi de l’efficacité de vos tests automatisés est important.
Cette métrique compte le nombre de tests automatisés effectués pour un build donné. Cependant, cette mesure ne prend pas en compte la redondance, l’efficacité ou la variabilité des tests.
Cette mesure va au-delà du simple décompte du nombre de tests automatisés et aide à définir clairement les risques métiers. Grâce à cette mesure, ils peuvent concentrer leurs efforts d’automatisation des tests sur les tests qui comptent le plus pour l’entreprise.

Métriques de Déploiement

Lead Time for changes

Il s’agit d’un indicateur important qui permet dans le cadre du modèle DevOps puisqu’il permet de déterminer l’efficacité des processus. La philosophie DevOps implique de déployer des « small batches » code fréquemment, c’est pourquoi il est important d’évaluer le temps nécessaire pour implémenter, tester et livrer le code. Pour cela il faut deux données importantes : le moment où le commit a eu lieu et celui où le code a été déployé.

Fréquence de déploiement

Il s’agit du nombre de déploiements de logiciels sur une période donnée. Attention, cette mesure concerne les performances techniques du pipeline de déploiement, et non la fréquence de livraison, en effet tous les déploiements ne sont pas poussés en production. Il peut être mesuré de différentes manières, notamment par des pipelines de déploiement automatisés, des appels API et des scripts manuels.

Taux de stabilité des déploiements

Tout déploiement qui peut causer des problèmes ou des défaillances pour vos utilisateurs est considéré comme un échec. La stabilité des déploiements est le pourcentage de temps pendant lequel le dépôt le plus récent pour un repository donné a réussi.

Bien sûr, les équipes DevOps sont censées intégrer la qualité dans le produit dès le début du projet, mais des échecs et des erreurs peuvent survenir. Les « builds » cassés ne sont pas tous dus à des erreurs de code ; il peut s’agir d’un problème d’infrastructure qui doit être résolu. Cela devient un problème lorsque ces erreurs persistent pendant une longue période et commencent à nuire à la productivité des développeurs.

Ce nombre doit être aussi bas que possible : 0 étant le nombre magique, moins de 5% d’échecs de déploiement est considéré comme acceptable.

Métriques de services

Volume des tickets

Le volume de tickets ou le nombre total de tickets permet de suivre tous les tickets dans votre file d’attente de support sur une période donnée. Les bogues et les erreurs peuvent parfois passer outre la phase de test et être détectés par l’utilisateur final, ce qui entraîne l’ouverture d’un nouveau ticket.
Le nombre de tickets clients signalés comme des « problèmes » ou des bugs est un indicateur majeur de la fiabilité de l’application. Un grand nombre de tickets indique des problèmes de qualité, tandis qu’un petit nombre indique la robustesse de l’application. En d’autres termes, ce chiffre est une mesure de la satisfaction de l’utilisateur final.
Une variante de cette mesure est le nombre total de conversations qui comptabilise tous les échanges avec les clients, que ce soit par le biais d’un ticket de support officiel, des réseaux sociaux ou de tout autre canal.

Utilisation des applications et de trafic

À l’issue d’un déploiement, il convient de vérifier le niveau d’utilisation des applications ou de contrôler si le nombre de transactions ou d’utilisateurs accédant au système paraît normal. Si tout à coup le trafic est nul ou présente un pic de trafic (si vous utilisez des microservices), il y a un problème.