Le délai de rétablissement du service expliqué (métrique DORA)

Dans l’environnement évolutif d’aujourd’hui, il est crucial de détecter rapidement une défaillance et de pouvoir rétablir le système dès que possible. Différentes pratiques ont été introduites pour rendre les équipes d’ingénieurs plus efficaces et plus souples dans le processus de rétablissement du système. Pour les équipes logicielles, le temps passé sur les bogues et la réparation d’une panne est un coût d’opportunité pour apporter une nouvelle valeur au produit.

Dans cet article, nous abordons la question du délai de rétablissement du service, l’une des mesures clés de DORA.

Métriques DORA — Présentation rapide

Basé sur une étude d’accélération DevOps, en 2015, Google a établi le programme appelé groupe DORA (DevOps Research and Assessment). En 2018, ils ont publié leur étude Accelerate introduisant les métriques DORA — un concept qui définit 4 métriques clés qui peuvent distinguer les équipes de développement très performantes des équipes moyennes : 

• Fréquence de déploiement — mesure la fréquence à laquelle le code est déployé avec succès dans un environnement de production. Les équipes d’ingénieurs ont tendance à livrer de nouvelles fonctionnalités aux clients dès que possible, et cette mesure est donc utile pour comprendre à quelle fréquence cela se produit.
• Délai nécessaire aux changements — cette mesure indique le temps nécessaire pour qu’un changement apparaisse dans l’environnement de production en examinant le délai moyen entre la première validation effectuée dans l’environnement de développement et le moment où cette fonctionnalité fonctionne avec succès dans la production.
• Délai de rétablissement du service — mesure le temps nécessaire au système pour se remettre d’un incident en production. Pour améliorer le délai de rétablissement du service, le service DevOps doit observer en permanence l’environnement de production.
• Taux d’échec des changements — mesure le pourcentage de déploiements provoquant un échec en production, et se calcule en divisant le nombre d’échecs par le nombre total de déploiements.

Les métriques DORA donnent aux chefs d’équipe des informations fiables, car ils peuvent analyser les métriques pour évaluer les performances de l’équipe. Ils peuvent alors améliorer leurs processus internes. En examinant le taux d’échec des changements et le temps de rétablissement du service, les responsables peuvent s’assurer que leur code est robuste et stable, tout en réduisant le nombre de perturbations. D’autre part, le suivi de la fréquence de déploiement et du délai nécessaire aux changements permet de s’assurer que l’équipe travaille à un rythme satisfaisant. Combinées, les mesures DORA fournissent des informations cruciales sur la qualité et la rapidité de l’équipe.

Qu’est-ce que le délai de rétablissement du service — Définition

Comme indiqué précédemment, le délai de rétablissement du service est un indicateur DORA qui mesure le temps nécessaire pour réparer le logiciel après un incident en production. En d’autres termes, le délai de rétablissement du service évalue la rapidité avec laquelle votre équipe peut détecter et résoudre les problèmes qui affectent vos systèmes logiciels. Il s’agit d’un indicateur important à suivre, car il vous aide à identifier les failles dans votre pipeline de livraison de logiciels et à l’optimiser en améliorant son efficacité.

Le temps de rétablissement du service doit être mesuré et communiqué régulièrement, c’est-à-dire quotidiennement, hebdomadairement ou mensuellement, afin de suivre l’évolution des délais de réponse aux incidents au fil du temps. Il s’agit de mesurer le temps nécessaire pour avertir les ingénieurs, diagnostiquer le problème, le résoudre, configurer et tester le système, et permettre un nouveau déploiement pour la production. Une augmentation du délai de rétablissement du service peut indiquer des problèmes dans le processus de réponse aux incidents ou dans la fiabilité du système.

Comment calculer le délai de rétablissement du service ? 

La formule pour calculer le temps de rétablissement du service est la suivante :
Temps de rétablissement du service = Temps d’arrêt total pour tous les incidents/Nombre d’incidents

Ainsi, si votre système a été indisponible pendant une heure lors de deux incidents distincts sur une période de 24 heures - 60 minutes divisées par deux font 30, le délai de rétablissement du service est donc de 30 minutes.

Pour calculer le délai de rétablissement du service, vous devez suivre les étapes suivantes :

• Enregistrer l’heure à laquelle l’incident s’est produit, c’est-à-dire l’heure à laquelle le système est devenu indisponible.

