Data Insider

Qu’est-ce que le temps moyen de réparation (MTTR) ?

Le temps moyen de réparation est un indicateur essentiel qui représente le temps moyen nécessaire pour réparer et rétablir la fonctionnalité d’un composant ou d’un système. À ce titre, le MTTR est un indicateur majeur de la simplicité de maintenance des systèmes d’une entreprise, de ses équipements, applications et infrastructures, et de l’efficacité de la correction en cas d’incident informatique.

Le MTTR commence à l’instant où une défaillance est détectée et englobe le temps de diagnostic, de correction et de test, ainsi que toutes les autres activités permettant de remettre le service à disposition des utilisateurs finaux. Un MTTR faible indique qu’un composant ou un service peut être réparé rapidement, et donc que tous les problèmes informatiques associés n’auront probablement qu’un faible impact sur l’entreprise. Un MTTR élevé indique au contraire que la défaillance d’un dispositif peut entraîner une interruption de service importante qui aura un effet plus sensible sur les activités.

Selon ZK Research, 90 % du MTTR est consacré à simplement déterminer s’il y a réellement un problème. Un diagnostic incorrect ou des réparations inadaptées peuvent également prolonger le MTTR. Un MTTR élevé doit inciter les administrateurs IT à réévaluer leur approche du dépannage en tenant compte de l’intégralité du cycle de vie, de la méthode de surveillance et de détection à l’approche de diagnostic et de résolution, dans le but de réduire les interruptions potentielles.

La plupart des accords de niveau de service incluent une forme ou une autre de MTTR. Il est essentiel de garder à l’esprit que le MTTR correspond à un temps de réparation typique et non à une garantie. Un fournisseur qui affiche un MTTR de 24 heures indique le temps qu’il lui faut généralement pour effectuer une réparation, mais certains incidents peuvent prendre plus ou moins de temps.

Selon le contexte dans lequel il est utilisé, le MTTR peut également désigner le temps moyen de restauration ou le temps moyen de résolution. Dans tous les cas, le terme représente le temps requis en moyenne pour dépanner et corriger un problème.

Qu’est-ce que le MTTR : Sommaire

Ressources complémentaires

Prédictions | Les tendances et technologies IT qui façonneront 2021

Bases du MTTR

Que sont les métriques de défaillance ?

Les métriques de défaillance sont des indicateurs de performance qui permettent à une entreprise de suivre la fiabilité de ses machines et systèmes, des demandes d’assistance courante telles que le dépannage d’un ordinateur portable ou un problème de connectivité, aux défaillances de serveurs ou autres composants dysfonctionnels pouvant avoir un impact grave. Le terme de « défaillance » ne désigne pas seulement les dispositifs ou systèmes non fonctionnels (comme un serveur de fichiers en panne), il s’applique également aux systèmes qui fonctionnent mais qui, en raison d’une dégradation des performances, ont été mis hors service intentionnellement. Tout système qui n’atteint pas ses objectifs peut être considéré comme défaillant.

