Close

Métriques DevOps

Pourquoi et comment mesurer la réussite dans une organisation DevOps

TOM HALL

Expert DevOps


Le vieil adage selon lequel vous ne pouvez pas améliorer ce que vous ne mesurez pas est tout aussi vrai pour DevOps que pour n'importe quelle autre pratique. Afin de tenir la promesse de DevOps (qui consiste à livrer des produits de meilleure qualité, plus rapidement), les équipes doivent collecter, analyser et mesurer de nombreuses métriques. Ces métriques DevOps fournissent les données essentielles dont les équipes DevOps ont besoin pour gagner en visibilité et en contrôle sur leur pipeline de développement.

Quelles sont les métriques DevOps ?


Les métriques DevOps sont des points de données qui révèlent directement les performances d'un pipeline de développement logiciel DevOps, et permettent d'identifier et de supprimer rapidement tout goulot d'étranglement dans le processus. Elles peuvent être utilisées pour suivre à la fois les capacités techniques et les processus de l'équipe.

DevOps cherche essentiellement à estomper les frontières entre les équipes de développement et opérationnelles, ce qui favorise la collaboration entre les développeurs et les administrateurs système. Les métriques permettent aux équipes DevOps de mesurer et d'évaluer les workflows collaboratifs et de suivre l'avancement vers la réalisation d'objectifs de haut niveau, notamment une qualité accrue, des cycles de livraison plus rapides et des performances applicatives améliorées.

Les quatre grandes métriques DevOps


Bien que de nombreuses métriques soient utilisées pour mesurer les performances DevOps, voici quatre métriques clés que chaque équipe DevOps doit mesurer.

Délai d'exécution des changements

Le délai d'exécution des changements constitue l'une des principales métriques DevOps à suivre. À ne pas confondre avec la durée de cycle (abordée ci-dessous), le délai d'exécution des changements désigne le temps écoulé entre le commit d'un changement de code dans la branche « trunk » et le moment où il peut être déployé. Par exemple, lorsque le code réussit tous les tests de versions préliminaires requis.

Taux d'échec des changements

Le taux d'échec des changements correspond au pourcentage de changements de code nécessitant des corrections ou une autre remédiation après la production. Il ne mesure pas les échecs détectés par les tests et corrigés avant le déploiement du code.

Fréquence de déploiement

Il est essentiel de connaître la fréquence de déploiement du nouveau code en production pour comprendre la réussite DevOps. De nombreux experts utilisent le terme « livraison » pour désigner les changements de code livrés dans un environnement de staging de pré-production, et emploient uniquement le terme « déploiement » pour faire référence aux changements de code livrés en production.

Temps moyen jusqu'à la remise en route

Le temps moyen jusqu'à la remise en route (MTTR) mesure le temps nécessaire pour reprendre les activités après une interruption de service partielle ou une panne totale. Il s'agit d'une métrique importante à suivre, que l'interruption soit le résultat d'un déploiement récent ou d'une panne système isolée.

Découvrir la solution

Outils pour une équipe DevOps « de choc »

Matériel connexe

L'importance de la structure d'équipe dans DevOps

Comment mesurer, utiliser et améliorer les métriques DevOps


Comme d'autres éléments du cycle de vie DevOps, une culture d'amélioration continue s'applique aux métriques DevOps. La capacité de recevoir un feedback rapide à chaque phase du développement, associée à la compétence et à l'autorité nécessaires pour implémenter ce feedback, constituent les caractéristiques des équipes ultra performantes. Dans le livre DevOps « Accelerate », les auteurs notent que les quatre principales métriques énumérées ci-dessus sont appuyées par 24 capacités adoptées par les équipes de développement ultra performantes. Nous couvrons la plupart de ces capacités ci-dessous (CI/CD, automatisation des tests, travail par petits lots, surveillance et apprentissage continu), mais il est judicieux de lire « Accelerate » pour approfondir l'étude qui sous-tend ces pratiques.

Délai d'exécution des changements

Les équipes ultra performantes mesurent généralement les délais d'exécution en heures, alors que les équipes moyennement et peu performantes les mesurent en jours, semaines voire mois.

L'automatisation des tests, le SLA de disponibilité et le travail par petits lots sont des éléments clés pour améliorer les délais d'exécution. Ces pratiques permettent aux développeurs de recevoir rapidement un feedback sur la qualité du code qu'ils commitent afin d'identifier et de corriger les défauts éventuels. Les longs délais d'exécution sont presque inévitables si les développeurs effectuent des changements importants sur des branches distinctes et s'appuient sur des tests manuels pour le contrôle qualité.

Taux d'échec des changements

Les équipes ultra performantes affichent des taux d'échec des changements compris entre 0 et 15 %.

Les mêmes pratiques qui permettent de réduire les délais d'exécution (automatisation des tests, SLA de disponibilité et travail par petits lots) sont liées à une réduction des taux d'échec des changements. Toutes ces pratiques facilitent considérablement l'identification et la correction des défauts.