• Enregistrer l’heure de résolution de l’incident, c’est-à-dire l’heure à laquelle le système a été rétabli dans son état de fonctionnement normal.

• Calculer le temps d’indisponibilité en soustrayant l’heure de début de l’incident de l’heure de rétablissement.

• Compter le nombre d’incidents survenus au cours de la période observée.

• Pour obtenir le temps d’arrêt moyen par incident, calculez le temps d’arrêt total pour tous les incidents et divisez-le par le nombre d’incidents.

Indicateurs de performance pour le délai de rétablissement du service

Selon DORA, un groupement mondial de référence sur la performance, le délai moyen de rétablissement du service en cas d’incident est inférieur à un jour pour les entreprises les plus performantes et se situe entre une semaine et un mois pour les entreprises les moins performantes. Cet écart important est dû à plusieurs facteurs, notamment le nombre de billets en attente, le nombre d’utilisateurs (qui influe sur le temps de traitement des billets) et la complexité des billets. Les problèmes plus complexes entraînent des délais de résolution plus longs et un temps de rétablissement du service plus important.

Différents indicateurs de performance permettent de faciliter le suivi des valeurs du délai de rétablissement du service :

• Délai moyen de reconnaissance d’un incident — indique la rapidité avec laquelle l’organisation peut détecter un incident.

• Temps moyen de résolution de l’incident — la rapidité avec laquelle l’incident peut être résolu et l’entreprise peut reprendre ses activités normales.

• Taux de résolution des incidents — pourcentage d’incidents résolus avec succès au cours d’une période donnée.

• Taux d’escalade des incidents — fréquence à laquelle les incidents doivent être transmis à un niveau supérieur de gestion ou d’assistance.

Les lacunes du temps de rétablissement du service

Le délai de rétablissement du service est une mesure utile pour déterminer les temps de réponse aux incidents et identifier les moyens d’améliorer les processus, mais il présente encore certaines faiblesses :

• Il ne prend pas en compte le temps d’arrêt avant réparation, c’est-à-dire le temps écoulé entre l’apparition de l’incident et sa détection, qui peut être important dans certains cas.

• Le temps de rétablissement du service peut être fortement affecté par des déviations, par exemple des incidents rares et complexes dont la résolution prend beaucoup de temps.

• Ces incidents augmenteront le temps de rétablissement du service, ce qui rendra difficile l’évaluation de la réponse réelle à l’incident.

• Il ne tient pas compte de la gravité des incidents. Par conséquent, il peut ne pas vous fournir une image complète de l’efficacité du processus de réponse aux incidents, ou de l’impact des incidents sur les utilisateurs.

• Il ne mesure pas les activités de prévention (maintenance proactive) qui empêchent les incidents de se produire. 

Les causes d’un mauvais temps de rétablissement du service

Votre code peut être robuste et bien testé, et vous avez un bon taux d’échec des changements, mais vous risquez tout de même de vous retrouver avec une faible performance opérationnelle. Si votre application tombe en panne et que votre équipe ne dispose pas d’un bon processus pour détecter le problème, le résoudre et le déployer rapidement, votre délai de rétablissement (performance opérationnelle) sera faible. Les causes d’un mauvais délai de rétablissement du service peuvent être multiples :

• Pas d’outils appropriés pour la surveillance et l’observabilité — Le temps nécessaire pour mesurer le temps de rétablissement du service commence au moment où votre système devient indisponible, et non au moment où vous vous en rendez compte. La lenteur de la détection des problèmes se traduira par une lenteur de la reprise. La détection des problèmes est délicate pour les organisations qui n’utilisent pas d’outils de surveillance et d’observabilité. Pour éviter l’insatisfaction des utilisateurs et mener à bien leurs tâches, les équipes DevOps ont besoin d’un dispositif de surveillance du temps de fonctionnement, de services d’assistance, d’outils de test et d’alerte, etc.

• Processus de déploiement maladroits et lents — Même si votre équipe détecte rapidement un incident et y apporte une solution, si l’automatisation du déploiement est déficiente ou si le déploiement est manuel, le délai de rétablissement du service en souffrira. Un processus de déploiement manuel avec des étapes nécessitant une intervention humaine a un impact négatif à la fois sur la fréquence de déploiement et sur le délai de rétablissement du service. Vous devez donc disposer d’un processus de déploiement fluide et éventuellement automatisé.

