DevOps et métriques DORA : un guide complet

Pour réussir avec le DevOps, vous devez mesurer la performance de vos initiatives DevOps. Suivez les bonnes métriques pour évaluer l’efficacité de vos pratiques DevOps.

Dans cet article, j’aborde différentes métriques DevOps, leur importance, les objectifs qu’elles permettent d’atteindre et, surtout, des conseils pour améliorer chacune d’entre elles. 

Les métriques DevOps : pourquoi vous ne pouvez pas vous en passer.

Les métriques DevOps sont des données qui permettent de mesurer la performance d’activités et de processus DevOps clés, parmi lesquels :

• l’intégration continue (CI),
• le déploiement continu,
• les tests automatisés,
• la supervision continue.

Ces métriques permettent aux entreprises de suivre leurs progrès : atteignez-vous les objectifs que vous vous êtes fixés ? Les métriques facilitent également l’identification des bottlenecks qui peuvent vous empêcher de maximiser la performance des applications et la productivité des employés dans les processus DevOps. En suivant de près ces indicateurs, vous pourrez apporter les améliorations nécessaires et maximiser votre retour sur investissement.

Pour les besoins de l’article, nous avons réparti ces métriques en différentes catégories :

• les quatre métriques clés de DORA,
• optimisation des tests et de la qualité du code,
• optimisation du déploiement,
• optimisation de l’intégration continue,
• mesure de la satisfaction des clients,
• optimisation des pratiques de supervision.

Métriques DevOps DORA

L’équipe DevOps Research and Assessment (DORA) de Google a mis au point un ensemble de métriques DevOps très utilisé. Au fil des ans, DORA a mis en évidence les critères grâce auxquels les équipes DevOps les plus performantes se démarquent. Ces quatre métriques ont été définies après plus de 7 ans de recherche sur les principes DevOps et leurs applications pratiques. 

Le framework DORA utilise les quatre métriques décrites ci-dessous pour mesurer deux domaines essentiels du DevOps : la vitesse et la stabilité. La fréquence de déploiement et le délai moyen des modifications mesurent la vitesse du DevOps, tandis que le taux d’échec des modifications et le délai de rétablissement du service mesurent sa stabilité. Interprétées ensemble, ces quatre métriques DORA dessinent la base de référence des performances d’une équipe DevOps et donnent des indices sur les points à améliorer.

La section suivante détaille rapidement ces quatre métriques clés, à quoi correspond un bon score et comment les améliorer.

Taux d’échec des modifications (CFR)

Le taux d’échec des modifications est le pourcentage de déploiements qui, une fois en production, provoquent une défaillance exigeant une solution immédiate (dégradation du service, interruption de service, etc.). On cherche à minimiser le taux d’échec des modifications, car plus une équipe passe de temps à résoudre les problèmes, moins elle peut produire de nouvelles fonctionnalités et de la valeur client. Cette métrique est généralement calculée en comptant le nombre de fois qu’un déploiement aboutit à un échec et en divisant ce chiffre par le nombre total de déploiements pour obtenir une moyenne. On ne comptabilise pas les corrections effectuées avant le déploiement en production. Vous pouvez calculer le CFR en comptant le nombre de déploiements ainsi que ceux qui ont fait l’objet de correctifs urgents et d’annulation. Vous pouvez calculer cette métrique comme suit :

(échecs de déploiement/nombre total de déploiements) x 100

Pour le taux d’échec des modifications, les différents niveaux de performance sont :

• Élite : 0 à 15 %
• Haut : 16 à 30 %
• Moyen : 16 à 30 %
• Faible : 16 à 30 %

Cette métrique est un bon indicateur de :

• la qualité de votre code,
• l’efficacité de vos méthodes de test.

Le CFR de votre équipe doit se situer entre 0 et 15 % si vous suivez des pratiques DevOps efficaces. Le déploiement par embranchements, l’automatisation des tests et le développement par petits incréments peuvent vous aider à améliorer cette métrique.

