Taux d'échec des changements expliquée (métrique DORA)

Dans l'environnement évolutif d'aujourd'hui, les entreprises technologiques ont du mal à évaluer les performances de leurs équipes de développement. Différentes études ont été menées dans le but de définir des critères objectifs qui rendront les équipes d'ingénieurs plus agiles et plus efficaces dans le processus de développement de logiciels.

Au cours des 10 dernières années, plus de 30 000 professionnels de l'informatique ont participé à l'enquête mondiale sur l'accélération du DevOps. En conséquence, Google a créé en 2015 le programme DORA (DevOps Research and Assessment). En 2018, ils ont publié leur étude Accelerate introduisant les métriques DORA : 4 métriques clés qui peuvent distinguer les équipes de développement très performantes des équipes moyennement performantes. Les métriques sont listées ci-dessous et dans cet article nous expliquons l'une d'entre elles, le taux d'échec des changements (Change Failure Rate ou CFR), qui mesure le pourcentage de changements à la production qui résultent en un service dégradé (ou des incidents). Nous clarifierons le rôle du CFR dans les entreprises technologiques et la nécessité d'identifier et de gérer le taux d'échec du changement de manière appropriée.

Présentation rapide des Métriques DORA

L'équipe de développement déploie des changements pour la production ou pour les utilisateurs. Certains de ces changements provoqueront des incidents (c'est-à-dire une interruption de service ou un problème de correctif). Le taux d'échec des changements est donc le pourcentage de changements qui entraînent une dégradation du service.

Outre le CFR, le groupe DORA définit trois autres mesures (appelées métriques DORA) :

• Fréquence de déploiement (Deployment Frequency) - mesure la fréquence à laquelle le code est déployé avec succès dans un environnement de production. Les équipes d'ingénieurs logiciels souhaitent fournir de nouvelles fonctionnalités aux clients le plus rapidement possible et cette mesure est donc utile pour comprendre à quelle fréquence cela se produit.
• Délai nécessaire aux changements (Lead Time For Changes) - cette mesure indique le temps nécessaire pour apporter une nouvelle modification à un environnement de production en examinant le temps écoulé entre le premier commit et le moment où le code est exécuté avec succès dans la production.
• Délai de récupération après un échec de déploiement (Failed Deployment Recovery Time) - mesure le temps nécessaire au système pour rétablir le service en cas d'incident ou de défaut affectant les utilisateurs.

Les métriques DORA donnent aux chefs d'équipe des informations véridiques qu'ils peuvent analyser pour évaluer les performances de l'équipe. Ils peuvent alors améliorer leurs processus de développement. En examinant le CFR et le délai de récupération après un échec de déploiement, vous pouvez vous assurer que votre code est robuste et stable, tout en réduisant les défaillances.

Il faut travailler la vitesse ET la stabilité en même temps. Vous ne pouvez pas vous contenter d'améliorer la stabilité, et vous ne pouvez pas vous contenter d'améliorer la vitesse. Par exemple, vous pourriez aller plus vite, mais cela augmenterait probablement les incidents. Vous pouvez également prendre plus de temps pour coder afin d'améliorer la qualité, mais vous sacrifierez la vitesse et vous n'aurez pas un rythme assez rapide.

Pour en savoir plus, consultez notre guide complet sur les métriques DORA ici.

Qu'est-ce que le taux d'échec des changements?

Le taux d'échec des changements mesure le pourcentage de déploiements qui provoquent un échec en production et qui doivent être corrigés ou annulés après avoir été déployés. Le taux d'échec des changements détermine le nombre de changements déployés en production qui ont entraîné un incident. Par exemple, un taux d'échec élevé indique que votre équipe n'a pas accordé suffisamment d'attention aux tests ou que son processus de déploiement n'est pas assez efficace. Par conséquent, le CFR mesure la stabilité et la qualité des déploiements de vos équipes.

Qu'est-ce qu'un échec?

