Définition

Le délai moyen de réparation (MTTR, Mean Time to Repair) est un indicateur clé de performance qui représente le temps moyen nécessaire pour qu’un système redevienne totalement opérationnel après un incident. Combiné à d’autres indicateurs liés aux incidents, il permet d’évaluer les performances du DevOps et de l’ITOps, l’efficacité des processus et des solutions de sécurité, ainsi que la maintenabilité des systèmes.

Si les accords de niveau de service conclus avec des fournisseurs tiers précisent généralement les attentes en matière de MTTR, la complexité de certains incidents ne permet pas de garantir ces délais. Par ailleurs, comparer les MTTR de deux entreprises distinctes n’est pas très productif, compte tenu des facteurs uniques liés à la taille et au type d’infrastructure de chacune, ainsi qu’à l’étendue et aux compétences de leurs équipes ITOps et DevOps. Chaque entreprise doit par conséquent déterminer les indicateurs qui serviront le mieux ses objectifs et la manière de les appliquer à son environnement.

Présentation des indicateurs d’échec les plus courants

Les systèmes d’entreprise modernes sont complexes et peuvent connaître différents types de défaillance. C’est pourquoi il n’existe pas d’ensemble unique d’indicateurs d’incident valable pour toutes les entreprises. Les combinaisons possibles sont multiples et les différences nuançables.

Délai moyen de détection (MTTD, Mean Time to Detect)

Également appelé « délai moyen de découverte », le MTTD correspond au temps moyen qui s’écoule entre une défaillance système et sa détection. Cet indicateur clé de performance sert à mesurer l’efficacité des outils et des processus utilisés par les équipes DevOps.

Pour le calculer, sélectionnez une période de temps (par exemple, un mois) et relevez le temps qui s’écoule entre la survenue des pannes système et leur découverte, puis additionnez ces délais et divisez le temps total obtenu par le nombre d’incidents. Le résultat doit être le plus bas possible. Si ce délai de détection ou de découverte des défaillances système a tendance à s’allonger, il conviendra d’examiner au plus vite les outils et processus de gestion de la réponse à incident.

Délai moyen d’identification (MTTI, Mean Time to Identify)

Cet indicateur consigne le nombre d’heures ouvrables qui s’écoulent entre le moment où une alerte est déclenchée et celui où l’équipe de cybersécurité commence à l’examiner. Le MTTI permet de déterminer si les systèmes d’alerte sont efficaces et si les équipes de cybersécurité disposent de personnel en suffisance. Un MTTI élevé ou qui évolue dans la mauvaise direction peut indiquer que votre équipe de cybersécurité souffre de lassitude face aux alertes répétées.

Délai moyen de reprise (MTTR, Mean Time to Recovery)

Le délai moyen de reprise correspond au temps moyen qui s’écoule, en heures ouvrables, entre la survenue d’un incident et le retour à la normale des activités de l’entreprise. Cet indicateur sert à déterminer l’efficacité des équipes DevOps et ITOps, et à identifier les points à améliorer en matière de processus et de capacités.

Délai moyen de résolution (MTTR, Mean Time to Resolve)

Le délai moyen de résolution correspond au temps moyen qui s’écoule entre la première alerte et l’analyse post-incident, en ce compris le temps passé pour s’assurer que la défaillance ne se reproduira pas. Il se mesure en heures ouvrables.

Délai moyen entre deux défaillances (MTBF, Mean Time Between Failures)

Le délai moyen entre deux défaillances est un indicateur clé de performance qui évalue la fiabilité et la disponibilité d’un système. Les équipes ITOps l’utilisent pour identifier les systèmes et composants qui fonctionnent correctement et ceux qui nécessitent d’être évalués en vue d’être réparés ou remplacés. Connaître le MTBF permet d’effectuer des opérations de maintenance préventive, de limiter la maintenance réactive, de réduire les temps d’arrêt et de prioriser efficacement le workload. Par ailleurs, les données historiques associées peuvent servir à optimiser la prise de décision concernant la planification des maintenances et l’allocation des ressources.

Le MTBF est obtenu en déterminant le nombre d’heures qui s’écoulent entre les différentes défaillances d’un système sur une période normale d’activité donnée, puis en calculant la moyenne.

Délai moyen avant défaillance (MTTF, Mean Time to Failure)

Le délai moyen avant défaillance permet de considérer les périodes de disponibilité du système et les temps d’arrêt. Contrairement au MTBF, qui se concentre sur la réparabilité, le MTTF se focalise sur les défaillances non réparables. Il est utilisé pour prédire la durée de vie des systèmes, mais n’est cependant pas adapté à tous les systèmes. Par exemple, les systèmes ayant une longue durée de vie, comme les systèmes bancaires de base et de nombreux systèmes de contrôle industriels ne constituent pas de bons sujets pour l’application du MTTF. En effet, leur durée de vie est telle que lorsqu’ils finiront par être remplacés, ce sera par un système totalement différent, aligné sur les dernières avancées technologiques. L’utilisation du MTTF dans ce type de situation est donc discutable.

À l’inverse, le suivi du MTTF des systèmes ayant une durée de vie plus standard est un bon moyen d’identifier les marques qui fonctionnent le mieux ou les facteurs environnementaux qui influencent le plus la durabilité d’un produit.

