Que sont les métriques DORA et quel impact ont-elles sur le succès de DevOps ?

Les métriques DORA sont quatre dimensions clés qui aident les chefs d’équipe à comprendre l’efficacité de leurs pratiques DevOps. L’ équipe de recherche et d’évaluation DevOps (DORA) a développé les métriques après six ans de recherche sur la mise en œuvre réussie de DevOps.

La mesure des données est le meilleur moyen d’évaluer l’impact de DevOps sur votre organisation. Se concentrer sur les aspects identifiés par DORA peut ouvrir des opportunités pour rationaliser vos processus et améliorer l’efficacité. Dans cet article, nous expliquerons comment chacune des quatre métriques contribue au succès de DevOps.

Fréquence de déploiement

La fréquence de déploiement mesure la fréquence à laquelle vous poussez le nouveau code en production. Étant donné que l’objectif principal de DevOps est de fournir un code fonctionnel plus efficacement, la fréquence de déploiement est un excellent point de départ pour mesurer le succès.

Vous pouvez collecter ces données simplement en analysant le nombre de fois où un nouveau code a été déployé au cours d’une période donnée. Vous pouvez ensuite rechercher des opportunités pour augmenter votre taux de libération sans sacrifier les clôtures qui maintiennent les normes de qualité. L’utilisation de la livraison continue pour déployer automatiquement le code lors de sa fusion est un moyen d’accélérer votre flux de travail.

La fréquence de déploiement idéale dépend du type de système que vous construisez. Bien que les applications Web soient généralement livrées plusieurs fois par jour ces jours-ci, cette fréquence ne convient pas aux développeurs de jeux qui créent des versions de plusieurs gigaoctets.

Dans certaines situations, il peut être utile de reconnaître cette différence en pensant un peu différemment à la fréquence de déploiement. Vous pouvez le considérer comme la fréquence à laquelle vous pourriez déployer du code si vous vouliez réduire la sortie d’une nouvelle version à un moment donné. Cela peut être un moyen plus efficace de mesurer le débit lorsqu’une véritable livraison continue n’est pas appropriée pour votre projet.

Modifier le délai de livraison

Le délai de modification est l’intervalle entre la validation d’une version de code et sa mise en production. Cette métrique montre les retards qui se produisent lors des revues de code et des itérations après que les développeurs ont terminé le sprint d’origine.

Il est facile de mesurer cette valeur. Vous devez trouver l’heure à laquelle le développeur a signé la modification, puis l’heure à laquelle le code a été livré aux utilisateurs. Le temps d’exécution est le nombre d’heures et de minutes entre les deux valeurs.

Par exemple, considérez un changement simple pour envoyer un e-mail d’avertissement de sécurité après la connexion des utilisateurs. Le développeur termine la tâche à 11 h 00 et valide son travail dans le référentiel d’origine. À midi, le réviseur lit le code et le soumet au contrôle qualité. À 14h00, un testeur QA a remarqué une faute de frappe dans la copie de l’e-mail. Le développeur valide le correctif à 15 h 00, et le contrôle qualité apporte la modification finale à la production à 16 h 00. Le temps pour effectuer ce changement était de 5 heures.

Le temps d’exécution est utilisé pour révéler les inefficacités lorsque le travail se déplace entre les éléments. Bien que les normes varient considérablement selon l’industrie et l’organisation, un délai moyen long peut être le signe de frictions internes et d’un flux de travail mal conçu. L’augmentation du temps d’exécution peut également être causée par de mauvaises performances des développeurs produisant un travail de mauvaise qualité lors de la première itération d’une tâche.

Certaines organisations utilisent des mesures de délais différentes. Beaucoup choisissent le temps qui s’écoule entre le lancement d’une fonctionnalité par un développeur et la mise en production du code final. D’autres peuvent aller encore plus loin et utiliser comme point de départ l’heure à laquelle le changement a été demandé par le client, le client ou le chef de produit.

Ces méthodes peuvent fournir des informations plus largement utiles au sein de l’entreprise, en dehors des équipes d’ingénierie. Cependant, l’interprétation de DORA à l’aide des horodatages de validation présente un gros avantage : les données sont automatiquement validées par votre outil de contrôle de version, de sorte que les développeurs n’ont pas à enregistrer manuellement l’heure de début de chaque nouvelle tâche.

Modifier le taux de rebond