Les organisations ont des critères différents quant à la signification d'un échec dans leurs opérations, puisqu'il n'existe pas de définition universelle de l'échec. Il est donc nécessaire de définir le terme «échec» à un niveau élevé dans chaque organisation, afin que toutes les équipes respectent et interceptent les échecs lorsqu'ils se produisent. Nous présentons ici quelques cas qui sont traités comme des défaillances par les équipes d'ingénieurs :

• Incidents capturés par l'outil de gestion des incidents (par exemple PagerDuty, Zenduty). En général, les équipes ont besoin d'un temps de fonctionnement élevé de leur produit ou service, de sorte qu'un tel outil peut être un bon moyen de suivre les défaillances.
• Incident système (vous le capturerez dans DataDog, AWS CloudWatch, NewRelic, etc.) Fondamentalement, votre système est dégradé ou en panne.
• Erreur produite par l'application (capturée dans un outil de suivi des erreurs, comme Sentry).
• Les bogues qui affectent les utilisateurs à partir d'un gestionnaire d'incidents (comme Jira).
• Gravité de l'incident : certaines équipes classent les incidents par niveau et ne réagissent qu'aux déploiements qui ont provoqué des pannes majeures, par exemple lorsque l'application n'est pas accessible aux clients.
• Nécessité d'un retour en arrière : il s'agit d'une manière assez simple et souvent utilisée de définir les défaillances, bien qu'elle ne soit pas toujours la plus complète. Dans ce cas, les équipes désignent les échecs comme des déploiements qui ont nécessité un retour en arrière.

