L’un des moyens les plus simples à comprendre et à mettre en œuvre consiste à utiliser des métriques. Les métriques permettent de suivre la santé de votre application et de votre infrastructure au fil du temps. Elles permettent de déterminer si vos pratiques de développement logiciel sont saines et offrent des pistes d’amélioration. Les métriques permettent également de quantifier le coût des interruptions de service, le stress des membres de l’équipe chargés du dépannage et de la correction des erreurs, et les dommages causés à vos clients en cas de problème.
Dans cet article, nous allons aborder deux des principaux ensembles de métriques utilisés dans le DevOps, DORA et MTTx.
DORA
DORA signifie DevOps Research and Assessment. Cette équipe a mené des recherches sur plusieurs années, puis mis au point quatre mesures clés qui indiquent les performances d’une équipe de développement de logiciels. Ces métriques sont les suivantes :
Fréquence de déploiement
À quelle fréquence lancez-vous des versions en production ? Celle-ci est assez simple, il vous suffit de compter le nombre de versions de production publiées sur une période donnée et de suivre l’évolution de ce chiffre. Les équipes DevOps performantes pratiquent le « déploiement continu », avec plusieurs déploiements par jour, parfois même plusieurs fois par heure. C’est la « norme de référence » des équipes DevOps. Même si vous n’en êtes pas encore là, le suivi de la fréquence de déploiement est une première étape essentielle.
Délai de livraison (pour les modifications)
Quel est le délai entre un commit dans votre base de code et sa mise en production ? Cette métrique est liée à la fréquence de déploiement, mais elle est un peu différente de la précédente. De nombreuses organisations déploient du code dans des branches de fonctionnalités. Même avec un rythme de déploiement soutenu, il peut arriver que les nouvelles fonctionnalités attendent dans des branches tandis que d’autres modifications (comme des corrections de bugs) sont apportées à la branche principale. Déterminer le temps qu’un commit moyen passe dans les limbes avant d’être publié et remis aux utilisateurs peut vous aider à déterminer la vitesse globale de votre pratique de développement logiciel. En combien de temps pouvez-vous présenter de nouvelles fonctionnalités à vos utilisateurs ?
Taux d’échec des modifications
Quel pourcentage de déploiements a causé un échec en production ? Encore une métrique assez simple. Combien de vos déploiements avez-vous finalement dû annuler, corriger ou manipuler à la suite d’un problème apparu en production ? Naturellement, l’objectif est de zéro, mais curieusement, un taux d’échec nul peut traduire un excès de prudence dans votre pratique de développement. Dans les équipes DevOps, trouver le juste milieu entre stabilité et innovation demande des talents d’équilibriste.
Temps de rétablissement du service
Combien de temps faut-il en moyenne pour se remettre d’un échec en production ? Une version qui se comporte de façon erratique, un coup de pelleteuse malheureux qui endommage la fibre devant votre datacenter, ou le serveur ue-east-1 qui fait des siennes... quel que soit le problème, combien de temps faut-il pour que vos utilisateurs ne soient plus affectés ? Il est extrêmement important de minimiser ce délai. Les problèmes sont inévitables dans toute architecture, mais une infrastructure robuste peut réduire leur impact et garantir que votre application continue à offrir toute sa valeur commerciale.
MTTx
En plus des métriques DORA, qui sont axées sur l’utilisation des développements logiciels, il existe une famille de métriques davantage centrées sur les opérations appelée MTTx, temps moyen de xxx. Voici une sélection des plus courantes :
MTTR
C’est tout simplement la dernière métrique DORA. En moyenne, combien de temps le système reste-t-il dégradé lorsqu’une erreur survient ? Cet acronyme signifie « temps moyen de résolution » et ce qu’il mesure est assez explicite : combien de temps, en moyenne, s’écoule-t-il entre le tout début d’un problème et le moment où son impact sur l’utilisateur est entièrement résolu ?
MTTD
La dernière lettre de celui-ci signifie « détection ». Cette métrique mesure le temps qu’il faut pour savoir que quelque chose ne va pas. Lorsqu’un problème survient, combien de temps faut-il pour que vous en soyez alerté ou que vous en preniez connaissance d’une manière ou d’une autre ? Cela peut prendre quelques secondes si toute l’application s’interrompt et lance des erreurs 503, mais cela peut aussi prendre plusieurs semaines si le problème n’affecte qu’un seul utilisateur qui ne prend pas la peine de se plaindre tant qu’il parvient à passer outre. Globalement, réduire cette métrique entraînera des améliorations dans toutes vos autres métriques.
MTTA
Le A signifie « Acknowledge », ou « reconnaissance », et cette métrique présente une petite nuance. À première vue, il s’agit simplement de mesurer le temps qu’il faut entre la détection d’un problème et sa reconnaissance par un opérateur du centre d’exploitation du réseau, un ingénieur en fiabilité des sites ou toute autre personne chargée de lancer le processus de triage et de résolution. Cependant, les opinions divergent quant au moment où l’on peut considérer qu’un problème est reconnu : est-ce celui où quelqu’un voit l’alerte, ou bien celui où l’alerte parvient à la personne chargée de la résolution ? À vous de choisir, mais selon moi la deuxième approche est bien plus précise et utile.
MTTC
Le C signifie « Clue », ou « indice ». Une fois l’incident reconnu, combien de temps faut-il avant que le destinataire de l’alerte sache réellement ce qui ne va pas et comment y remédier ? Des MTTC élevés suggèrent que votre environnement ou votre application est trop complexe, que vous n’avez pas assez de visibilité sur le déploiement ou que vos ingénieurs ont trop de choses à superviser et sont dans l’incapacité de circonscrire rapidement les problèmes lorsqu’on les appelle.
MTTI
Le I signifie « innocence » ici. C’est peut-être un peu ironique, mais c’est une métrique MTTx très importante dans les environnements modernes, où les responsabilités de la livraison et de l’exploitation des logiciels sont réparties entre de nombreuses équipes. Le MTTI est une mesure du temps qu’il faut, en moyenne, pour reconnaître qu’un problème n’est pas la faute de votre équipe. Quiconque a déjà déployé une application moderne sait que le responsable de l’infrastructure réseau est un bouc émissaire très pratique en cas de problème. Mais en allant immédiatement se plaindre à l’équipe des opérations réseau quand le problème a une toute autre cause, on ne fait que retarder le processus de dépannage global. Un MTTI court pour les équipes d’infrastructure réduit le MTTR global et contribue également à réduire la pression sur leurs membres.
Comment générer toutes ces métriques et les exploiter ?
Les outils d’observabilité et de supervision prennent en charge le calcul de bon nombre de ces métriques, soit directement, soit via des plugins. Elles peuvent également être calculées manuellement, même si cela en réduit fortement l’intérêt.
Le suivi de l’évolution de ces métriques vous donne de précieuses informations sur les performances de votre équipe, de votre infrastructure et de vos applications. Cela peut également vous aider à justifier des demandes de ressources et de temps supplémentaires.
Enfin, suivre à la fois sur les métriques MTTx et DORA donne vie au véritable état d’esprit DevOps : en examinant les performances des deux côtés, Dev et Ops, on peut mettre en place un langage et des objectifs communs et ainsi renforcer le travail d’équipe et la qualité globale de la livraison de logiciels.
Vous pouvez très facilement obtenir les métriques MTTx et DORA avec Splunk Observability Cloud, quels que soient l’endroit où votre application est déployée et sa complexité. Démarrez avec un essai gratuit de 14 jours (aucune carte de crédit demandée).
*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.
