LE GUIDE ULTIME

DORA Metrics - Indicateurs DORA

Que sont les indicateurs DORA et pourquoi en avons-nous besoin ? Découvrez comment mesurer et améliorer les performances DevOps, en lien avec la gestion de la chaîne de valeur.

Introduction

La transformation numérique a transformé chaque entreprise en entreprise informatique, quel que soit son secteur d’activité. Les entreprises sont contraintes de réagir plus rapidement à l’évolution constante des besoins des clients, mais elles doivent aussi leur fournir des services stables. Afin de répondre à ces besoins, les équipes DevOps doivent constamment s’améliorer.

Les indicateurs DORA et Flow Metrics (les indicateurs de flux) répondent à ce besoin en fournissant des objectifs de données afin de mesurer la performance des équipes d’exploitation logicielle et de favoriser l’amélioration des produits.

Ce document vous expliquera ces indicateurs en détail et comment ils peuvent vous aider dans vos efforts de value stream management.

 

Que sont les DORA metrics (indicateurs DORA) ?

Les indicateurs DORA sont utilisés par les équipes de DevOps pour mesurer leurs performances et déterminer s’ils sont de bons ou de mauvais performeurs. Les quatre indicateurs utilisés sont la fréquence de déploiement (DF), les délais d’exécution des changements (LT), le temps moyen de récupération (MTTR) et le taux d’échec des changements (CFR).

Indicateur Explication
Deployment Frequency (Fréquence de déploiement) Il s'agit de la fréquence des mises en production réussies de logiciels.
Lead Time for Changes (Délai d’exécution des changements) Capture le temps entre la réception de demande d’un changement de code et son passage à un état déployable.
Mean Time to Recovery (Temps moyen de récupération) Mesure le temps qui s'écoule entre une interruption due à un déploiement ou à une défaillance du système et le rétablissement complet de la situation.
Change Failure Rate (Taux d’échec des changements) Indique la fréquence à laquelle les modifications ou les correctifs apportés par une équipe entraînent des défaillances après le déploiement du code.

L’acronyme DORA signifie équipe de DevOps Research and Assessment. Dans le cadre d'un programme de sept ans, ce groupe de recherche de Google a analysé les pratiques et les capacités DevOps et a pu identifier quatre paramètres clés pour mesurer les performances en matière de développement et de livraison de logiciels.

Cela a révolutionné le mode de fonctionnement des équipes DevOps, car ces mesures génèrent de la visibilité et fournissent des données réelles qui peuvent servir de point de départ pour des améliorations et des prises de décisions.

Afin d'établir ce guide utile pour DevOps, le groupe de recherche de Google a analysé les données de plus de 32 000 professionnels du domaine dans le monde. En plus d'un rapport officiel sur le DevOps, elle a également publié un livre blanc sur le retour sur investissement de la transformation DevOps ainsi qu'un livre sur la transformation DevOps intitulé « Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations », co-écrit par la chef d’équipe DORA Nicole Forsgren.

Les sections suivantes sont consacrées aux quatre indicateurs DORA et à leur utilité pour la gestion de la chaîne de valeur.

POSTER GRATUIT

17 indicateurs pour vous aider à créer un bon logiciel

Découvrez les indicateurs essentiels qui aident les responsables DevOps, les CTO, les responsables de produit et les ingénieurs à améliorer l'efficacité de l'ingénierie et à créer de meilleurs logiciels.

Obtenir une copie gratuite
17 Metrics To Help Build Better Software

Deployment Frequency (Fréquence de déploiement)

Comme son nom le suggère, la Deployment frequency (fréquence de déploiement) désigne la fréquence des mises en production réussies des logiciels. En d'autres termes, il mesure la fréquence à laquelle une entreprise déploie le code pour une application donnée.

Cet indicateur, qui se réfère au nombre total de déploiements par jour, a été développé à partir de concepts de fabrication qui mesurent et contrôlent la taille des lots de stocks qu'une entreprise livre.

Naturellement, les entreprises les plus prospères ont tendance à effectuer des livraisons plus petites et beaucoup plus fréquentes ; ou, dans le monde de DevOps, des déploiements plus fréquents, mais plus petits.

En général, un déploiement par semaine est la norme, tandis qu'une entreprise performante publie jusqu'à sept déploiements par jour. Bien entendu, le nombre standard de déploiements varie d’un produit à l’autre.

Par exemple, les applications qui demandent aux utilisateurs de télécharger la dernière Mise à jour sortent généralement une ou deux versions par trimestre tout au plus, alors qu'une solution SaaS peut être déployée plusieurs fois par jour.

