Nous constatons qu’un nombre croissant d’organisations se concentrent à nouveau sur l’adoption et l’amélioration de leurs pratiques DevOps pour aider à optimiser leur cycle de vie de développement de logiciels et améliorer leur vitesse de livraison pour atteindre les marchés et les clients plus rapidement. Voici tout ce que vous devez savoir sur les quatre métriques DevOps clés et sur la manière dont les équipes peuvent utiliser ces métriques pour améliorer l’efficacité et les performances des développeurs afin de créer des produits meilleurs et plus rapides pour leurs clients.
Que sont les métriques DevOps ?
Les métriques DevOps sont les points de données utilisés pour mesurer les performances et l’efficacité du processus de développement logiciel DevOps d’une équipe. Étant donné que DevOps intègre à la fois les fonctions de développement et d’exploitation, les métriques doivent pouvoir mesurer et optimiser les performances des processus et des personnes impliquées.
La mesure et la collecte d’informations à partir des métriques DevOps peuvent aider les responsables à recueillir des informations exploitables sur les processus et les goulots d’étranglement de leur équipe et à prendre des mesures correctives rapides en cas de blocage. Ainsi, les métriques DevOps permettent aux équipes de réussir leurs objectifs.
Les quatre métriques DevOps clés
L’équipe de recherche et d’évaluation DevOps (DORA) de Google a identifié quatre mesures cruciales qui peuvent indiquer et optimiser la santé des performances DevOps. Le projet DORA Four Keys vise à générer des données précieuses et à recueillir des informations pour amplifier la productivité de l’ingénierie autour des pratiques DevOps. Vous trouverez ci-dessous les quatre métriques DevOps de base, plus communément appelées métriques DORA :
- Fréquence de déploiement : Mesure la fréquence à laquelle une équipe publie avec succès des modifications en production, indiquant la vitesse à laquelle l’équipe livre le logiciel.
- Modifier le délai : Le temps entre le début du travail sur une demande de modification et le moment où elle est mise en production et par conséquent donnée au client est appelé délai de modification. Les équipes utilisent le délai d’exécution pour déterminer l’efficacité du processus de développement.
- Modifier le taux d’échec : Mesure la vitesse à laquelle les changements de production provoquent une défaillance après la publication. C’est un indicateur de la qualité du code produit par une équipe.
- Temps moyen de restauration : Mesure le temps qu’il faut pour qu’un incident ou un échec soit résolu par un changement de production.
Alors que les mesures de la fréquence de déploiement et du délai de modification calculent la vélocité d’une équipe, les mesures du taux d’échec des modifications et du temps moyen de restauration se concentrent sur la stabilité du logiciel.
Selon le rapport Accelerate State of DevOps 2019, ce format des métriques DevOps analyse et classe les équipes en performances faibles, moyennes, élevées et élites, ces dernières étant deux fois plus susceptibles d’atteindre ou de dépasser leurs objectifs de performance organisationnelle. En utilisant ces indicateurs, les organisations peuvent suivre et améliorer les performances des équipes et l’efficacité des processus.
Fréquence de déploiement
La fréquence de déploiement d’une équipe se traduit directement par la rapidité avec laquelle elle déploie les codes ou les versions en production. Cette métrique DevOps peut varier selon les équipes, les fonctionnalités et les organisations. Cela dépend également du produit et des critères de déploiement interne. Par exemple, certaines applications peuvent ne s’engager que sur quelques grandes versions par an, tandis que d’autres peuvent effectuer de nombreux petits déploiements en un seul trimestre.
Comment la fréquence de déploiement affecte les affaires
Un taux de fréquence de déploiement plus élevé peut indiquer que les équipes suivent, améliorent ou déploient plus rapidement de nouvelles fonctionnalités sur le marché. Une fréquence de déploiement plus élevée ouvre également la voie à une boucle de rétroaction constante entre les clients et l’équipe qui se traduit par de meilleures versions du produit mises à la disposition de l’utilisateur final. La recherche de Google sur DORA suggère également que les équipes proactives ont des fréquences de déploiement plus élevées, ce qui signifie qu’elles peuvent se déployer à la demande de manière cohérente.
Comment le mesurer
Le suivi de la fréquence de déploiement sur une période prolongée peut aider à suivre le changement de vitesse, à détecter les goulots d’étranglement et à prendre des mesures correctives plus rapidement. Un moyen efficace de mesurer la fréquence de déploiement consiste à collecter des données auprès de GitHub, Jira et d’autres pour déterminer si les codes prévus sont expédiés. Cela permet non seulement aux responsables de suivre la fréquence de déploiement, mais également d’éliminer les bloqueurs, car l’accent mis régulièrement sur la fréquence de déploiement met en lumière les déploiements manqués et comprend le schéma et la raison qui les sous-tendent.
Conseils pour atteindre une fréquence de déploiement plus élevée
- Automatisez les tâches répétitives dans le processus de déploiement et configurez et configurez les pipelines de livraison continue
- Apporter des améliorations continues aux versions pour optimiser le résultat final
- Obtenez des commentaires constants sur les améliorations uniquement lorsque cela est nécessaire
- Soyez clair sur les exigences et les attentes, ne laissant aucune place aux glissements de portée indésirables
- Optimiser les temps de cycle pour être plus efficace afin de garantir que les déploiements se produisent à intervalles réguliers
Modifier le délai de livraison
Les équipes utilisent le délai de modification (à ne pas confondre avec le temps de cycle/délai) pour déterminer l’efficacité de leur processus de développement. Les longs délais peuvent être dus à une procédure inefficace ou à un goulot d’étranglement dans le pipeline de développement ou de déploiement. Les équipes visent souvent des délais plus courts, mais un délai plus long n’est pas toujours un signe de problème. Certaines versions peuvent être complexes et peuvent nécessiter plus de temps pour être livrées.
Comment le changement de délai affecte-t-il l’entreprise ?
La métrique LTC permet de suivre les inefficacités du processus. L’un des principaux objectifs de l’optimisation des délais est d’augmenter le déploiement grâce à l’automatisation, principalement le processus de test, afin de raccourcir le délai global de déploiement. Comme la fréquence de déploiement, le délai peut également varier selon les équipes et les produits. Par conséquent, les organisations doivent suivre, établir des repères et comparer les performances des équipes individuelles au fil du temps plutôt que de les comparer avec d’autres équipes.
Comment le mesurer
Le délai d’exécution est calculé en mesurant le temps entre la validation initiale et la date à laquelle la version est mise en production. Étant donné que les délais d’exécution consistent en plusieurs étapes du cycle de développement, les équipes doivent calculer le temps à chaque étape du processus de développement pour identifier les goulots d’étranglement. Garder une trace du temps de cycle peut aider à comprendre les différentes étapes du processus de développement, à identifier les zones problématiques et à en effectuer l’ACR. Faire cela de manière cohérente permet de découvrir les goulots d’étranglement et de mieux élaborer des stratégies dans tous les cycles de développement futurs.
Conseils pour optimiser les délais
Un facteur crucial pour arriver à un délai plus court est l’amélioration de la collaboration entre les équipes de test et de développement afin d’améliorer l’assurance qualité. Cela aide le responsable à mieux comprendre le temps de cycle DevOps.
- Les tests automatisés peuvent éliminer les efforts en double et les changements triviaux qui accaparent le temps du développeur.
- Travailler par petits incréments pour rester au top du module actuel afin de s’assurer qu’il n’y a pas d’erreurs qui pourraient nécessiter une refonte à l’avenir.
- Apportez les modifications à la version dupliquée afin que le code principal ne soit pas compromis.
Modifier le taux d’échec
Le taux d’échec des modifications mesure le pourcentage de déploiements qui échouent en production, nécessitant une correction de bogue ou une restauration. Cette métrique DevOps vérifie le nombre de déploiements effectués par rapport au nombre d’échecs pour décoder l’efficacité du processus DevOps.
Comment le taux d’échec du changement affecte le processus de développement
Les métriques de taux d’échec de changement suivent le temps passé à résoudre les problèmes au lieu de développer de nouveaux projets. Cela aide les responsables à comprendre où leurs équipes consacrent leurs efforts et aide à aligner les équipes et les processus pour passer plus de temps à écrire un nouveau code plutôt qu’à gérer les erreurs et les retouches.
Comment le mesurer
En divisant le nombre d’échecs de déploiement par le nombre total de déploiements, on obtient le CFR. Les équipes doivent s’assurer que les taux d’échec des changements sont au minimum. Mais cela ne signifie pas non plus passer trop de temps à créer et à tester chaque module, car cela pourrait avoir un impact sur le délai de livraison.
Conseils pour optimiser l’échec du changement
L’échec d’une modification n’indique pas toujours qu’un code est mal exécuté. Parfois, des facteurs externes tels que des exigences peu claires ou des bogues mineurs peuvent entraîner l’échec du programme.
- S’assurer que les codes sont écrits, révisés et testés conformément au plan de sprint
- Garder sous contrôle les métriques de vitesse de sprint et de désabonnement du code peut fournir des informations sur les changements apportés et la raison qui les sous-tend
Temps moyen de récupération (MTTR)
Le MTTR est la mesure du temps nécessaire aux contre-mesures pour résoudre un problème après le déploiement. La capacité d’une équipe à se remettre rapidement d’une panne dépend de sa capacité à reconnaître une panne (MTTD) dès qu’elle se produit et à publier une solution ou à annuler les modifications qui ont causé la panne. Ceci est normalement accompli en surveillant en permanence la santé du système et en avertissant le personnel d’exploitation chaque fois qu’une panne se produit.
Impact du MTTR sur le processus de développement
Le MTTR teste la vitesse à laquelle une équipe est capable de résoudre des bugs ou des incidents. Les équipes performantes récupèrent rapidement des incidents, tandis que les équipes moins performantes peuvent prendre jusqu’à une semaine ou plus pour récupérer. La mesure du MTTR est une pratique cruciale pour assurer la résilience et la stabilité.
Comment le mesurer
Le MTTR peut être mesuré en calculant le temps entre le moment où l’incident se produit et le moment où il est résolu. Pour résoudre les incidents, les équipes opérationnelles doivent être équipées des bons outils, protocoles et autorisations.
Conseils pour optimiser le MTTR
Pour obtenir des métriques MTTR rapides, déployez le logiciel par petits incréments pour réduire les risques et déployez des solutions de surveillance automatisées pour anticiper les échecs.
- Construire des systèmes plus robustes qui sont testés avant une version
- Une meilleure journalisation fournit les données pour diagnostiquer et trouver le problème plus rapidement en cas de panne
- Ceci peut être réalisé en vérifiant constamment les erreurs et les bloqueurs
Stratégies pour améliorer les métriques DORA
Focus sur le cadre
Le simple fait d’avoir les métriques DORA en place n’améliore pas le processus de développement. Les responsables doivent également élaborer des stratégies sur la manière d’exploiter et de renforcer les métriques DORA. La meilleure façon de le faire est de comparer la position actuelle de l’équipe et de dessiner une feuille de route des objectifs et des plans…