Quatre Indicateurs Clés Accelerate

Auteure : Tom Geraghty
Source : Accelerate Metrics - Software Delivery Performance Measurement
Date : 14/04/2021

---

Traducteur : Fabrice Aimetti
Date : 13/10/2023

---

Traduction :

Que sont les indicateurs d'Accelerate ?

Les indicateurs DORA/Accelerate ont été conçus par Nicole Forsgren, Jez Humble et Gene Kim, à partir de données et de faits tirés des rapports annuels State Of DevOps, et synthétisés dans le livre "Accelerate", publié en 2018.

Les quatre mesures reflètent les catégories de capacités fondamentales qu'ils ont identifiées comme étant essentielles à la performance dans la livraison de logiciels :

• Livraison continue
• Architecture
• Produit et Processus
• Lean Management et Monitoring
• Culture

Les quatre indicateurs Accelerate sont les suivants :

• Lead time de mise en œuvre du changement
• Fréquence de déploiement
• Temps moyen de rétablissement (Mean Time To Restore ~ MTTR)
• Taux d'échec des changements

Les deux premiers s'orientent vers l'objectif classique du développement, qui est d'apporter des changements, tandis que les deux autres s'orientent vers l'objectif classique de l'exploitation, qui est d'assurer la stabilité.

Les mesures sont puissantes et utiles, que vous fonctionniez en mode Agile ou Cycle en V, que vos environnements de travail soient dans le cloud public ou sur du matériel dédié dans un datacenter, et que votre temps d'exécution soit un mainframe monolithique ou des microservices conteneurisés. Ils ne dépendent d'aucune technologie et sont tout aussi utiles pour une petite équipe technique dans une startup que pour de multiples équipes orientées flux de valeur dans de grandes entreprises complexes.

Les données de l'étude Accelerate montrent que les organisations technologiques les plus performantes ont les capacités suivantes :

• Déploiements de logiciels très fréquents
• Lead times courts entre l'engagement et le déploiement
• Délais courts de reprise après un temps d'arrêt
• Taux d'échec des changements plus faible

Pourquoi les utiliser?

Que votre organisation soit fortement axée sur la fiabilité et la stabilité, ou sur les itérations rapides de produits et la rapidité de mise sur le marché de nouvelles fonctionnalités, toutes ces mesures sont importantes.

Il s'agit d'indicateurs basés sur les résultats, et non sur les entrées ou les sorties. En d'autres termes, elles mesurent ce qui "se passe", et non ce que quelqu'un a fait (heures de travail, par exemple) ou ce qu'il a produit (lignes de code écrites, par exemple). Les mesures de résultats décrivent un état souhaité du monde, par exemple "haute fiabilité" (mesurée par le MTTR) ou "livraison rapide de la valeur" (mesurée par le lead time du changement).