On recense plusieurs métriques de défaillance courantes :

  • Temps moyen de réparation (MTTR) : temps moyen nécessaire pour réparer et restaurer un système défaillant. C’est une mesure de la capacité à maintenir un composant ou un service réparable. Selon la complexité du dispositif et du problème, le MTTR peut se mesurer en minutes, en heures ou en jours. (Peut également désigner le temps moyen de restauration ou le temps moyen de résolution.)
  • Temps moyen entre deux pannes (MTBF) : temps opérationnel moyen entre une défaillance d’un dispositif ou d’un système et une autre. Les entreprises utilisent le MTBF pour prédire la fiabilité et la disponibilité de leurs systèmes et composants. Il peut être calculé en suivant le temps écoulé entre deux défaillances de système ou de composant au cours des opérations normales.
  • Temps moyen avant défaillance (MTTF) : durée moyenne pendant laquelle un dispositif ou un système est censé fonctionner avant de tomber en panne. Généralement, les équipes IT recueillent ces données en observant les composants du système pendant plusieurs jours ou semaines. S’il est similaire au MTBF, le MTTF est normalement employé pour décrire les éléments remplaçables telles qu’un lecteur de bande dans un ensemble de sauvegarde, alors que le MTBF est utilisé pour les composants qui peuvent être réparés ou remplacés.
  • Temps moyen de détection (MTTD) : temps moyen qui s’écoule entre le déclenchement d’un problème et le moment où l’entreprise le détecte. Le MTTD décrit la durée qui sépare le moment où l’IT reçoit un ticket et où elle démarre le compteur du MTTR.
  • Temps moyen d’investigation (MTTI) : durée moyenne qui sépare la détection d’un incident IT du moment où l’organisation commence à investiguer ses causes et sa résolution. Il décrit le temps qui s’écoule entre le MTTD et le début du MTTR.
  • Temps moyen de rétablissement du service (MTRS) : temps moyen qui s’écoule entre la détection d’un incident et le moment où le système ou le composant affecté est remis à la disposition des utilisateurs. Le MTRS diffère du MTTR car ce dernier indique le temps qu’il faut pour réparer un composant, tandis que le MTRS décrit le temps nécessaire pour rétablir le service une fois le composant réparé.
  • Temps moyen entre incidents système (MTBSI) : temps moyen qui s’écoule entre la détection de deux incidents consécutifs. Le MTBSI peut se calculer en additionnant le MTBF et le MTRS (MTBSI = MTBF + MTRS).
  • Taux de défaillance : autre indicateur de fiabilité, qui mesure la fréquence à laquelle un composant ou un système tombe en panne. Il s’exprime sous la forme d’un nombre de défaillances sur une unité de temps.

Les métriques de défaillance sont essentielles pour gérer les coupures et leur impact néfaste potentiel sur l’entreprise. Elles fournissent à l’IT les données quantitatives et qualitatives nécessaires pour mieux anticiper et prendre en charge les défaillances inévitables du système.

Pour utiliser efficacement les métriques de défaillance, vous devez recueillir une grande quantité de données spécifiques et précises. Cette tâche peut être fastidieuse si elle est réalisée manuellement, mais les logiciels modernes peuvent facilement collecter les données nécessaires et calculer ces indicateurs en puisant dans une variété de sources, et ce en quelques clics seulement.

process-mining-business-process-flowchart

Que sont la fiabilité, la disponibilité et la capacité de maintenance ?

La fiabilité, la disponibilité et la capacité de maintenance, parfois désignées sous l’acronyme anglais RAM, sont des attributs de la conception des systèmes qui influencent le coût de leur cycle de vie et leur capacité à remplir leur fonction. À ce titre, la RAM peut mesurer la confiance qu’une entreprise a dans ses machines, ses logiciels et ses réseaux.

Chacun de ces attributs éclaire les forces et les faiblesses d’un système ainsi que leur impact sur la productivité, la satisfaction des clients et les revenus de l’entreprise.

  • La fiabilité désigne la probabilité qu’un système va remplir sa fonction désignée sans défaillance pendant une période donnée. Comme la fiabilité est, dans une certaine mesure, fonction de la qualité d’un produit, c’est une caractéristique intrinsèque des différents composants d’un système (et de sa conception). Toutefois, toutes les machines et tous les logiciels sont sujets à tomber en panne, et des indicateurs tels que le MTBF, le MTTF et le taux de défaillance sont souvent employés pour mesurer et prédire la fiabilité des composants et des systèmes.
  • La disponibilité est la probabilité qu’un système fonctionne comme prévu lorsqu’il doit être utilisé. Elle est donc fonction à la fois de la fiabilité et de la capacité de maintenance, et peut être calculée en divisant le MTBF par la somme du MTBF et du MTTR (A = MTBF / (MTBF + MTTR).)
  • La capacité de maintenance décrit l’aisance et la vitesse avec lesquelles un système et ses composants peuvent être réparés ou remplacés puis remis en fonctionnement normal après une défaillance. La capacité de maintenance d’un système dépend d’un grand nombre de facteurs : qualité de l’équipement et de son installation, compétence et disponibilité du personnel informatique, adéquation et efficacité des procédures de maintenance et de réparation. Le MTTR est l’une des métriques de référence employée pour déterminer la capacité de maintenance d’un composant ou d’un système, et un MTTR bas indique une capacité de maintenance élevée.

