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.

Noces rebelles – les origines du DevOps

DevOps est un ensemble de pratiques qui combinent le Développement (Dev) et les Opérations informatique (Ops). Il s’agit avant tout d’une culture issue de la fusion de principes de management, du développement traditionnel de logiciels, de processus de gestion d’infrastructure et d’outils qui augmentent la capacité d’une organisation à fournir à un rythme intense des applications et des services.
Faire travailler ensemble tous les services IT, est un concept qui peut sembler évident. Mais la réalité s’avère plus complexe à mettre en place pour une raison, elle, très simple : traditionnellement, Devs et Ops fonctionnent chacun en silos et ont des rôles et objectifs diamétralement opposés. Plus simplement, le DevOps est né de la volonté de réconcilier ces deux camps devenus opposés. Pour mieux comprendre il faut déconstruire cette tragédie en 3 actes, menant à la rupture Dev/Ops.

Des problèmes systémiques

Pour comprendre la notion même de DevOps, il faut remonter un peu dans le temps. Traditionnellement, l’organisation des services IT privilégiait une approche fonctionnelle, organisant les équipes en fonction de leurs spécialités – les administrateurs de bases de données, les administrateurs réseaux, les administrateurs serveurs, les Développeurs etc. Chacun dans des groupes différents, et pour rajouter à la difficulté, chacun ayant des objectifs diamétralement opposés.

Devs

Les développeurs se concentrent sur la réalisation des besoins de l’entreprise en matière de nouvelles caractéristiques et fonctionnalités ainsi que sur leur mise en production le plus rapidement possible.

Ops

Les opérations informatiques ont pour mission de fournir à leurs clients un service informatique à la fois stable, fiable et sécurisé, et par conséquent, cherche à tout prix à éviter l’introduction de changements susceptibles de mettre en péril la production.

Le drame

Commence ici le drame classique, une structure en 3 actes.

Acte 1 – l’exposition (Set Up)

La scène commence au sein des Ops, occupé à maintenir les applications et infrastructure pour s’assurer que l’organisation continue à délivrer de la valeur à leurs clients. La routine consiste à devoir régler les problèmes dû à la complexité des applications, à la dette technique et aux hacks quotidiens. Bien sûre, la promesse est faite de régler le problème plus tard, quand la charge de travail s’allègera…

Acte 2 – Confrontation (confrontation)

Evidemment, les artefacts les plus fragiles, car les plus sujets à modification lourdes et toujours urgentes, sont aussi ceux supportant généralement les projets les plus critiques ou les systèmes apportant le plus de revenues. Et là, c’est le drame. Un bug, un système down, des retards, un problème de sécurité. Et pendant que les équipes Ops s’affairent à résoudre le problème, un Product Manager ou un CEO, un Commercial, arrive avec une idée lumineuse pour une nouvelle fonctionnalité qui résoudra sûrement tous les problèmes préexistant (peu importe la difficulté ou la faisabilité technique). Entre à nouveau en scène les Devs qui vont devoir trouver une solution rapide pour créer cette nouvelle fonctionnalité, relever les défis techniques et parfois prendre des raccourcis pour respecter les deadlines. Et le cycle continue…

Acte 3 – Dénouement – Résolution (climax)

Pas de dénouement heureux ici, le cycle fini par aboutir logiquement à des cycles de livraison rallongés, des résultats de déploiements moins fiable, des pannes, une plus grande résistance des Ops à tout changement, le traitement des feedbacks interne et externe se ralenti… Finalement toute l’entreprise perd de sa compétitivité et les équipes IT qui se sentent coincé dans un système qui prédispose à l’échec dans lequel ils se sentent impuissant et non reconnu. Demandez à n’importe quel administrateur système ce qu’il pense des joies du déploiement du vendredi soir, qui force toutes les équipes à travailler tout le weekend.

Epilogue – Calms down