Avantages pour les équipes DevOps et ITOps

L’analyse du MTTR (à comprendre au sens de délai moyen de réparation dans la suite de ce document) vise à limiter les temps d’arrêt non planifiés et le temps de propagation. Elle est également utilisée pour améliorer la culture des équipes ITOps.

La résolution d’un incident avant qu’il n’affecte les utilisateurs témoigne de l’efficacité des équipes DevOps et ITOps. Le fait de savoir que leurs performances sont mesurées à l’aide du MTTR encourage les équipes DevOps à concevoir des systèmes résilients et des applications réparables plus rapidement, notamment en développant des applications reposant sur des services web distincts, de sorte que la défaillance d’un service n’entraînera pas le plantage de l’application tout entière. Le calcul du MTTR, lorsqu’il est effectué correctement, inclut une analyse post-incident, qui doit être utilisée pour informer une boucle de rétroaction visant à améliorer les builds ultérieurs du logiciel et à encourager la correction des bugs le plus tôt possible dans le cycle de développement logiciel.

Calcul du délai moyen de réparation

Pour calculer le MTTR, il suffit d’additionner le temps de réparation non planifié total passé sur un système au cours d’une période donnée et de diviser cette somme par le nombre total d’incidents pertinents.

Cependant, toutes les pannes ne se valent pas. Le temps passé à réparer un composant défaillant ou un système en interface avec les clients qui tombe en panne pendant une période de forte activité sera plus coûteux en termes de pertes commerciales, de productivité et d’atteinte à la marque que celui passé à réparer une panne non critique en pleine nuit. Par conséquent, les entreprises peuvent établir un « budget d’erreur » stipulant que chaque minute passée à réparer les systèmes les plus critiques équivaut à une heure de réparation des systèmes les moins essentiels. Un tel niveau de précision permet de déterminer le coût réel des temps d’arrêt et de mieux comprendre ce que représente le MTTR pour une entreprise donnée.

Comment réduire le MTTR

Il existe trois moyens de réduire le MTTR.

1. Le premier consiste à définir une stratégie de gestion du processus de résolution, qui doit inclure une analyse post-incident afin de tirer des enseignements des incidents passés.
2. Bien entendu, la technologie joue un rôle essentiel et la solution idéale doit allier visibilité, surveillance et maintenance corrective afin de déceler les problèmes à la source et de renforcer les défenses contre de futures attaques.
3. Enfin, il convient d’avoir à disposition les compétences nécessaires pour atténuer les incidents.

Si l’augmentation du budget ou des effectifs peut contribuer à réduire le MTTR, une telle approche n’est pas toujours réaliste. Une alternative serait de déployer l’intelligence artificielle (IA) et le Machine Learning (ML) afin d’automatiser au maximum le processus de réparation. Cela comprend la détection rapide, la réduction des faux positifs, la remontée intelligente et la correction automatique basée sur des flux de travail propices à la réduction du MTTR.

Si le MTTR peut se révéler utile pour limiter les temps d’arrêt et rationaliser les tâches des équipes DevOps et ITOps, son amélioration ne devrait pas être l’objectif final. En effet, l’utilisation d’indicateurs n’a pas pour seul but d’améliorer les chiffres. Dans ce cas particulier, il s’agit d’assurer la continuité du fonctionnement des systèmes et de protéger l’entreprise et ses clients. Utilisez donc le MTTR pour aider vos équipes à protéger vos clients et à optimiser la disponibilité des systèmes.

Amélioration du MTTR au moyen d’une solution moderne de gestion des logs

Les logs constituent une précieuse ressource aux fins de la réponse à incident. Falcon LogScale offre une observabilité totale pour tous les logs de streaming et données d’événement. Il permet ainsi aux équipes informatiques de mieux se préparer à l’inconnu et de trouver rapidement la cause sous-jacente de tout incident.

Falcon LogScale s’appuie sur des technologies modernes, dont le streaming de données, une architecture sans index et des déploiements hybrides, pour optimiser les ressources informatiques et réduire les coûts de stockage. La solution est ainsi en mesure de collecter en mémoire des données structurées et non structurées afin d’accélérer leur analyse et leur examen, quel que soit le volume.

Journalisez toutes vos données et répondez à toutes les questions – gratuitement

Falcon LogScale Community Edition (auparavant Humio) offre une plateforme moderne et gratuite de gestion des logs pour le cloud. Exploitez l’ingestion des données de streaming pour bénéficier d’une visibilité instantanée sur les systèmes distribués, de même que détecter et résoudre les incidents.

Falcon LogScale Community Edition, disponible instantanément et gratuitement, inclut les fonctionnalités suivantes :

• Ingestion de jusqu’à 16 Go de données par jour
• Durée de rétention de 7 jours
• Aucune carte de crédit requise
• Accès continu sans période d’essai
• Journalisation sans index, alertes en temps réel et tableaux de bord en direct
• Accès à notre place de marché et à nos packages, y compris aux guides de création de nouveaux packages
• Formation et collaboration avec une communauté active

DÉMARRER GRATUITEMENT