Dans son ensemble, la RAM permet de déterminer les tendances de fonctionnement (fiabilité) et de coupure (capacité de maintenance) d’un système, ainsi que son taux de fonctionnement sur une période donnée (disponibilité).

Comprendre l’importance du MTTR

Comme le MTTR mesure ostensiblement la durée pendant laquelle des systèmes stratégiques sont hors service, c’est un indicateur puissant de l’impact qu’un incident IT aura sur les résultats de l’entreprise. Plus le MTTR d’une équipe IT est élevé, et plus l’entreprise court le risque de subir une coupure importante en cas d’incident, pouvant entraîner de graves perturbations dans son fonctionnement, une insatisfaction des clients et une perte de revenus.

Les défaillances technologiques sont inévitables. Comprendre le MTTR donne aux entreprises une idée de la vitesse et de l’efficacité avec lesquelles elles peuvent espérer y répondre et rétablir leurs opérations. Dans l’ensemble, un MTTR bas est le signe d’un environnement informatique sain et d’une fonction IT performante.

Quelle est la différence entre le MTTR et le MTBF ?

Pour résumer, le MTBF indique à une entreprise à quelle fréquence son équipement tombe en panne, tandis que le MTTR lui montre à quelle vitesse elle peut le remettre en service. Ces indicateurs peuvent toutefois être utilisés ensemble pour calculer la disponibilité d’un système. L’objectif de l’entreprise doit être à la fois de réduire le MTTR et d’augmenter le MTBF pour minimiser ou éviter les interruptions non prévues.

Comment le MTTR est-il calculé ?

Le MTTR est calculé en divisant la durée totale d’interruption causée par des pannes par le nombre total de pannes. Si, par exemple, un système tombe en panne trois fois dans un même mois et que ces défaillances ont entraîné 6 heures d’interruption, le MTTR est de deux heures.

MTTR = 6 heures / 3 pannes = 2 heures

Si les réparations peuvent prendre quelques minutes ou plusieurs jours, selon la gravité de la défaillance, le MTTR des systèmes IT est généralement mesuré en heures.

Application du MTTR

Qu’est-ce que le MTTR dans l’ITIL ?

Le MTTR est un indicateur clé inclus dans la bibliothèque d’infrastructure IT (ITIL). ITIL est une série d’ouvrages qui décrivent des bonnes pratiques pour mieux aligner la gestion des services IT (ITSM) sur les besoins de l’entreprise. Elle comprend actuellement cinq publications principales qui cartographient le cycle de vie des services ITIL, depuis « l’identification des besoins du client et des sources de spécifications IT, puis la conception et la mise en œuvre des services, jusqu’à la phase finale de surveillance et d’amélioration du service », selon Axelos, propriétaire actuel de la licence de la bibliothèque.

ITIL répartit les fonctions IT en plusieurs processus mesurables : gestion du catalogue de services, gestion à l’échelle des services, gestion du risque, gestion des capacités, gestion de la disponibilité, gestion de la continuité des services IT, gestion de la conformité, gestion de l’architecture IT et gestion des fournisseurs.

Le MTTR fait partie du processus de gestion de la disponibilité, dont l’objectif est de « veiller à ce que l’ensemble de l’infrastructure, des processus, des outils, des rôles, etc. de l’IT soient adaptés aux objectifs de disponibilité convenus ». Le MTTR s’accompagne des MTBF, MTBSI et MTRS, indicateurs de la gestion des incidents et des problèmes pouvant être inclus dans un accord de niveau de service (SLA).

Qu’est-ce que le MTTR dans le DevOps?

Dans le domaine du DevOps, où il désigne normalement le temps moyen de rétablissement, le MTTR est employé pour mesurer le temps nécessaire à l’équipe DevOps pour se rétablir après une défaillance en production. Dans ce contexte, il est généralement calculé comme la durée moyenne d’interruption de la production sur les dix derniers incidents.