Au cours de la dernière décennie, les évolutions technologiques et la transformation numérique ont impacté toutes les entreprises. La transformation numérique est pilotée par les interactions avec les clients, les partenaires et les fournisseurs, qui évoluent toujours plus vers le numérique. De nos jours, « Chaque entreprise est une entreprise technologique » et les application et infrastructure sont devenues des facteurs stratégiques clés de différenciation des entreprises.
Autant dire que les enjeux et la pression auxquels sont confrontés les équipes IT est immense.
Et là, entre le DevOps ! L’idée apparait pour la première fois en 2008 de la rencontre d’Andrew Shafer (software Développer) et Patrick Debois (sysadmin) à une session devenue célèbre de la conférence Agile de Toronto : Birds of Feathers. Fini les équipes de Développement et d’exploitation « cloisonnées », souvent fusionnées en une seule équipe où les ingénieurs travaillent ensemble du cycle de vie (build – test – release).
Au fil des années sont aussi apparus des Frameworks regroupant les principes de base du DevOps : CALMS, The Three Ways, Accelerate.

Rework

Dans le domaine du développement de logiciels, le Rework est une source de tension et de gaspillage bien connue causée par des problèmes de qualité qui entraînent des défauts et la reprise du code.
L’approche DevOps se concentre sur la collaboration et la qualité. La mise en œuvre de feedbacks rapides et précis au moyen d’un CI (Continuous Improvement) efficace avec des tests automatisés de type « build-acceptance » – combinant différents types de tests, unitaires, fonctionnels, d’intégration et de bout en bout – réduira le nombre de défauts échappés. La qualité du code et le temps de disponibilité du service sont des mesures dont toute l’organisation devrait se préoccuper et aucune équipe ne devrait être récompensée pour avoir terminé plus tôt si la qualité est médiocre.

Transfert / Motion

En ce qui concerne le gaspillage des transferts, le problème provient d’un trop grand nombre de dépendances entre les individus – par exemple, pour approuver une tâche ou accepter des modifications. Pour résoudre ce problème, les équipes DevOps doivent éliminer les silos autant que possible.
Les équipes peuvent utiliser le regroupement d’équipes cross-fonctionnelles pour résoudre ce problème. Par exemple, les développeurs peuvent travailler en binôme avec les testeurs pour approuver des éléments en cours d’exécution plutôt qu’en cours de route. L’intégration continue (CI) est un autre moyen de résoudre le problème du gaspillage des transferts : la mise en place d’un processus de CI unique pour couvrir les différents aspects de la validation doit servir de véhicule pour la livraison des logiciels entre les différents membres de l’équipe.

Processus supplémentaire / Overengineering 

Il s’agit probablement du type de gaspillage le plus facile à résoudre et le plus sous-estimé. Ce type de gaspillage consiste à consacrer trop d’efforts à des choses qui ne sont pas vraiment nécessaires. Il s’agit par exemple d’investir du temps et des ressources dans des éléments qui ne sont pas essentiels à la fonctionnalité ou au système, ou prévoir comme procédure d’onboarding de l’équipe de réapprendre le code hérité et non documenté. Pour éviter cela, concentrez-vous sur les fonctionnalités clés qui apportent la valeur ajoutée nécessaire par le biais d’user stories claires.
Un lien plus étroit entre la gestion de produit et le développement permet aux équipes de savoir ce qui est nécessaire et quand s’arrêter. À la place des Product Managers ou des Business Analystes qui écrivent des spécifications de 150 pages et les jettent par-dessus le mur aux développeurs, il est plus judicieux que ces équipes s’appuient sur une compréhension approfondie du domaine d’activité pour élaborer des user stories initiales avec lesquelles les développeurs peuvent commencer à travailler au lieu d’attendre qu’une spécification parfaite soit complétée.

Inventaire

Dans une usine, un inventaire est constitué de tous les travaux en cours (WIP) et des produits finis qui attendent les commandes des clients sur les étagères [Push]. Dans le cadre de DevOps, l’inventaire est constitué de tous les travaux partiellement réalisés. Un exemple d’inventaire WIP est le backlog des tickets ouverts. Ce travail en cours peut être en suspens, en attente d’informations ou tout simplement dans la file d’attente. Le gaspillage associé à l’inventaire est constitué par les coûts de redémarrage associés à la reprise d’un travail partiellement achevé, au temps nécessaire à sa gestion et aux retards dans la découverte des problèmes de qualité.

 Changement de tâche