Le taux d’échec des modifications correspond au pourcentage de déploiements de production ayant provoqué un incident. Un incident est une erreur ou un comportement inattendu qui provoque le blocage ou l’arrêt des clients. Les développeurs et les opérateurs devront passer du temps à résoudre le problème.

Vous pouvez calculer le pourcentage de modifications ayant échoué en divisant le nombre de déploiements que vous avez effectués par le nombre d’échecs. Cette dernière signification est généralement obtenue en marquant les rapports d’erreurs dans votre logiciel de gestion de projet de déploiement avec celui qui les a soumis.

Attribuer avec précision les incidents au changement qui les a provoqués peut parfois être délicat, surtout si vous avez une fréquence de déploiement élevée, mais dans de nombreux cas, les développeurs et les équipes de triage peuvent déterminer le déclencheur le plus probable. Un autre problème pourrait être de se mettre d’accord sur ce qui constitue un échec : les erreurs mineures doivent-elles augmenter la fréquence des échecs, ou êtes-vous uniquement intéressé par les échecs majeurs ? Les deux types de problèmes affectent la façon dont les clients perçoivent votre service, il peut donc être utile de conserver plusieurs valeurs différentes pour cette métrique, chacune faisant référence à différentes classes de problèmes.

Vous devez toujours vous efforcer de maintenir le taux d’échec aussi bas que possible. L’utilisation de tests automatisés, d’analyses statiques et d’intégration continue peut aider à empêcher le code défectueux d’être mis en production. Protégez vos processus avec de nouveaux outils et pratiques pour réduire progressivement les défaillances au fil du temps.

Il est temps de rétablir le service

Malheureusement, il est impossible d’éradiquer complètement les défaillances. Finalement, vous rencontrerez un problème qui nuira à vos clients. La quatrième métrique DORA, Time to Restore Service, analyse l’efficacité avec laquelle vous pouvez répondre à ces événements.

Comme pour la modification des délais, le délai mesuré peut varier selon l’organisation. Certaines commandes utiliseront l’heure à laquelle le bogue a été déployé, d’autres proviendront du premier rapport du client, et certaines peuvent utiliser l’heure à laquelle l’équipe de réponse aux incidents a été envoyée sur la page. Quel que soit le point de déclenchement que vous choisissez, vous devez l’utiliser de manière cohérente et continuer à mesurer jusqu’à ce que l’incident soit marqué comme résolu.

Un MTTR élevé indique que vos processus de réponse aux incidents doivent être affinés. Une réponse efficace dépend de la présence des bonnes personnes pour identifier le problème, développer une solution et communiquer avec les clients concernés. Vous pouvez réduire le temps de récupération en développant des procédures de réponse cohérentes, en centralisant l’accès aux informations critiques dans votre organisation et en mettant en œuvre une surveillance automatisée pour vous alerter des problèmes dès qu’ils surviennent.

L’optimisation de cette métrique est souvent négligée car trop d’équipes supposent qu’une panne majeure ne se produira jamais. Vous pouvez également avoir relativement peu de points de données avec lesquels travailler si votre service est généralement stable. Effectuer des répétitions de réponse aux incidents à l’aide de méthodes telles que les tests de chaos peut fournir des données plus significatives reflétant votre temps de récupération actuel.

Sommaire

Les quatre métriques DORA fournissent aux chefs d’équipe DevOps des données qui révèlent des opportunités d’amélioration. Mesurer et analyser régulièrement la fréquence de déploiement, modifier le délai d’exécution, modifier le taux d’échec et le temps de récupération du service vous aidera à comprendre vos performances et à prendre des décisions éclairées sur la façon de les améliorer.

Les métriques DORA peuvent être calculées manuellement à l’aide des informations de votre système de gestion de projet. Il existe également des outils comme les  » Four Keys  » de Google Cloud qui les génèrent automatiquement en fonction des informations de validation. Certains outils écosystémiques, tels que GitLab , commencent également à inclure un support intégré.

Les meilleures implémentations DevOps encourageront des changements rapides et des déploiements réguliers qui entraînent très rarement de nouveaux bugs. Toutes les régressions qui surviennent seront rapidement résolues, minimisant les temps d’arrêt afin que les clients aient la meilleure expérience possible avec votre service. Le suivi des tendances DORA au fil du temps vous permet de vérifier si vous atteignez ces idéaux, ce qui vous donne les meilleures chances de succès DevOps.