• Pas de plan de gestion des incidents — lorsqu’un incident se produit, l’équipe DevOps subit le stress combiné d’une panne de système, d’utilisateurs frustrés et de parties prenantes déçues. Une fois qu’un problème est détecté et reconnu, vous devez avoir désigné une personne responsable et une procédure pour résoudre la situation. Si votre équipe n’a pas de plan sur la façon de gérer un incident, le temps nécessaire à l’élaboration d’un plan s’ajoutera à votre temps de rétablissement du service.

Comment améliorer le délai de rétablissement du service ?

Pour maintenir un faible délai de rétablissement du service, il convient de prendre en compte les meilleures pratiques suivantes :

• Adoptez une procédure efficace de traitement des incidents qui définit clairement les rôles, les responsabilités et les étapes en cas d’escalade. Veillez à ce que tous les membres de l’équipe soient formés à cette procédure et à ce qu’elle soit régulièrement révisée et mise à jour.

• Mettez en place un système de surveillance et d’alerte efficace pour vos systèmes logiciels. Cela vous aidera à détecter les problèmes rapidement et de manière proactive avant qu’ils n’affectent les utilisateurs.

• Des tests automatisés qui vous permettent de repérer l’incident plus rapidement, puisque vous disposez d’une suite de tests qui couvrent le code, ce qui vous permet de savoir plus rapidement où se situe le problème lorsque vous diagnostiquez le bogue.

• Effectuez des changements plus petits — des changements plus petits signifient qu’il est plus facile de « détecter » l’incident depuis le dernier changement.

• Pour identifier les domaines d’amélioration, examinez et analysez régulièrement les données relatives aux incidents. Mettez en œuvre des changements pour optimiser le processus de réponse aux incidents et réduire le temps de rétablissement du service.

• Effectuez une analyse approfondie des causes sous-jacentes de tous les incidents pour identifier les problèmes et y remédier afin d’éviter de nouveaux incidents.

• Automatisez les processus de réponse aux incidents, par exemple en automatisant les alertes, les diagnostics et les correctifs. Cela réduira le temps nécessaire à la résolution des incidents.

• Effectuez des tests fréquents pour identifier et résoudre les problèmes avant qu’ils n’affectent les utilisateurs. Cela permettra de prévenir les incidents et de réduire le délai de rétablissement du service.

• Favorisez une communication efficace entre les membres de votre équipe lors de la réponse aux incidents. Cela permet de résoudre rapidement les problèmes et de prévenir les incidents.

Une façon simple d’analyser le temps de rétablissement du service 

Les calculs manuels peuvent fournir des informations utiles, mais un outil automatisé comme Axify.io peut fournir un modèle pronostique du comportement du système et suivre le temps de rétablissement du service sans effort. Axify est une plateforme unique permettant d’observer tous les indicateurs de performance clé qui vous aideront à améliorer vos processus de développement et de livraison. Il est équipé de tableaux de bord de qualité supérieure et assure un suivi constant des métriques DORA en temps réel, ce qui simplifie l’ensemble du processus et permet aux équipes de se concentrer sur les améliorations à apporter.

Axify intègre les quatre métriques DORA :

• Délai de rétablissement du service — mesure le temps nécessaire au système pour se rétablir d’un incident en production.

• Fréquence de déploiement — mesure la fréquence à laquelle une organisation réussit à déployer en production. Cette mesure importante facilite les tests, les déploiements, les rétroactions et les corrections de problèmes, tout en augmentant la valeur perçue par vos clients.

• Délai nécessaire aux changements — temps qui s’écoule entre la première validation et l’exécution réussie du code en production. Cette mesure nous permet d’évaluer l’efficacité des cycles et des initiatives de développement de logiciels. Il tend à entraîner des changements organisationnels, humains et techniques.

• Taux d’échec des changements — mesure le pourcentage de déploiements entraînant un échec en production, et se calcule en divisant le nombre d’échecs par le nombre total de déploiements.

Avoir un œil sur le délai de rétablissement du service peut fournir des informations révélatrices sur l’état général du système. En vous efforçant de réduire ce délai, vous améliorerez la stabilité du système, ce qui favorisera la rationalisation des opérations et la satisfaction de l’équipe.