Il s’agit du basculement contextuel des tâches qui ralentit l’ensemble du processus de développement et de livraison de logiciels et qui entraîne un épuisement mental résultant des actions (répétitives) infligées par le processus. Cela inclut le changement de tâches ou de responsabilités ou la gestion de ressources éloignées ou inaccessibles. La réponse à de meilleurs processus réside dans la gestion des gaspillages de transfert et d’inventaire, ainsi que dans l’attribution d’un environnement et d’outils efficaces, qui aideront les équipes à mieux collaborer et communiquer.

Temps mort / Waiting

Celui-ci est facile à identifier : l’attente d’une réponse à une question spécifique à propos d’un produit de la part des clients, ou d’environnements prêts et à jour.
Le modèle DevOps y contribue, car il s’agit d’une question d’efficacité. Les équipes peuvent partager le même système de tickets afin qu’une équipe de développement puisse immédiatement commencer à travailler sur un défaut dès qu’il a été enregistré par l’équipe de Support Technique. Cette approche est également axée sur la responsabilisation et l’autonomie des équipes, qui peuvent agir sur les tâches qui le nécessitent au lieu d’attendre quelqu’un.
Par exemple, les mises à jour d’environnement ou la mise en place d’une infrastructure en tant que code (IaC) pour soutenir la création d’environnements DevOps. Contrairement à la mise en place d’un environnement traditionnel qui comprend la configuration du réseau, des machines virtuelles, etc., l’IaC génère automatiquement l’environnement requis à la demande.

Surproduction / Overproduction

La surproduction consiste à fabriquer un produit en quantité supérieure à celle qui peut être vendue, par exemple lorsque l’entreprise dépasse les commandes des clients ou continue à fabriquer un produit même si les ventes diminuent.
Dans le domaine du développement de logiciels, le gaspillage lié à la surproduction résulte du développement de fonctionnalités et de solutions qui ne seront jamais utilisées.
Pour y remédier, il convient de concentrer le développement logiciel uniquement sur les bonnes user stories à développer, clairement rattachées à des epics, des initiatives, des thèmes, etc. Des révisions appropriées et fréquentes au sein de l’équipe chargée des fonctionnalités permettent d’identifier les écarts par rapport au scope défini et aident les membres de l’équipe à rester dans les bonnes voies de livraison.
Dans le Lean et le DevOps, l’objectif ultime est de fournir ce dont le client a besoin, quand il en a besoin. Si l’équipe de test est occupée à écrire des scripts inutiles simplement parce qu’elle s’ennuie en attendant un code à tester, c’est le signe que vous avez un problème. Il y a probablement un goulot d’étranglement ou une contrainte qui bloque le flux et vous oblige à surproduire dans un domaine pour compenser. Dans un autre exemple, envisagez de provisionner des environnements d’application et de demander délibérément plus de capacité que nécessaire, juste pour éviter de revenir en arrière et d’en redemander plus tard. Dans un environnement Cloud, ce type de surproduction n’est pas nécessaire. Au lieu de produire une capacité supérieure à celle demandée, vous pouvez acquérir et payer exactement ce dont vous avez besoin.

Conclusion

DevOps est plus qu’une technologie, c’est avant tout une culture et un état d’esprit. Il n’existe pas de solution unique pour tout. C’est à chaque organisation d’identifier ses propres ralentissements. Comprendre et mettre un nom sur les différents gaspillages au sein d’un processus peut vous aider à appliquer le bon type d’amélioration (continue) à apporter. L’amélioration peut porter sur les personnes, les processus, la technologie ou une combinaison des trois. Le cloud en lui-même ne permet pas de rationaliser une organisation si des changements de processus (et de culture) correspondants ne l’accompagnent pas. Vous devez apprendre à « voir le système » et à reconnaître où se trouvent les contraintes et les gaspillages et à les remédier.