Tous les problèmes qui surviennent après un changement ne sont pas considérés comme des échecs. Par exemple, les bogues mineurs qui n'affectent pas les performances globales du système ou qui n'ont pas d'incidence sur l'utilisateur (ex : correction d'une étiquette) ne sont pas considérés comme des échecs.

Comment calculer le taux d'échec des changements?

Si vous mesurez les bons paramètres, il sera facile de calculer le taux d'échec des changements. Il suffit de diviser le nombre de déploiements qui ont causé des échecs par le nombre total de déploiements. Par exemple, si votre équipe a effectué 6 déploiements aujourd'hui, et que 2 d'entre eux ont causé des problèmes qui nécessitent des corrections, alors le taux de CFR de l'équipe est de 33%. Dans le calcul du CFR, vous prenez en compte uniquement les changements et les échecs déployés en production, et non les échecs apparus lors de la phase de test, puisqu'ils n'ont jamais été déployés.

Selon les recommandations du groupe DORA, il convient également d'observer les trois autres paramètres : la fréquence de déploiement, le délai de mise en œuvre des changements et le délai de reprise. Pour obtenir de meilleures performances et optimiser les bonnes choses, en plus de mesurer le taux d'échec des changements, vous devriez établir une procédure qui définit ce qu'est un échec.

Qu'est-ce qu'un bon taux d'échec des changements?

Lorsque l'équipe procède à un déploiement vers la production, le travail a été intégré au tronc, tous les tests et l'analyse critique ont été réussis et devraient fonctionner comme prévu. En réalité, de nombreuses actions non planifiées peuvent se produire, et certains des changements se traduiront par un échec ou un arrêt de service. Un certain taux d'échecs est prévisible, mais vous devez savoir ce qui indique une faible performance de l'équipe.

Selon le rapport State of DevOps 2022, il existe trois classifications du CFR : les très performants se situent entre 0 et 15 %, les moyennement performants entre 16 et 30 % et les peu performants entre 46 et 60 %. Cependant, cette classification change chaque année. Parmi les entreprises consultées pour cette étude, 11 % des équipes sont très performantes, 69 % sont moyennement performantes et 19 % sont peu performantes. Mesurer le CFR vous donne un aperçu de la qualité de développement de vos équipes de développement logiciel et vous aide à voir où des changements sont nécessaires, avant que cela ne devienne un problème sérieux.

Classification du taux d'échec des changements, selon le rapport State of DevOps 2022.

Relation entre le taux d'échec des changements et le délai de récupération après un échec de déploiement

Le délai de récupération après un échec de déploiement est défini comme le temps nécessaire au système pour rétablir le service en cas d'incident. Avec le taux d'échec des changements, le délai de récupération après un échec de déploiement est une mesure de la qualité et de la stabilité du processus de livraison de votre équipe. Si le taux d'échec des changements est élevé, le délai de récupération après un échec de déploiement tend généralement à l'être aussi. Cela signifie qu'il faut plus de temps que souhaité pour rétablir le service dans son état de fonctionnement normal, ce qui nuit à la fiabilité globale du logiciel et à la productivité de l'entreprise.

En améliorant la culture d'ingénierie, les pratiques DevOps vous conduiront à des changements plus petits, mais plus fréquents. Les petits changements sont plus faciles à repérer et à corriger, ce qui réduit le temps nécessaire pour y remédier. Il sera plus sûr de déployer davantage de changements. Il est moins risqué pour une entreprise d'avoir une équipe qui peut déployer plus de changements avec moins d'échecs et qui peut corriger une erreur rapidement (par exemple en moins de 30 minutes). En outre, un CFR et un délai de récupération après un échec de déploiement élevés signifient que l'on passe plus de temps à corriger les bogues et à dégrader le service, ce qui revient à dépenser un dollar sans créer de valeur commerciale supplémentaire.

Coût et impact des échecs en production sur les entreprises

Afin de comprendre où se situent les failles dans le processus de déploiement, les directeurs techniques suivent généralement le taux d'échec des changements de l'équipe. Un CFR important peut avoir de multiples conséquences en termes de coûts financiers, opérationnels et de produits, il est donc crucial d'identifier ce taux et de le gérer. Un plus grand nombre de bogues entraîne la perte de clients, en raison de l'impact sur la confiance et la réputation. Voici une liste des principaux problèmes qui peuvent découler d'un CFR élevé :

• Diminution de la productivité - les interruptions fréquentes du processus de travail pour corriger les erreurs de modification pèsent lourdement sur le flux de travail de votre équipe. Les changements fréquents de contexte retardent le développement des fonctionnalités (et réduisent les délais de mise sur le marché). Des échecs multiples peuvent également démotiver les développeurs et réduire leur efficacité.
• Augmentation des coûts de maintenance - le retour en arrière en cas d'échec d'une modification entraîne un gaspillage de ressources en termes de temps et d'argent pour votre équipe. Le temps passé sur les bogues est un coût d'opportunité (dans le développement de fonctionnalités qui génèrent plus de revenus) car vous auriez pu développer une fonctionnalité à la place.
• Compétitivité réduite - les temps d'arrêt du système et la correction constante des fonctionnalités peuvent être frustrants pour les utilisateurs finaux et faire de vous un acteur moins compétitif sur le marché.
• Risques pour la sécurité - lorsque les nouvelles fonctionnalités ne sont pas suffisamment testées (parce que vous essayez d'aller plus vite), votre produit devient vulnérable aux cyber-attaques et aux failles de sécurité.

En termes financiers, le coût du taux d'échec des changements peut varier considérablement en fonction de la gravité des problèmes, du type de défaillance, de la taille et de la complexité du système. Il dépend également de la taille de votre organisation, du nombre de clients et de l'industrie ou du secteur concernés. Il est difficile de définir un coût monétaire acceptable pour le taux d'échec des changements, car celui-ci varie beaucoup.

Dans le retour sur investissement de la transformation DevOps, il y a des coûts de temps d'arrêt basés sur différents facteurs : par exemple, pour les entreprises Fortune 1000, le coût horaire moyen d'une panne d'infrastructure est de 100 000$ et le coût moyen d'une panne d'application critique par heure est d'environ 500 000$.

Afin de réduire le taux d'échec des changements et les coûts financiers associés, il est bon d'évaluer régulièrement les coûts du CFR et de les comparer à ceux d'organisations similaires dans votre secteur d'activité. Vous comprendrez ainsi les coûts relatifs et pourrez fixer des buts et des objectifs réalistes.

Comment minimiser le taux d'échec des changements?

Pour réduire le CFR, les équipes doivent adopter les meilleures pratiques telles que les tests automatisés rigoureux, l'intégration continue et le déploiement continu (CI/CD), la réalisation de revues de code diligentes et le déploiement de solutions efficaces de surveillance du système. La réduction du taux d'échec des changements est cruciale pour améliorer les performances de votre équipe, et pour le minimiser, la meilleure approche consiste à mettre en œuvre une livraison continue, incluant les pratiques suivantes :

• Automatisation des tests - outils d'automatisation permettant de mener et d'analyser les tests (recherche des défaillances réelles).
• Automatisation des déploiements - déploiements entièrement automatisés ne nécessitant pas d'intervention manuelle.
• Développement basé sur des troncs - avoir moins de trois branches actives dans un référentiel de code ; les branches et les troncs ont des durées de vie très courtes.
• Intégration continue - création de versions canoniques et de paquets qui sont ensuite déployés et publiés.
• Tests continus - tests tout au long du cycle de vie de la livraison du logiciel plutôt que comme une phase distincte après le cycle de développement.

Voici d'autres bonnes pratiques permettant de minimiser le risque de défaillance du système (CFR) :

• Pour la détection des bogues, mettez en œuvre des fonctions de surveillance et de test automatisées.
• Vous serez mieux à même de suivre les défaillances et de les corriger rapidement si vous effectuez de petits déploiements à un rythme fréquent.
• Il est plus sage d'identifier et de traiter les causes des déploiements ratés, plutôt que de réduire le nombre de déploiements pour réduire les échecs.

En plus du CFR, vous devez suivre d'autres détails associés, comme la durée de la panne ou la dégradation du service due à la défaillance, ainsi que les étapes nécessaires pour rétablir le service. Le suivi de la durée de la panne aide l'équipe à hiérarchiser ses efforts et à améliorer les processus. Inversement, le suivi des étapes de restauration aide l'équipe à comprendre la cause principale des défaillances.

Une façon simple de mesurer le taux d'échec des changements

Les calculs manuels peuvent vous fournir des informations utiles, mais un outil automatisé comme Axify peut modéliser avec précision le comportement du système et suivre le taux d'échec des changements sans effort. Axify est une plateforme unique permettant d'observer tous les indicateurs clés de performance qui vous aideront à améliorer vos processus de développement et de livraison. Elle est équipée de tableaux de bord de qualité supérieure et assure un suivi constant des indicateurs DORA en temps réel, ce qui simplifie l'ensemble du processus et permet aux équipes de se concentrer sur les améliorations à apporter. Il n'y a pas de calcul manuel, ce qui réduit les risques d'erreur humaine. Avec Axify, chaque équipe calcule son CFR et celui-ci n'est pas normalisé entre elles.

Voici quelques-unes des principales caractéristiques d'Axify concernant les mesures DORA :

• Fréquence de déploiement - mesure la fréquence à laquelle une organisation réussit à déployer en production. Cette mesure importante facilite les tests, les déploiements, les rétroactions et les retours en arrière, tout en augmentant la valeur perçue par vos clients.
• Délai d'exécution des changements - temps écoulé entre la première validation et l'exécution réussie du code en production. Cette mesure nous permet d'évaluer l'efficacité des cycles et des initiatives de développement de logiciels. Il tend à entraîner des changements organisationnels, humains et techniques.
• Délai de rétablissement du service - mesure le temps nécessaire au système pour rétablir le service en cas d'incident ou de défaut affectant les utilisateurs.
• Des métriques d'ingénierie logicielle, telles que les chaînes de valeur, les items prioritaires à travailler, le suivi et les prédictions de livraison, des objectifs, le temps investi par type d'items, la répartition du temps de cycle, le débit, le niveau de service attendu, la stabilité du workflow, le travail en cours (WIP), la taille des revues de code, les revues de codes intégrées et auto-évaluées, le moral de l'équipe, et plus encore.