Fréquence de déploiement (Deployment frequency, DF)

La DF mesure la fréquence à laquelle vous déployez des modifications en production. Les équipes les plus performantes déploiement généralement du code en production sur demande, ou plusieurs fois par jour. Des déploiements hebdomadaires ou mensuels vont faire baisser la DF.  

Cette métrique aide les équipes à :

• réagir aux besoins des clients,
• corriger les bugs plus rapidement,
• apporter des modifications aux fonctionnalités existantes,
• réduire les risques associés aux déploiements moins fréquents ou plus vastes.

Pour la fréquence de déploiement, les différents niveaux de performance sont :

• Élite : plusieurs déploiements par jour
• Haut : un déploiement par semaine à un par mois
• Moyen : un déploiement par mois à un tous les six mois
• Faible : moins d’un déploiement tous les six mois

Chaque organisation a sa propre définition d’un déploiement réussi, et la fréquence de déploiement peut même varier d’une équipe à l’autre au sein d’une même organisation.

(Lisez notre guide complet de la fréquence de déploiement.)

Délai de modification (Lead time to changes, LT)

Le délai de modification désigne le temps nécessaire à une validation de code pour être prête à passer en production, une fois tous les tests nécessaires effectués dans l’environnement de pré-production. Le calcul de cet indicateur repose sur les heures de validation du code et de publication. 

Les équipes DevOps avancées comptent leur LT en heures, tandis que les équipes intermédiaires ou peu performantes le comptent en jours, voire en semaines. Pour améliorer le LT, mettez en place des pratiques comme le déploiement par embranchements, travaillez progressivement et automatisez les tests.

Pour le délai moyen des modifications, les différents niveaux de performance sont :

• Élite : moins d’une heure
• Haut : entre un jour et une semaine
• Moyen : entre un mois et six mois
• Faible : plus de six mois

Les processus propres à la culture d’une organisation, comme la séparation de ses équipes de test ou de ses environnements de test partagés, peuvent avoir un impact sur les délais et ralentir les performances d’une équipe.

Temps moyen de rétablissement des services (MTTR)

Le MTTR est le temps nécessaire pour se remettre d’une interruption totale ou partielle des services dans un environnement de production. Les équipes performantes maintiennent un MTTR de moins d’une heure, alors qu’il peut atteindre une semaine chez les équipes en difficulté. Vous pouvez calculer le MTTR en examinant l’heure à laquelle un incident est survenu et le temps nécessaire à sa résolution. 

Le MTTR dépend de la vitesse à laquelle vous pouvez identifier un incident lorsqu’il se produit et déployer une mesure de correction. Vous pouvez améliorer le MTTR en supervisant continuellement les systèmes et les services et en alertant le personnel concerné dès qu’un incident se produit. Cela lui permettra de prendre rapidement des mesures. 

Pour le délai de rétablissement du service, les différents niveaux de performance sont :

• Élite : moins d’une heure
• Haut : moins d’un jour
• Moyen : entre un jour et une semaine
• Faible : plus de six mois

Applications et scénarios d’utilisation des métriques DORA

Dans tous les secteurs ou presque, les entreprises peuvent utiliser les métriques DORA pour mesurer et améliorer leurs performances de développement et de livraison de logiciels. Un développeur de jeux mobiles, par exemple, pourrait utiliser les métriques DORA pour mieux comprendre et optimiser sa réponse en cas de déconnexion du jeu, de façon à minimiser l’insatisfaction des clients et à préserver ses revenus. Une société de services financiers pourra communiquer les bienfaits du DevOps aux acteurs de l’entreprise en traduisant les métriques DORA en dollars économisés grâce à l’accroissement de la productivité et à la réduction des temps d’arrêt.

Avantages et inconvénients des métriques DORA

Les métriques DORA sont très utiles pour quantifier les performances de votre organisation en matière de livraison de logiciel et lui permettre de se comparer aux autres acteurs de son secteur. Les effets potentiels sont multiples :