Question à laquelle il répond Très bon performeur Bon performeur Performeur moyen Mauvais performeur
À quelle fréquence votre organisation déploie-t-elle du code en production ou le met-elle à la disposition des utilisateurs finaux ? À la demande (plusieurs déploiements par jour) Entre une fois par jour et une fois par semaine Entre une fois par semaine et une fois par mois Entre une fois par mois et une fois tous les six mois

Source: 2019 Accelerate State of DevOps, Google

Lorsque les équipes DevOps se rendent compte qu'elles font partie d'une catégorie peu performante, elles peuvent mettre en place des processus plus automatisés pour tester et valider le nouveau code, ainsi que réduire le délai entre la rectification des erreurs et la livraison du code modifié.

 

Lead Time for Changes (Délai d’exécution des changements)

Cet indicateur mesure le temps qui s'écoule avant que le code validé n'atteigne la production. Alors que la fréquence de déploiement mesure la cadence de publication du nouveau code, le Lead Time for Changes (délai d'exécution des changements) mesurent la rapidité de la livraison des logiciels. Il sert à mieux comprendre la durée de cycle de l'équipe DevOps et à savoir comment une augmentation des demandes est gérée. Plus le délai de mise en œuvre des modifications est court, plus l'équipe DevOps est efficace pour déployer le code.

Afin de mesurer les délais d’exécution des changements, deux données (ou horodatages) sont nécessaires : l'heure exacte de la réception de la demande et l'heure exacte du déploiement, soit la durée entre début et fin de produit. Le temps moyen est ensuite utilisé comme indicateur de la performance globale.

Question à laquelle il répond Très bon performeur Bon performeur Performeur moyen Mauvais performeur
Combien de temps faut-il pour passer d'un code validé à un code fonctionnant avec succès en production ? Moins d’une journée Entre un jour et une semaine Entre une semaine et un mois Entre un mois et six mois

Source: 2019 Accelerate State of DevOps, Google

Si l'on constate que les délais d’exécution des changements sont longs, les équipes DevOps peuvent mettre en place des processus de déploiement et d'examen plus automatisés et diviser les produits et les fonctionnalités en unités beaucoup plus compactes et faciles à gérer.

 

Change Failure Rate (Taux d’échec des changements)

Cet indicateur mesure le pourcentage de changements qui ont été apportés à un code qui ont ensuite entraîné des incidents, des retours en arrière ou tout autre type d'échec de production. Ainsi, le Change Failure Rate (taux d’échec des changements) est un véritable indicateur de la qualité et de la stabilité alors que les indicateurs précédents, la fréquence de déploiement et le délai d’exécution des changements, n’indiquent pas la qualité du logiciel, mais juste son rythme de livraison. Selon le rapport DORA, les plus performants se situent entre 0 et 15 %.

Le taux d’échec des changements est calculé en comptant le nombre d’échecs de déploiement et en le divisant par le nombre total de déploiements. Lorsqu'il fait l’objet d’un suivi régulier, cet indicateur donne une idée assez précise du temps consacré à la correction des erreurs et des bogues par rapport à la livraison d'un nouveau code. Il va sans dire qu'une équipe DevOps doit toujours s'efforcer d'obtenir la moyenne la plus basse possible.

Question à laquelle il répond Très bon performeur Bon performeur Performeur moyen Mauvais performeur
Quel est le pourcentage de modifications apportées aux résultats au niveau de la production ou des utilisateurs finaux qui entraînent une dégradation du service ? 0-15% 0-15% 0-15% 46-60%

Source: 2019 Accelerate State of DevOps, Google

Afin d'améliorer une moyenne élevée, les équipes doivent réduire les échecs de déploiement et les pertes de temps dues aux retards.

 

Mean Time to Recover (Temps moyen de récupération)

L’indicateur Mean Time to Recover (délai moyen de récupération) mesure le temps qu'il faut à un service pour rebondir après un échec. Peu importe les performances de l'équipe DevOps, des pannes ou des incidents imprévus peuvent survenir. Et comme les défaillances ne peuvent être évitées, c'est le temps nécessaire pour restaurer ou récupérer un système ou une application qui fait la différence.

Si une entreprise dispose d'un temps de récupération court, les dirigeants se sentent généralement plus à l'aise pour expérimenter et innover de manière raisonnable. En retour, cela crée un avantage concurrentiel et améliore les revenus de l'entreprise.

Cet indicateur est important dans le sens où il incite encourage les ingénieurs à construire des systèmes plus robustes. Il est généralement calculé en suivant le temps moyen entre le signalement d’un bogue et le moment où la correction du bogue est déployée.

Question à laquelle il répond Très bon performeur Bon performeur Performeur moyen Mauvais performeur
Combien de temps faut-il pour rétablir le service après un incident de service ou un défaut ayant un impact sur les utilisateurs ? Moins d’une heure Moins de 24 heures Moins de 24 heures Entre une semaine et un mois

Source: 2019 Accelerate State of DevOps, Google

Afin d'améliorer leurs performances en matière de délai moyen de récupération, les équipes DevOps doivent pratiquer une surveillance continue et donner la priorité à la récupération lorsqu'une défaillance se produit. Il est également utile d'établir un plan d'action pour réagir immédiatement à toute défaillance.

20 Key Questions a Microservice Catalog Answers

Poster

20 Key Questions a Microservice Catalog Answers

Download this LeanIX poster to see the 20 key questions a microservice catalog can answer.

Microservices @ LeanIX - then, now and tomorrow

Video

Microservices @ LeanIX - then, now and tomorrow

Live Recording - EA Connect Day 2020 

Per Bernhardt - Staff Software Engineer - LeanIX

 

Maximize the Development Efficiency of Your Microservices Landscape with LeanIX

Webinar

Maximize the Development Efficiency of Your Microservices Landscape with..

Watch this on-demand webinar hosted by The Open Group, where LeanIX shares insights on how we can help bring order and clarity to your complex microservices architecture.

Efficiently Navigate your Microservices with LeanIX

Webinar

Efficiently Navigate your Microservices with LeanIX

Watch this interview-style webinar on how to build reliable software using a microservice catalog - including a product demo

Les avantages du suivi des indicateurs DORA

Pourquoi toutes les équipes DevOps devraient utiliser les indicateurs DORA ? La réponse est assez simple : en l’absence de données permettant de mesurer les performances, il est difficile, voire impossible, d'apporter des améliorations.

Les indicateurs DORA décomposent les processus abstraits de développement et de livraison de logiciels pour les rendre plus tangibles et visibles, afin que les responsables de l'ingénierie puissent prendre des mesures pour simplifier les processus et accroître la valeur des logiciels.

Voici un aperçu des avantages les plus convaincants des indicateurs DORA.

La prise de décision

Les entreprises qui rationalisent leur processus de développement et de livraison augmentent la valeur des logiciels et sont plus performantes à long terme. Le suivi des performances à l'aide des indicateurs DORA permet aux équipes DevOps d'établir des tendances qui permettent de prendre décisions éclairées qui vont dans le bon sens.

Créer de la valeur

Ces dernières années, le  value stream management est devenu un élément important du développement des logiciels. Dans ce contexte, les indicateurs DORA jouent un rôle important car ils montrent quel type de valeur est fourni au client et quel niveau de performance est nécessaire pour atteindre les résultats métier souhaités. Ainsi, lorsque les équipes DevOps utilisent les indicateurs DORA, elles constatent généralement une augmentation de la valeur au fil du temps.

Cycle vertueux

Lorsque les performances sont mesurées, il y a de fortes chances qu'elles soient manipulées. Autrement dit, les personnes qui se sentent responsables d'un indicateur donné vont adapter leur comportement pour améliorer cet indicateur de leur côté. Bien que cela puisse avoir un effet de distorsion dans divers contextes, c'est en fait l'effet recherché du DevOps, il permet d'éradiquer les processus inefficaces et de réduire le gaspillage.

WEBINAIRE

Apporter de l’ordre et de la clarté à vos microservices complexes

Obtenez des informations pour comprendre comment donner des moyens aux équipes autonomes tout en soutenant la gouvernance et encourager le développement rapide de logiciels en automatisant la détection et le catalogage des microservices.

Regarder maintenant
Events_Cover Image for Recording_The Open Group Webinar_042021

Principaux défis des indicateurs DORA

Si les indicateurs DORA constituent un excellent moyen pour les équipes DevOps de mesurer et d'améliorer les performances, leur utilisation n’est pas aussi simple en pratique. Pour la plupart des entreprises, les quatre indicateurs ne sont qu'un point de départ et doivent être adaptés au contexte de chaque application plutôt qu'à celui de l'équipe ou de l'organisation.

Voici quatre défis rencontrés lors de l’utilisation des indicateurs DORA :

  • Environnement et données décentralisés : les données sont dispersées dans différentes sources à travers l’environnement informatique.
  • Extraction des données : les données sont uniquement disponibles au format brut.
  • Transformation des données : les données doivent être transformées et combinées en unités calculables.
  • Vitesse vs. Stabilité : les différents indicateurs doivent être replacés dans leur contexte. Un haut taux d’échec des changements peut indiquer qu’il y a un mauvais contrôle de qualité alors qu’une fréquence de déploiement élevée ne témoigne en rien de la qualité du code ou du produit.

 

Indicateurs DORA et Value Stream Management

Nous avons déjà mentionné les indicateurs DORA et leur importance pour le value stream management. De nos jours, de plus en plus d’entreprises n’utilisent pas seulement les indicateurs DORA pour rationaliser et optimiser le développement et la livraison de logiciels, mais aussi la gestion de la chaîne de valeur pour bénéficier d’une visibilité de bout en bout de l'ensemble du processus de production.

En contrôlant chaque étape (c'est-à-dire de la demande du client à la livraison du produit) à l’aide d'une plateforme de gestion de la chaîne de valeur appropriée, telle que LeanIX VSM, cette technique de gestion permet de s'assurer que la valeur totale du logiciel est livrée au client de la manière la plus efficace possible.

 

Conclusion

À ce jour, DORA est le meilleur moyen de visualiser et de mesurer les performances des équipes d'ingénieurs et de DevOps. Cependant, les entreprises ne doivent pas s'arrêter là. Afin de libérer toute la valeur que le logiciel peut apporter au client, les indicateurs DORA doivent s’inscrire dans le cadre plus large du value stream management.

En reliant les catalogues de services, la planification agile et les plateformes de livraison par une plateforme telle que la solution LeanIX Value Stream Management, une entreprise développant des logiciels bénéficiera d’une vue d’ensemble lui permettant de réduire les inefficacités et de simplifier le développement et la livraison de logiciels.

Free trial

Build Reliable Digital Products Faster

Connect teams, technology, and processes for efficient software delivery with LeanIX Value Stream Management solution.

Free 14-Day Trial
VSM_header_mobile_edited (1)
ESSAI GRATUIT DE 14 JOURS

Découvrez la solution LeanIX Value Stream Management

HubSpot Video

Utilisez les intégrations et les données de GitHub et Kubernetes pour aider vos équipes à utiliser au mieux les technologies disponibles afin de développer d'excellents produits. 

  • Découvrez les référentiels de code et créez votre catalogue de services 
  • Obtenez des informations détaillées sur le Ownership
  • Partagez les connaissances au sein de votre organisation de développement
Êtes-vous prêt(e) à vous convaincre de l'utilité de la solution ? Inscrivez-vous à un essai gratuit de 14 jours et faites passer votre développement de logiciels au niveau supérieur. 

Démarrer l'essai de 14 jours

Réponses aux questions fréquemment posées sur les indicateurs DORA

Que sont les indicateurs DORA ?

Les DORA Metrics (indicateurs DORA) sont utilisés par les équipes DevOps pour mesurer leurs performances et déterminer s’ils sont de bons ou de mauvais performeurs. Les quatre indicateurs utilisés sont la fréquence de déploiement (DF), le délai d’exécution des changements (LT), le temps moyen de récupération (MTTR) et le taux d’échec des changements (CFR).

Qu’est-ce que la Deployment Frequency (fréquence de déploiement) ?

La Deployment Frequency (fréquence de déploiement) désigne la fréquence des mises en production réussies des logiciels. En d'autres termes, il mesure la fréquence à laquelle une entreprise déploie le code pour une application donnée.

Qu’est-ce que le Lead Time for Changes (délai d’exécution des changements) ?

Le Lead Time for Changes (délais d’exécution des changements) mesure la rapidité de la livraison des logiciels. Il sert à mieux comprendre la durée de cycle de l'équipe DevOps et à savoir comment une augmentation des demandes est gérée.

Afin de mesurer les délais d'exécution des changements, deux données (ou horodatages) sont nécessaires : l'heure exacte de réception de la demande et l'heure exacte du déploiement, soit la durée entre le début et la fin d’un produit. Le délai moyen est ensuite utilisé comme indicateur de la performance globale.

Qu’est-ce que le Change Failure Rate (taux d’échec des changements) ?

Le Change Failure Rate (taux d'échec des changements) est une véritable mesure de la qualité et de la stabilité de la livraison des logiciels. Il désigne le pourcentage de modifications apportées à un code qui ont ensuite entraîné des incidents, des retours en arrière ou tout autre type d'échec de production. 

Il est calculé en comptant le nombre d'échecs de déploiement et en le divisant par le nombre total de déploiements.

Qu’est-ce que le Mean Time to Recover (délai moyen de récupération) ?

L’indicateur Mean Time to Recover (délai moyen de récupération) mesure le temps qu'il faut à un service pour rebondir après une défaillance. Il est calculé en suivant le délai moyen entre un rapport de bogue et le moment où le correctif est déployé.