Les métriques sont toujours essentielles pour garantir et quantifier la performance des DevOps. Si le MTTR peut être interprété en fonction du volume de nouvelles fonctionnalités ajoutées à une application, de la complexité du code ou d’autres variables de production, il fournit généralement une mesure précise des capacités d’une équipe. Idéalement, le MTTR diminue quand l’implémentation DevOps d’une organisation gagne en maturité.

Le MTTR peut également être utile pour communiquer l’impact positif du DevOps sur l’entreprise aux dirigeants et aux décideurs métier, par exemple en chiffrant l’économie réalisée grâce à l’augmentation de la productivité ou la réduction des interruptions.

Qu’est-ce que le MTTR dans le développement continu ?

Le MTTR est une mesure de la stabilité du processus de développement continu d’une entreprise.

La vitesse du développement logiciel et de sa livraison est un moteur vital de réussite pour la plupart des entreprises. Un processus robuste de livraison continue utilise une boucle de feedback « développer, mesurer, apprendre » qui garantit l’amélioration permanente et le respect des objectifs commerciaux.

Comme la vitesse et la stabilité sont le fondement du développement continu, les métriques qui permettent d’évaluer et d’améliorer ces questions sont essentielles. Il n’existe pas de métrique normalisée pour superviser le développement continu, et il appartient à chaque organisation de choisir les métriques adaptées à son objectif. Toutefois, le MTTR est couramment employé pour déterminer à quelle vitesse les équipes savent corriger les problèmes dans le pipeline de la livraison continue, et le MTTR peut être un guide pour améliorer sa stabilité.

Comment réduire le MTTR ?