• Meilleure prise de décision : le suivi constant des métriques DORA aide les organisations à s’appuyer sur des données concrètes pour comprendre l’état actuel de leur processus de développement et prendre des décisions sur l’amélioration. Et comme DORA incite les équipes DevOps à se focaliser sur des indicateurs spécifiques plutôt que de tout superviser, il leur devient plus facile d’identifier les bottlenecks dans leur processus, de concentrer leurs efforts sur leur résolution et de valider les résultats. Une amélioration de la vitesse et de la qualité des livraisons, qui repose sur les données plutôt que sur l’instinct, en découle.
• Valeur accrue : les équipes d’élite et hautement performantes peuvent être sûres d’une chose : elles apportent de la valeur à leurs clients et elles ont un impact positif sur l’entreprise. Les métriques DORA donnent également aux équipes les moins performantes une vision claire des obstacles qui freinent leurs processus et les aident à identifier une marche à suivre pour délivrer davantage de valeur.
• Amélioration continue : les équipes DevOps peuvent comparer leurs performances sur la base des métriques DORA et découvrir quels habitudes, politiques, processus, technologies et autres facteurs entravent leur productivité. Les quatre métriques clés aident l’organisation à se fixer des objectifs pour optimiser les performances de l’équipe et mettent en évidence les moyens les plus efficaces d’y parvenir.

Les métriques DORA peuvent améliorer la prise de décision, la valeur délivrée et les processus en général.

Si les métriques DORA forment un bon point de départ pour évaluer les performances de vos pratiques de livraison de logiciels, elles peuvent aussi présenter certains défis. Les métriques peuvent varier considérablement d’une organisation à l’autre, empêchant d’évaluer avec précision les performances de l’entreprise dans son ensemble et de les comparer aux autres.

Chaque métrique repose généralement également sur la collecte d’informations réparties dans plusieurs outils et applications. Pour déterminer le délai de rétablissement du service, par exemple, vous devrez peut-être recueillir des données auprès de PagerDuty, GitHub et Jira. Et les choses se compliquent encore quand les outils utilisés varient d’une équipe à l’autre.

À chaque métrique DevOps sa fonction

Les métriques DORA nous donnent un bon point de départ. Mais d’autres indicateurs DevOps, plus importants encore, permettent de mesurer le succès des processus DevOps. Nous allons les passer en revue dans les sections suivantes. Nous les avons réparties en différentes catégories : tests et qualité du code, déploiement, intégration continue, satisfaction des clients et pratiques de supervision. 

Métriques d’optimisation des tests et de la qualité du code

Taux de défauts non détectés

Cet indicateur mesure le nombre de défauts qui ont échappé aux tests de plus bas niveau et qui ont été poussés en production. Votre équipe doit s’efforcer de maintenir cette valeur aussi proche de zéro que possible. Un taux de défauts non détectés supérieur indique que vos processus de tests doivent être encore automatisés et améliorés.

Les équipes DevOps devraient détecter au moins 90 % des défauts dans les environnements de pré-production, avant de publier le code. 

Taux d’échec des tests de CI

Cette métrique est un excellent moyen de mesurer la qualité de votre code. Pour la calculer, divisez le nombre de tests qui ont échoué dans le pipeline CI par le nombre total de tests réalisés.

Un taux élevé d’échec de tests de CI indique que votre code doit être amélioré, et doit encourager les développeurs à effectuer leurs propres tests unitaires avant de valider le code. 

Couverture du code

La couverture du code indique la quantité de code testée par la suite de tests automatisés. Généralement, la bonne pratique recommande de maintenir une couverture aussi haute que possible pour détecter rapidement les défauts. Pour autant, un taux de couverture de 100 % n’est pas forcément une garantie de qualité maximale, et peut même indiquer que des tests inutiles sont réalisés.

Métriques d’optimisation du déploiement et des workflows

