Le Temps moyen de restauration indique le temps nécessaire pour rétablir le service suite à un déploiement en échec. Il s'agit essentiellement du temps que votre équipe met pour analyser, préparer et déployer un correctif en production.
Faisant partie des métriques DORA (lien vers la page officielle, anglais), cette mesure ainsi que le Taux d'échec des modifications permettent de mesurer la stabilité d’une équipe de développement et la qualité du code livré.
Vous pouvez afficher le délai de changement pour la période du dernier mois, des trois derniers mois ou encore des 6 derniers mois. Vous pouvez également préciser l'environnement à afficher, soit production ou staging.
Il est à noter que vous devez configurer un (ou plusieurs) webhook, source(s) d'incident(s), ainsi que vos environnements de déploiement afin de synchroniser les données nécessaires à la mesure de cette donnée.
Lecture du graphique
Pour le graphique suivant, la période affichée correspond aux trois derniers mois et, dans l’ensemble, nous pouvons voir que l’équipe a un temps moyen de restauration de 4 jours et 5 heures pour cette période. Selon le rapport sur l'état du DevOps en 2022, ce délai de changement correspond aux critères d'évaluation pour une équipe à moyenne performance.
Ce graphique ressemble beaucoup au niveau de service attendu (SLE) pour les items (processus) ou les revues de code (technique), tant par son format que par les données présentées lorsque vous le survolez. Pour notre exemple, nous pouvons voir que le bogue PAN-3630 a été résolu 2 heures après avoir été rapporté (donc créé dans Jira pour notre exemple), la résolution correspondant au déploiement effectué à 12h44 le 8 février 2023.
Un temps moyen de restauration élevé démontre que l'équipe met du temps à corriger les problèmes détectés. Généralement, nous visons à avoir un temps de restauration court, voire même similaire ou équivalent au délai de changements. Un déploiement en échec entraine un investissement en temps et efforts à rétablir la situation. Donc un temps de restauration plus court permet l'allocation de ces ressources à la création de valeur.
Lorsque corrélé aux autres métriques DORA, il peut témoigner de processus de gestion d'incidents inefficaces. Par exemple, une réticence à changer de focus pour résoudre l'incident, des dépendances ou autres éléments empêchant l'équipe de déployer rapidement en production.
Psst! Consultez notre article de blogue pour en savoir plus sur les pistes de solutions permettant de réduire votre temps moyen de restauration!
Calcul de la métrique
Axify identifie et mesure le temps moyen de restauration de la façon suivante :
- Nous considérons
- Tout item de type bogue créé suite à un déploiement
- Tout item d'un type précis créé suite à un déploiement, lorsqu'une source d'incident précise a été ajoutée à Axify (disponible seulement pour certains utilisateurs en date du 10 avril 2023)
- La date de création de l'item représente le moment où l'échec a été détecté, donc quand l'incident a débuté
- La date de déploiement (ou date a laquelle le bogue a été déplacé à "done") représente le moment où le problème a été résolu, donc quand l'incident s'est terminé