Que sont les métriques DORA et comment informent-elles le succès de DevOps ?
Agence web » Actualités du digital » Que sont les métriques DORA et comment informent-elles le succès de DevOps ?

Que sont les métriques DORA et comment informent-elles le succès de DevOps ?

Les métriques DORA sont quatre mesures clés qui aident les chefs d’équipe à comprendre l’efficacité de leurs pratiques de travail DevOps. Le groupe DevOps Research and Assessment (DORA) a développé les métriques après six ans de recherche sur l’adoption réussie de DevOps.

La mesure des données est le meilleur moyen d’évaluer l’effet que DevOps a sur votre organisation. Se concentrer sur les aspects identifiés par DORA peut révéler des opportunités d’optimiser vos processus et d’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 expédiez du nouveau code dans votre environnement de production. Comme l’objectif primordial de DevOps est de fournir un code fonctionnel plus efficacement, la fréquence de déploiement est un excellent point de départ lorsque vous évaluez le succès.

Vous pouvez collecter ces données en analysant simplement le nombre de fois où un nouveau code a été déployé sur une période donnée. Vous pouvez ensuite rechercher des opportunités pour augmenter votre taux de libération, sans sacrifier les garde-corps qui maintiennent les normes de qualité. L’utilisation de la livraison continue pour déployer automatiquement le code au fur et à mesure que vous le fusionnez 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 qu’il soit maintenant courant que les applications Web soient livrées plusieurs fois par jour, cette cadence n’est pas adaptée aux développeurs de jeux produisant des versions de plusieurs gigaoctets.

Dans certaines situations, il peut être utile de reconnaître cette différence en pensant à la fréquence de déploiement légèrement différemment. Vous pouvez l’aborder comme la fréquence à laquelle vous pourrait avez déployé du code, si vous vouliez couper une nouvelle version à un moment donné. Cela peut être un moyen plus efficace d’évaluer le débit lorsqu’une véritable livraison continue n’est pas viable pour votre projet.

Modifier le délai de livraison

Le délai d’exécution d’un changement est l’intervalle entre la validation d’une révision de code et son entrée dans l’environnement de production. Cette métrique révèle les retards qui se produisent lors de la révision et de l’itération du code, une fois que les développeurs ont terminé le sprint d’origine.

La mesure de cette valeur est simple. Vous devez trouver l’heure à laquelle le développeur a approuvé une modification, puis l’heure à laquelle le code a été livré aux utilisateurs. Le délai est le nombre d’heures et de minutes entre les deux valeurs.

Prenons l’exemple d’un changement simple pour envoyer un e-mail d’alerte de sécurité après la connexion des utilisateurs. Le développeur termine la tâche à 11h et valide son travail dans le référentiel source. À midi, un réviseur lit le code et le transmet au QA. À 14 heures, le testeur de l’équipe QA a remarqué qu’il y avait une faute de frappe dans la copie de l’e-mail. Le développeur valide un correctif à 15h et QA fusionne le changement final en production à 16h. Le délai de réalisation de ce changement était de 5 heures.

Le délai d’exécution est utilisé pour découvrir 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 élevé peut être le signe de frictions internes et d’un flux de travail mal pensé. Des délais d’exécution prolongés peuvent également être causés par des développeurs peu performants produisant un travail de mauvaise qualité lors de leur première itération sur une tâche.

Certaines organisations utilisent des mesures différentes pour le délai d’exécution. Beaucoup sélectionnent le temps qui s’écoule entre le début d’une fonctionnalité par un développeur et l’entrée en production du code final. D’autres peuvent regarder en arrière encore plus loin et utiliser le moment auquel un changement a été demandé – par un client, un client ou un chef de produit – comme point de départ.

Ces méthodes peuvent produire des informations plus largement utiles au sein de l’entreprise, en dehors des équipes d’ingénierie. L’interprétation de DORA utilisant les horodatages de validation présente cependant un gros avantage : les données sont capturées automatiquement par votre outil de contrôle de source, de sorte que les développeurs n’ont pas besoin d’enregistrer manuellement les heures de début pour chaque nouvelle tâche.

Modifier le taux d’échec

Le taux d’échec des modifications correspond au pourcentage de déploiements en production qui provoquent un incident. Un incident est un bogue ou un comportement inattendu qui provoque une panne ou une perturbation pour les clients. Les développeurs et les opérateurs devront passer du temps à résoudre le problème.

Vous pouvez calculer votre taux d’échec de changement en divisant le nombre de déploiements que vous avez effectués par le nombre qui a conduit à une erreur. Cette dernière valeur est généralement acquise en étiquetant les rapports de bogues dans votre logiciel de gestion de projet avec le déploiement qui les a introduits.

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, il est possible pour les développeurs et les équipes de triage de déterminer le déclencheur le plus probable. Un autre défi peut être de s’entendre sur ce qui constitue un échec : les bogues mineurs doivent-ils augmenter votre taux d’échec, ou êtes-vous uniquement intéressé par les pannes majeures ? Les deux types de problèmes ont un impact sur 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 examinant une classe de problème différente.

Vous devez toujours viser à réduire autant que possible le taux d’échec des modifications. L’utilisation de tests automatisés, d’analyses statiques et d’une intégration continue peut aider à empêcher le code défectueux d’atteindre la production. Protégez vos processus avec de nouveaux outils et méthodes de travail pour réduire progressivement le taux d’échec au fil du temps.

Il est temps de rétablir le service

Malheureusement, les échecs ne peuvent pas être complètement éradiqués. Vous finirez par rencontrer un problème qui causera de la douleur à vos clients. La quatrième métrique DORA, Time to Restore Service, analyse l’efficacité avec laquelle vous pouvez répondre à ces événements.

De la même manière que pour modifier le délai d’exécution, la durée mesurée peut varier d’une organisation à l’autre. Certaines équipes utiliseront l’heure à laquelle le bogue a été déployé, d’autres partiront du premier rapport client, et certaines pourront prendre l’heure à laquelle l’équipe de réponse à l’incident a été appelée. Quel que soit le point de déclenchement que vous adoptez, vous devez l’utiliser de manière cohérente et continuer à mesurer jusqu’à ce que l’incident soit marqué comme résolu.

Un temps de récupération moyen élevé indique que vos processus de réponse aux incidents doivent être affinés. Des réponses efficaces dépendent de la disponibilité des bonnes personnes pour identifier le défaut, développer un correctif et communiquer avec les clients concernés. Vous pouvez réduire le temps de restauration en développant des procédures de réponse convenues, en gardant les informations critiques accessibles de manière centralisée dans votre organisation et en introduisant 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. L’exécution de répétitions de réponse aux incidents à l’aide de techniques telles que les tests de chaos peut fournir des données plus significatives, représentatives de 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. La mesure et l’analyse régulières de votre fréquence de déploiement, de votre délai de modification, de votre taux d’échec de modification et du temps de restauration du service vous aident à comprendre vos performances et à prendre des décisions éclairées sur la manière 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 tels que Four Keys de Google Cloud qui les généreront automatiquement à partir des informations de validation. Certains outils écosystémiques comme GitLab commencent également à inclure un support intégré.

Les meilleures implémentations DevOps faciliteront les changements rapides et les déploiements réguliers qui introduisent très rarement de nouvelles erreurs. Toute régression qui se produit sera traitée rapidement, minimisant les temps d’arrêt afin que les clients aient la meilleure impression de 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.

★★★★★