Temps de cycle 

Le temps de cycle mesure le temps qui s’écoule entre le moment où l’équipe s’attelle à un élément spécifique et celui où il est mis à la disposition des utilisateurs finaux. Pour les équipes de développement, le temps de cycle est celui qui sépare la validation du code et son déploiement en production.

Plus le temps de cycle est long, plus il y a de tâches en cours, et moins les workflows sont efficaces. Les équipes doivent s’efforcer d’optimiser leurs workflows et d’améliorer leur efficacité pour réduire le temps de cycle. 

Taille du déploiement

La taille du déploiement est déterminée par le nombre de fonctionnalités, de scénarios et de correctifs implémentés. Vous pouvez la mesurer en utilisant le nombre de tâches effectuées dans chaque déploiement. Associez cette métrique à d’autres indicateurs comme la fréquence de déploiement et la durée du cycle pour évaluer la productivité de chaque déploiement. 

Temps de déploiement

Le temps de déploiement est la durée nécessaire à la finalisation d’un déploiement. C’est une métrique DevOps utile pour mesurer l’efficacité de vos pipelines de déploiement. Si le temps de déploiement est long, s’il faut plusieurs heures pour effectuer un déploiement, c’est le signe d’un problème potentiel et un facteur de baisse de productivité pour votre équipe de publication.

Vous pouvez améliorer cette métrique en éliminant les étapes superflues du pipeline de déploiement et en introduisant des mécanismes de parallélisation.  

Métriques de flux

Les métriques de flux sont un framework qui vise à mesurer la valeur fournie par un flux de valeur produit et la vitesse à laquelle il est délivré du début à la fin. Si les métriques de performance traditionnelles se concentrent sur des processus et des tâches spécifiques, les métriques de flux mesurent de bout en bout le flux de l’activité et ses résultats. Les organisations peuvent ainsi localiser les obstacles présents dans le flux de valeur qui empêchent les résultats souhaités.

On mesure les flux de valeur à l’aide de quatre métriques principales :

• La vitesse du flux mesure le nombre d’éléments terminés sur une période définie. Elle détermine si la valeur accélère.
• Le temps de flux mesure le temps qui s’est écoulé entre le début et la fin d’un élément pour évaluer le temps de mise sur le marché.
• L’efficacité du flux mesure le rapport entre le temps d’activité et le temps de flux total pour identifier tout gaspillage dans le flux de valeur.
• La charge de flux mesure le nombre d’éléments présents dans un flux de valeur afin d’identifier la sur-utilisation et la sous-utilisation des flux de valeur.

Les métriques de flux aident les organisations à voir ce qui circule dans l’ensemble de leur processus de livraison de logiciels du point de vue du client comme de celui de l’entreprise, quelles que soient les méthodologies de livraison de logiciels utilisées. On obtient ainsi une vision plus claire de l’impact de la livraison des logiciels sur les résultats de l’entreprise.

Métriques d’optimisation de l’intégration continue (CI)

Cycles de CI par jour

Cette métrique dénombre les exécutions quotidiennes de pipeline CI. Les équipes les plus performantes exécutent davantage de cycles CI chaque jour, 4 ou 5 par développeur en moyenne. Ce chiffre est à la fois le signe de publications fréquentes et d’une grande confiance dans le pipeline CI/CD, deux bonnes pratiques. 

Taux de réussite de la CI

La CI peut avoir lieu plusieurs fois par jour, même si elle n’est pas systématiquement couronnée de succès. On mesure le taux de réussite de la CI en divisant le nombre total de CI réussies par le nombre total de cycles de CI. Il faut s’efforcer d’avoir un taux de réussite de CI élevé : c’est le signe de processus CI/CD bien tenus et de tests de développement efficaces.

Métriques de la satisfaction client

Naturellement, tous ces efforts ont pour objet de satisfaire vos clients. Voici comment le mesurer.

Volume de tickets de clients