Le suivi des taux d'échec des changements et les rapports associés sont non seulement importants pour identifier et corriger les bugs, mais aussi pour s'assurer que les livraisons d'un nouveau code répondent aux exigences de sécurité.

Fréquence de déploiement

Les équipes ultra performantes peuvent déployer les changements à la demande, ce qui est souvent le cas plusieurs fois par jour. Les équipes peu performantes se limitent souvent à un déploiement hebdomadaire ou mensuel.

La possibilité de déployer à la demande nécessite un pipeline de déploiement automatisé qui intègre les mécanismes de test et de feedback automatisés mentionnés dans les sections précédentes, et réduit le besoin d'intervention humaine.

Temps moyen jusqu'à la remise en route

Les équipes ultra performantes reprennent rapidement leurs activités après une panne système (généralement en moins d'une heure), alors que les équipes peu performantes peuvent avoir besoin d'une semaine.

La possibilité de reprendre rapidement ses activités après une panne dépend de la capacité à identifier rapidement le moment où une panne se produit, à déployer une correction ou à annuler tout changement qui a entraîné la panne. Cette approche implique généralement de surveiller en permanence l'intégrité du système et d'alerter l'équipe opérationnelle en cas de panne. Cette équipe doit disposer des processus, des outils et des autorisations nécessaires pour résoudre les incidents.

Comme l'accent est mis sur le MTTR, on s'éloigne de la pratique historique qui consistait à se focaliser sur l'intervalle moyen entre les défaillances (MTBF). Cette approche reflète la complexité croissante des apps modernes et, par conséquent, accroît la probabilité d'un échec. Elle renforce également la pratique de l'apprentissage et de l'amélioration continus. Au lieu d'attendre que le déploiement soit « parfait » pour éviter tout échec (et donc de réinitialiser l'ancien tableau de bord MTBF), les équipes déploient en continu. Plutôt que de reprocher à quelqu'un d'avoir mis à mal un MTBF qui aurait dû être « parfait », le MTTR favorise les rétrospectives sans reproches pour aider les équipes à améliorer leurs processus et outils en amont.

Autres métriques associées


La durée de cycle est une autre métrique pertinente. Elle correspond au temps qu'une équipe consacre à une tâche jusqu'à ce qu'elle soit prête à être livrée. Dans l'univers du développement, la durée de cycle désigne le temps qui s'écoule entre le moment où les développeurs effectuent un commit et le moment où il est déployé en production. Cette métrique DevOps clé permet aux responsables de projet et d'ingénierie de mieux comprendre ce qui fonctionne bien dans le pipeline de développement. Par conséquent, ils peuvent mieux aligner leur travail sur les attentes des parties prenantes et des clients, ce qui permet à leur équipe de livrer plus rapidement.

Les rapports sur la durée de cycle permettent aux responsables de projet d'établir une base de référence pour le pipeline de développement. Celle-ci peut être utilisée pour évaluer les futurs processus. Lorsque les équipes optimisent la durée de cycle, les développeurs ont généralement moins de travail en cours et moins de workflows inefficaces.

Dans la gestion des produits Lean, l'accent est mis sur la cartographie de la chaîne de valeur (VSM), qui donne un aperçu du flux depuis la conception d'un produit ou d'une fonctionnalité à la livraison. Les métriques DevOps fournissent de nombreux points de données essentiels pour une VSM et une gestion efficaces. Toutefois, elles doivent être complétées par d'autres métriques métier et produit pour permettre une véritable évaluation de bout en bout. Par exemple, les graphiques Burndown de sprint donnent un aperçu de l'efficacité des processus d'estimation et de planification, tandis qu'un Net Promoter Score indique si le livrable final répond aux besoins des clients.

Conclusion…


L'amélioration continue est l'un des principes fondamentaux des équipes qui adoptent les pratiques DevOps. La capacité de mesurer et de suivre les performances sur les délais d'exécution des changements, le taux d'échec des changements, la fréquence de déploiement et le MTTR permet aux équipes d'améliorer la vélocité et la qualité. Découvrez comment Atlassian vous aide à fournir plus rapidement une meilleure valeur ajoutée aux clients grâce à Code in Jira et Déploiements (Deployments) dans Jira.

Tom Hall
Tom Hall

Tom Hall est un expert DevOps, un lecteur avide et un pianiste amateur.
Au cours des 20 dernières années, il a notamment obtenu les certifications Novell, EMC, VMware et AWS. Il a participé à l'organisation des DevOpsDays à Atlanta en 2016 et à Austin, au Texas, dans les années qui ont suivi.


Partager cet article
Thème suivant

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration Devops

Communauté DevOps

Illustration Devops

Atelier de simulation

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter Devops

Thank you for signing up