Ces mesures reflètent les résultats souhaités qui sont communément partagés par toutes les équipes d'une organisation. L'un des dangers des mesures est qu'elles peuvent inciter les équipes à se faire concurrence ; si les équipes ont des mesures différentes, il peut en résulter une relation conflictuelle où le succès d'une équipe nuit à l'autre. Les équipes de développement et d'exploitation cloisonnées en sont un exemple : les développeurs proposent autant de fonctionnalités que possible (parce que leur mesure est la livraison de nouvelles fonctionnalités), sans se soucier de la maintenabilité (parce que c'est la mesure de l'équipe d'exploitation, pas la leur), et l'équipe d'exploitation s'efforce d'assurer le fonctionnement fiable des services sous l'assaut de nouvelles modifications et d'un code difficile à maintenir.

Lorsque ces quatre indicateurs sont en tension les uns avec les autres, ils sont de puissants moteurs de performance. Les équipes ne peuvent pas jouer consciemment ou inconsciemment avec leurs indicateurs en augmentant l'un d'entre eux alors que l'autre en pâtit. Les équipes doivent être en mesure de s'optimiser elles-mêmes, mais une trop grande importance accordée à l'optimisation localisée peut déboucher sur une organisation peu performante où les performances d'une équipe font souffrir une autre équipe.

Il est essentiel de les combiner. L'utilisation isolée d'un seul indicateur n'apporte aucun avantage et peut même être préjudiciable. Par exemple, mesurer le taux de changement sans mesurer le taux d'échec des changements pourrait entraîner des changements très fréquents et de mauvaise qualité qui auraient un impact sur les niveaux de service et l'expérience des clients. Mesurer uniquement le temps moyen entre les défaillances sans mesurer le temps moyen de rétablissement pourrait entraîner des temps d'arrêt peu fréquents mais à fort impact en encourageant des stratégies de déploiement "big bang".

Penchons-nous sur chaque indicateur, sur sa signification et sur la manière dont les équipes peuvent l'améliorer :

Indicateur : Lead Time de mise en œuvre du changement

Répond à : "Combien de temps faut-il pour qu'un commit soit exécuté en production ?"

Il s'agit d'une mesure de la capacité technique à faire fonctionner le code commité et à fournir de la valeur, puisque ce n'est que lorsque le code fonctionne en production que de la valeur est fournie - à toutes les autres étapes antérieures, le "travail" ne fait que générer du stock. Cette mesure est fortement liée à la capacité technique de l'équipe et à la puissance technique de la plateforme et de l'architecture des systèmes. Une bonne conception du système, des pipelines CI/CD et des lots de petite taille améliorent cette mesure.

En termes de mesure, vous devez savoir et enregistrer à la fois le moment où le commit a eu lieu et le moment où le déploiement correspondant a eu lieu. Le temps écoulé entre ces deux événements est le délai de changement.

Remarque : certaines équipes peuvent mesurer le cycle time total au lieu du délai entre le commit et le déploiement, mais le cycle time total (à partir du moment où une exigence est identifiée et où le travail est commencé) peut dépendre de facteurs confus échappant au contrôle de l'équipe et n'est donc pas un indicateur aussi fiable.

Indicateur : Fréquence de déploiement

Répond à : "Quelle est la fréquence de déploiement en production ?

La fréquence de déploiement est en fait une approximation de la taille des lots. Des lots plus petits (déploiements) effectués plus souvent sont un indicateur et une base pour des performances plus élevées. Les lots de petite taille sont plus rapides à déployer, présentent moins de risques et sont plus faciles à annuler que les lots de grande taille. Des techniques telles que les feature flags, les déploiements en canaris et les pipelines CI/CD bien conçus améliorent cette métrique.

Cet indicateur encourage également l'adoption d'un état d'esprit expérimental, en utilisant de multiples petits déploiements pour tester des hypothèses et mettre à la disposition des clients les fonctionnalités les plus utiles.

C'est l'un des indicateurs les plus faciles à mesurer, car les déploiements sont généralement bien enregistrés, quels que soient les méthodes ou les systèmes utilisés. Veillez toutefois à définir un déploiement de manière appropriée : dans votre contexte, une modification d'une seule ligne de code est-elle considérée comme un déploiement ? Une modification de plusieurs lignes de code est-elle prise en compte si elle concerne un système qui reçoit très peu de trafic ?

Indicateur : Temps moyen de rétablissement (MTTR)

Répond à : "Combien de temps nous faut-il pour rétablir la situation après une panne en production ?

Les pannes sont inévitables. Qu'il s'agisse des conséquences imprévues des changements, qui peuvent entraîner une défaillance partielle ou totale des services, de problèmes de capacité, de menaces malveillantes ou accidentelles, de certificats arrivant à expiration ou, comme d'habitude, de pannes DNS, pannes de système font partie de la vie quotidienne.

Plus les changements peuvent être annulés rapidement, ou les systèmes adaptés manuellement ou automatiquement pour restaurer les services, plus les performances de l'équipe sont élevées et plus l'expérience client et la valeur fournie sont bonnes. Pour améliorer le temps moyen de restauration, il faut réduire la taille des lots de changements, construire et utiliser des systèmes plus résilients et distribués, permettre des défaillances graduelles des composants grâce à un découplage et à une mise en file d'attente appropriés, ainsi qu'à une surveillance et à des alertes efficaces.

En termes de mesure, vous devez savoir quand l'incident s'est produit (et pas seulement quand il a été observé ou enregistré pour la première fois) et quand il a été résolu. Veillez à définir ce que signifie "résolu" : "résolu" peut-il signifier que le système fonctionne dans un état dégradé mais qu'il est disponible, ou existe-t-il un état optimal "souhaité" du système ? Dans ce dernier cas, vous aurez probablement besoin d'indicateurs de niveau de service (SLI) pour vous assurer que tout le monde est d'accord sur l'état souhaité.

Indicateur : Taux d'échec des changements (CFR)

Répond à : "À quelle fréquence nos déploiements entraînent-ils une défaillance en production ?"

Différentes estimations ont été faites pour montrer combien de changements dans la production entraînent des défaillances du système, et elles vont de 5% à plus de 50%. Les défaillances résultant des changements ont un impact sur l'expérience du client et obligent l'équipe à passer de la livraison de la valeur planifiée à un travail de lutte contre les incendies non planifié. Le travail non planifié a toujours la priorité sur le travail planifié.

Les risques de défaillance augmentent avec les systèmes complexes et de grande envergure dont les composants sont étroitement liés. De même, si les processus de développement n'incluent pas de tests unitaires ou d'intégration appropriés ni d'analyse statique du code, et si les pratiques de l'équipe de développement n'incluent pas le pair programming ou la peer review, les risques d'échec sont plus élevés. Pour réduire le taux d'échec des modifications, il faut renforcer la capacité à intégrer la qualité plus tôt dans le cycle de développement des logiciels.

Pour mesurer cela, nous devons connaître le volume de déploiements et le volume d'incidents. Nous devrions également être en mesure d'établir un lien et de démontrer la causalité entre le déploiement et l'incident, qui peut n'être évident que quelque temps après le fait, et peut se produire des semaines ou des mois après le changement initial.