Le nombre d’incidents signalés ou de tickets d’assistance créés par vos clients indique dans quelle mesure ils sont satisfaits de vos produits. Cette métrique permet également de suivre les retours des clients après des publications de code, et donne de la visibilité sur la gravité des problèmes en production.

Si les volumes de tickets restent faibles, c’est le signe que vous avez mis en place les bonnes approches et que vous n’avez besoin que d’améliorations modestes. 

Disponibilité/temps de fonctionnement des applications

La disponibilité d’une application décrit la durée pendant laquelle une application est pleinement opérationnelle pour ses utilisateurs finaux. Les erreurs d’application peuvent entraîner de longs temps d’arrêt et susciter de la frustration chez les utilisateurs qui tentent d’y accéder. Pour améliorer la disponibilité des applications, les équipes doivent miser sur des stratégies éprouvées :

• infrastructure cloud à haute disponibilité,
• redimensionnement automatique,
• plans de reprise après sinistre (sauvegarde et restauration),
• mécanismes de sécurité rigoureux.

Performance des applications

Cette métrique évalue la façon dont une application se comporte face à des contraintes et différents niveaux de charge. Les équipes doivent effectuer ces tests de charge avant le déploiement en production, dans un environnement de pré-production équivalent à celui de destination.

Cette métrique permet d’identifier les transactions susceptibles d’échouer et les défaillances qui se produisent lorsque le système est soumis à une charge. L’équipe peut alors optimiser le code avant le déploiement et ainsi offrir une expérience utilisateur cohérente. 

Métriques d’optimisation des pratiques de supervision

Temps moyen de détection (MTTD)

Le MTTD est le temps nécessaire pour détecter une défaillance en production et la signaler. Cette métrique évalue l’efficacité de vos systèmes de supervision et d’alerte. Plus le MTTD est faible, plus vous avez de chances de résoudre le problème et de publier le correctif avant que les utilisateurs finaux ne soient touchés. Pour améliorer le MTTD, vous pouvez :

• employer des outils de supervision robustes,
• maximiser la couverture de la supervision des applications.

(Découvrez tout ce qu’il faut savoir sur la supervision DevOps et comment Splunk peut vous aider.)

Utilisation des applications et trafic

Cette métrique indique combien d’utilisateurs accèdent aux systèmes et combien de transactions ont lieu en temps réel. Le risque de défaillance du système augmente lorsque la charge est élevée. Vous pouvez donc tenir votre équipe DevOps en alerte pour intervenir en cas de problème. 

Les outils de suivi des métriques DevOps et DORA

Une fois que vous avez automatisé le suivi des métriques DevOps, vous pouvez commencer à améliorer les performances de livraison de vos logiciels. Plusieurs outils de suivi des métriques d’ingénierie capturent les principales métriques DevOps, notamment :

• Faros,
• Haystack,
• LinearB,
• Sleuth,
• Velocity par Code Climate.

Pour bien choisir votre outil de suivi des métriques, veillez à ce qu’il s’intègre aux principaux systèmes de livraison de logiciels : CI/CD, suivi des problèmes et supervision. Il doit également afficher les métriques sous une forme claire et lisible afin que les équipes puissent rapidement extraire des informations, identifier les tendances et tirer des conclusions à partir des données.

À chaque métrique DevOps sa fonction

Les métriques DevOps sont des données qui permettent aux entreprises d’évaluer l’efficacité de leurs pratiques DevOps et leur contribution aux objectifs globaux. Les quatre métriques essentielles du DevOps sont le taux d’échec des modifications, la fréquence de déploiement, le délai de modification et le temps moyen de rétablissement des services.

On recense également plusieurs autres métriques DevOps, cette fois liées à des tâches clés du pipeline de livraison de logiciel –déploiement, test, supervision et expérience utilisateur. Ces métriques contribuent à garantir la qualité des résultats métiers en évaluant les processus mis en œuvre par les entreprises.