Si la plupart des problèmes qui font augmenter le MTTR sont propres à chaque entreprise (et nécessitent donc une évaluation spécifique des processus et procédures IT), on peut recommander six étapes qui permettront à tous les types d’organisation ou presque d’améliorer leur MTTR.

  1. Comprenez les incidents : pour réduire le MTTR, vous devez mieux comprendre les incidents et les défaillances. Les logiciels d’entreprise modernes peuvent vous aider à unifier automatiquement vos données en silos pour obtenir un indicateur MTTR fiable et des renseignements précieux sur les causes et les facteurs de cette métrique stratégique.
  2. Mettez l’accent sur la supervision : avant de pouvoir corriger un problème, vous devez l’identifier, et le plus tôt sera le mieux. Une bonne solution de monitoring vous fournira un flux continu de données en temps réel sur les performances de votre système, généralement au sein d’un même tableau de bord facile à lire, et vous avertira de l’apparition des problèmes.
  3. Élaborez un plan d’action : si les petites organisations aux ressources limitées doivent souvent se contenter de réponses ad hoc, les grandes entreprises doivent suivre des procédures et des protocoles plus rigoureux. Pour nombre d’entre elles, cela nécessite une approche ITSM conventionnelle, avec des rôles et des réponses bien définis. Les entreprises qui ont effectué une transformation numérique complète peuvent adopter une approche plus flexible et utiliser des outils de collaboration interfonctionnels pour apporter une réponse spécifique à chaque incident. Quel que soit votre plan, il doit indiquer clairement les personnes à informer en cas d’incident, comment le documenter et la marche à suivre par votre équipe pour le résoudre.
  4. Automatisez votre système de gestion des incidents : pour répondre rapidement, il faut d’abord que les bonnes personnes reçoivent rapidement des informations précises sur le problème. Avertir un membre de l’équipe par téléphone fonctionne pour un incident de faible priorité survenant pendant les heures de bureau. Mais que se passe-t-il si une panne de serveur met votre site hors ligne à 20h00 un vendredi ? Un système automatisé de gestion des incidents peut envoyer simultanément des alertes sur plusieurs canaux (appel téléphone, sms, e-mail) à tous les intervenants désignés, ce qui permet de gagner un temps considérable en évitant d’avoir à localiser et contacter manuellement chaque personne.
  5. Désignez les équipes de réponse aux incidents et leurs rôles : il est essentiel d’avoir des rôles et responsabilités clairement définis pour gérer efficacement la réponse aux incidents et réduire le MTTR. Bien que la structure d’une organisation de support dépende des besoins de votre entreprise, ITIL propose un framework composé des rôles suivants :
    • Gestionnaire d’incidents : ce rôle dirige le processus de gestion des incidents, l’adapte et l’améliore au besoin. Selon ITIL, ce rôle est généralement confié au responsable du service d’assistance dans les petites et moyennes entreprises, mais il peut être un rôle à part entière. Le gestionnaire d’incidents est avant tout chargé d’administrer le système de gestion des incidents et d’appliquer le processus associé. Le gestionnaire d’incidents dirige également l’équipe d’intervention, présente les indicateurs clés de performance (KPI) à la direction et gère l’assistance de première et de deuxième ligne.
    • Assistance de première ligne (niveau 1) : ce rôle est le point de contact unique pour les utilisateurs finaux qui signalent des dégradations de service. Il est responsable de la classification des incidents et doit s’efforcer de restaurer un service défaillant aussi vite que possible. Si l’assistance de première ligne est incapable de résoudre l’incident, ce groupe doit acheminer le problème à l’équipe de deuxième ligne, superviser les activités de restauration et tenir les utilisateurs informés de l’évolution de l’incident.
    • Assistance de deuxième ligne (niveau 2) : les techniciens de deuxième ligne possèdent généralement des connaissances plus pointues que ceux de la première ligne. Ils sont donc mobilisés pour les incidents que la première ligne ne parvient pas à résoudre. Les techniciens de deuxième ligne peuvent également être chargés d’interagir avec les fournisseurs de logiciels ou de matériel tiers pour accélérer le rétablissement des services. Dans les environnements très vastes, complexes ou sensibles, il peut être nécessaire de mettre en place un groupe de support de troisième ligne (niveau 3) possédant des compétences et des connaissances plus avancées encore.
    Votre équipe de réponse aux incidents n’a pas besoin de coller exactement à cette structure. Mais quelle que soit votre approche, veillez à ce qu’elle ait un leader désigné qui supervise la réponse aux incidents, assure une communication robuste avec les parties prenantes internes et externes à l’équipe et s’assure que tous les membres de l’équipe connaissent leurs responsabilités.
  6. Formez les membres de l’équipe à différents rôles : les spécialistes aux connaissances très ciblées ont une valeur inestimable pour une équipe de réponse aux incidents. Toutefois, si vous confiez à ces spécialistes des problèmes triviaux, vous risquez de les surcharger, de réduire leurs performances dans leurs responsabilités habituelles et de les épuiser. Votre équipe de sécurité peut également se retrouver bloquée si un spécialiste est absent lorsque l’incident se produit.

Vous pouvez réduire ces problèmes et ainsi réduire votre MTTR en faisant en sorte que tous les membres de l’équipe maîtrisent votre système et soient formés à différentes fonctions de la réponse aux incidents. Votre équipe sera en mesure de répondre plus rapidement, quelles que soient les personnes d’astreinte lorsque le problème survient.

Cette visibilité sur votre infrastructure peut aussi vous aider à diagnostiquer les problèmes plus rapidement et plus précisément. Par exemple, disposer de données en temps réel sur le volume des requêtes d’un serveur et la rapidité avec laquelle le serveur y répond vous permettra de mieux vous préparer à résoudre une défaillance de ce serveur. Les données vous permettent également de voir comment des mesures spécifiques prises pour réparer les composants du système affectent ses performances, pour trouver plus rapidement une solution appropriée.

Pour résumer

Le temps moyen de réparation peut avoir un profond impact sur votre entreprise

Les services IT des entreprises sont confrontés à l’obligation d’améliorer constamment les niveaux de service tout en réduisant les coûts, et c’est pourquoi les délais de réponse aux incidents acquièrent une importance cruciale. Si le MTTR n’est pas un chiffre magique, c’est un indicateur solide de la capacité d’une organisation à répondre rapidement et à réparer des problèmes potentiellement coûteux. Étant donné l’impact direct des interruptions des systèmes sur la productivité, la rentabilité et la confiance des clients, une solide compréhension du MTTR et de ses facteurs est un impératif pour toute entreprise axée sur les technologies.