DevOps : Google met en garde contre l’utilisation abusive des métriques DORA
Le rapport DORA de cette année se fait l’écho de l’expérience d’une organisation qui les a mis en pratique : les indicateurs DORA peuvent être puissants, mais ne sont pas toujours une science exacte.
L’équipe DevOps Research and Assessment (DORA) de Google est spécialisée dans les métriques, les métriques DevOps, en l’occurrence. Mais son dernier rapport State of DevOps met également en garde contre leur utilisation excessive.
L’enquête « Accelerate State of DevOps Report 2023 » a été conduite auprès de 36 000 professionnels de l’IT sur leur expérience du déploiement de l’approche DevOps et ses effets sur la performance de l’organisation.
Le groupe DevOps Research and Assessment (DORA) suggère aux pros de l’informatique de jauger les performances de leurs équipes en fonction de quatre mesures clés : la fréquence de déploiement ; le délai d’exécution des changements ; le taux d’échec des modifications ; et le temps de récupération des déploiements ayant échoué – anciennement, temps moyen de rétablissement du service (MTTR).
Depuis l’acquisition de DORA par Google en 2018, des startups et des éditeurs de développement logiciel établis, notamment Sleuth, Harness et Atlassian, ont publié des enquêtes sur les métriques DORA en direction des responsables de l’ingénierie.
Si DORA fait toujours le point sur les performances de l’organisation à l’aide de mesures, le rapport de cette année met aussi en garde contre les pièges courants lorsque ces indicateurs sont considérés comme une science exacte, ou utilisés de manière inappropriée pour évaluer les performances d’une équipe à l’autre.
« La mesure n’est pas l’objectif, tout comme la livraison d’un logiciel n’est pas le but », stipule cette neuvième édition du « State of DevOps Report ». « Se focaliser sur les indicateurs de performance peut conduire à des comportements inefficaces ».
Une mauvaise utilisation des métriques DORA peut se transformer en piège organisationnel
Il est naturel pour les responsables techniques et les dirigeants d’utiliser les résultats des métriques DORA comme objectifs et de comparer les performances des différentes équipes de développement, mais c’est une erreur, assure Nathen Harvey, responsable des relations avec les développeurs au sein de DORA et de Google Cloud.
« Regardons [l’équipe de livraison de logiciels] qui s’est le plus améliorée, car c’est celle-ci qui aura embrassé l’idée d’amélioration continue ».
Nathen HarveyResponsable des relations avec les développeurs, DORA et Google Cloud
« Ce que je souhaite vraiment que les dirigeants fassent, ce n’est pas acclamer les équipes de livraison de logiciels les plus rapides », avance-t-il. « Je veux qu’ils célèbrent les équipes les plus performantes à la fin de l’année. Regardons celle qui s’est le plus améliorée, car c’est celle-ci qui aura embrassé l’idée d’amélioration continue ».
L’amélioration continue n’a pas de « fin ». Cela peut être difficile à assimiler pour les chefs d’entreprise, consent Nathen Harvey. Selon le responsable, même l’équipe la plus performante peut encore se perfectionner. L’équipe la plus lente d’une entreprise est peut-être celle qui s’est le plus bonifiée au regard de l’application qu’elle délivre. Comparer ses mesures à celles d’une équipe qui développe une autre application – avec des contraintes, des exigences d’infrastructure et des expériences utilisateur différentes – n’est souvent pas productif et peut même s’avérer toxique, prévient-il.
Le rapport DevOps de DORA appelle les équipes de développement de logiciels à se concentrer non pas sur la production de fonctionnalités, pour reprendre les termes de M. Harvey, mais sur l’expérience de l’utilisateur et le bien-être de l’équipe.
« Les ingénieurs ne savent peut-être pas pour qui ils construisent [ou] pourquoi ils conçoivent ces fonctionnalités, on leur dit simplement : “Livrez plus, livrez plus, livrez plus, livrez plus” », assure-t-il. « Ce que nous constatons dans ce type d’équipes, c’est un taux d’épuisement plus élevé – même s’ils sont capables de livrer plus rapidement, ils ne livrent peut-être pas la bonne chose ».
Selon le rapport DevOps de DORA, les équipes qui créent des logiciels en gardant l’utilisateur final à l’esprit affichent des performances organisationnelles supérieures de 40 %. L’approche idéale est un équilibre entre la vitesse de déploiement, la performance opérationnelle et l’expérience utilisateur, indique le document.
Les métriques DORA : une phase exploratoire nécessaire, selon Cobre
Cette année, Sleuth.io et Propelo, acquis par Harness en janvier, ont développé des fonctions pour mieux exploiter les métriques DORA ; non seulement en les rapportant, mais en leur permettant de lancer des flux de travail automatisés pour mettre en œuvre les meilleures pratiques. L’intégration de Propelo dans la plateforme Harness DevOps permet aux utilisateurs de déclencher automatiquement des actions dans les pipelines CI/CD sur la base des métriques DORA.
Sleuth a suivi le mouvement en ajoutant Sleuth Actions et Sleuth Automations le mois dernier. Sleuth Actions était le framework développé par l’éditeur pour automatiser les processus IT. Il a été étendu et renommé Sleuth Automations, un ensemble de workflows pré-packagés pour des systèmes tiers, tels que GitHub Actions, qui sont offerts par le biais de la Sleuth Automations Marketplace.
Cobre, l’éditeur d’une plateforme de paiement d’entreprise en Colombie, a commencé à utiliser Sleuth pour rendre compte des métriques DORA il y a environ un an. La jeune pousse utilise Sleuth Automations pour déclencher des notifications Slack si les mises à jour sont décalées entre l’assurance qualité et la production, ainsi que pour bloquer automatiquement les pull requests (PR) dans les actions GitHub si elles ne répondent pas aux exigences internes.
« Elle ne permet pas à un développeur de fusionner une PR si plus de 20 fichiers ont été modifiés. C’est trop gros », explique Juan Matheus, architecte de solutions chez Cobre. Cela permettrait d’appliquer la meilleure pratique recommandée par DORA. Cela consiste à effectuer de petites modifications fréquentes plutôt que de grandes mises à jour de logiciels.
« Cela peut également vous aider à encourager vos développeurs à mettre le code en production plus rapidement, car ils savent qu’ils ne peuvent pas accumuler beaucoup de changements », ajoute-t-il.
Comme le suggère le rapport « Accelerate State of DevOps Report » de cette année, l’application de la méthode DORA peut conduire à un processus d’apprentissage et d’amélioration continu. Cobre s’est trouvé concerné par un goulet d’étranglement commun identifié par le document, la lenteur des révisions de code. La startup l’a ressenti lorsqu’elle s’est mise à superviser les métriques DORA et qu’il a fallu transformer les données brutes habituellement collectées à l’aide de l’outil d’observabilité New Relic.
« La façon dont chaque équipe définit la notion d’échec est unique. »
Dylan EtkinCofondateur et PDG, Sleuth
Le cofondateur de Sleuth a reconnu les difficultés rencontrées par Cobre.
« La façon dont chaque équipe définit la notion d’échec est unique », avance Dylan Etkin, cofondateur et PDG de Sleuth. « Lorsqu’une équipe choisit d’utiliser des métriques personnalisées, comme c’est le cas de l’équipe de Cobre, cela peut demander un effort supplémentaire pour décider exactement ce qui est une mesure pertinente et pour comprendre si elle représente vraiment un taux d’échec pour leurs équipes ou leurs projets ».
De fait, l’organisation DORA reconnaît que la statistique MTTR n’est pas simple à appréhender. C’est pour cette raison qu’elle a été retravaillée cette année et renommée « temps de récupération d’un déploiement raté », selon Nathen Harvey.
« Si je pousse un changement en production et qu’il provoque un incident, il s’agit d’un type de défaillance », relate-t-il. « Si une pelleteuse vient couper l’alimentation de mon centre de données, c’en est une autre. Et ce que je dois faire est très différent dans les deux cas. Nous avons donc dû nous concentrer exclusivement sur ces déploiements ratés ».
Cependant, comme chaque équipe et organisation DevOps est différente, il est difficile de prescrire une procédure spécifique pour la collecte de données sur ces indicateurs, signale le responsable.
« Certaines équipes se diront : “Eh bien, s’il y a une version…” et qu’ensuite, dans un délai très court, il y a une autre version, ou qu’il y a une régression (un rollback en VO), nous pouvons supposer que la première version correspond à un déploiement raté », explique-t-il. « Mais ce n’est pas nécessairement quelque chose [où] vous pouvez explorer votre système de contrôle de version et en tirer des données ».
