Le MTTR (mean time to recovery, ou repair : temps moyen de rétablissement ou de réparation) est la durée moyenne entre le début d’un incident et le retour à la normale du service. Le MTTA (mean time to acknowledge : temps moyen de prise en charge) est la durée moyenne entre une alerte et le moment où quelqu’un confirme qu’il s’en occupe. Le MTBF (mean time between failures : temps moyen entre pannes) est la durée moyenne pendant laquelle un service fonctionne normalement entre deux incidents. Ensemble, ils décrivent la fiabilité : le MTBF indique la fréquence des pannes, le MTTA la rapidité de votre réaction et le MTTR la durée pendant laquelle vos clients sont touchés.
Ce guide couvre les définitions, les formules, un exemple chiffré, les horodatages à collecter et les changements concrets qui améliorent chaque indicateur.
Les indicateurs et ce qu’ils mesurent
MTTR : un sigle, quatre significations
Le MTTR est l’indicateur d’incident le plus cité et le plus déroutant, car le R ne désigne pas la même chose selon qui l’emploie :
Mean time to repair (temps moyen de réparation) : du début des travaux de réparation jusqu’à la mise en place du correctif. Courant dans le matériel et la maintenance.
Mean time to recovery ou restore (temps moyen de rétablissement) : du début de la panne jusqu’au moment où le service fonctionne à nouveau pour les utilisateurs. La version la plus utile pour les sites web et les API.
Mean time to respond (temps moyen de réaction) : de l’alerte jusqu’au moment où l’équipe commence à agir. Proche du MTTA.
Mean time to resolve (temps moyen de résolution) : jusqu’à la clôture complète de l’incident, y compris le suivi qui l’empêche de se reproduire.
Aucune n’est fausse. L’essentiel est d’en choisir une, de consigner la définition par écrit et de s’y tenir. Comparer votre chiffre de « rétablissement » au chiffre de « réparation » de quelqu’un d’autre ne vous apprend rien. Dans cet article, MTTR signifie temps moyen de rétablissement : du moment où le service a cessé de fonctionner jusqu’à celui où il a fonctionné à nouveau.
MTTD et MTTA : la réaction avant la réparation
Le MTTD (mean time to detect : temps moyen de détection) est la durée entre le début d’un incident et le déclenchement d’une alerte par la surveillance. Le MTTA est la durée entre cette alerte et sa prise en charge par une personne. Tous deux font partie du MTTR, d’où leur importance : personne ne peut corriger un problème dont il n’a pas entendu parler.
MTBF : la fréquence des pannes
Le MTBF est la durée moyenne de fonctionnement entre deux incidents. Plus il est élevé, mieux c’est. Son cousin, le MTTF (mean time to failure : temps moyen avant panne), s’applique aux éléments que l’on remplace plutôt que de les réparer, comme les disques ; pour les services en ligne, c’est le MTBF qu’il vous faut.
Les formules
MTTD = durée totale entre début de l’incident et alerte / nombre d’incidents
MTTA = durée totale entre alerte et prise en charge / nombre d’incidents
MTTR = durée totale entre début de l’incident et rétablissement / nombre d’incidents
MTBF = durée totale de fonctionnement sans incident / nombre d’incidents
Disponibilité = MTBF / (MTBF + MTTR)
La dernière ligne montre pourquoi les deux côtés comptent. Vous pouvez améliorer la disponibilité en ayant moins d’incidents (MTBF plus élevé) ou en les raccourcissant (MTTR plus faible). Les raccourcir coûte souvent bien moins cher.
Un exemple chiffré
Voici un mois type pour une boutique en ligne, avec quatre incidents. Les chiffres sont inventés pour l’exemple, mais les horodatages sont ceux que fournit n’importe quel outil de surveillance.
IncidentDébutAlertePrise en chargeRétabliDétectionPrise en chargeRétablissementPaiement en 50303:1203:1303:1603:191 min3 min7 minTimeouts de l’API10:0510:0610:0810:411 min2 min36 minErreurs de connexion14:3014:3114:4515:021 min14 min32 minRecherche en panne22:5022:5122:5623:151 min5 min25 min
Appliquons maintenant les formules :
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minute.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minutes.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minutes.
MTBF : un mois de 30 jours compte 43 200 minutes. Moins 100 minutes d’interruption, il en reste 43 100. Divisé par 4 incidents, le MTBF est de 10 775 minutes, soit environ 7,5 jours.
Disponibilité = 10 775 / (10 775 + 25) = 99,77 %.
Deux points ressortent. Les 14 minutes de prise en charge sur l’incident de connexion font passer le MTTA d’environ 3 minutes à 6 : il vaut donc la peine de se demander pourquoi personne n’a réagi à cette alerte. Et à 99,77 %, cette boutique est loin d’un objectif de 99,9 %, qui n’autorise que 43 minutes par mois. Si vous fixez ce type d’objectifs, lisez SLA, SLO et SLI pour comprendre comment ils s’articulent.
Imaginez maintenant le même mois avec des vérifications toutes les cinq minutes et sans étape de confirmation. La détection pourrait prendre jusqu’à cinq minutes au lieu d’une, soit jusqu’à quatre minutes de plus par incident. Le MTTR passe de 25 à 29 minutes au maximum avant que quiconque ait changé quoi que ce soit à sa façon de travailler.
Les horodatages à collecter
Il vous faut quatre horodatages par incident. La plupart proviennent directement de la surveillance :
Début : la première vérification en échec. Une surveillance externe l’enregistre même quand vos serveurs ne journalisent rien.
Alerte : le moment où la panne a été confirmée et la notification envoyée.
Prise en charge : le moment où une personne a dit « je m’en occupe ». Sans outil d’astreinte, une réponse dans le canal d’incident fait l’affaire ; notez l’heure. Dans Uptimecheck, vous prenez en charge l’incident dans l’application ou, avec l’application Slack, d’un bouton dans Slack, et l’heure est enregistrée.
Rétablissement : la première vérification réussie après l’incident, qui est aussi le moment où l’avis de rétablissement est envoyé.
Avec Uptimecheck, chaque incident dispose d’une chronologie : son début, qui a été alerté et quand, les prises en charge (également d’un bouton dans Slack si vous utilisez l’application Slack), les notes et le rétablissement. Le MTTA et le MTTR sont calculés pour vous, et l’export CSV du rapport fournit, pour chaque moniteur, le nombre d’incidents, la durée d’interruption et l’incident le plus long, prêts pour un tableur. Consignez ensuite les enseignements dans un postmortem.
Une mise en garde pratique : les moyennes masquent les valeurs extrêmes. Un incident de six heures et neuf micro-coupures d’une minute donnent une moyenne d’environ 37 minutes, qui ne décrit ni l’un ni les autres. Regardez la médiane et l’incident le plus long en plus de la moyenne, et passez en revue les incidents les plus lents un par un.
Réduire le temps de détection
Vérifier toutes les minutes
L’intervalle de vérification fixe la limite haute de votre temps de détection. Des vérifications toutes les minutes sur tout ce qui génère du chiffre d’affaires ou sert vos clients constituent l’amélioration du MTTR la moins coûteuse qui soit. Utilisez une surveillance de disponibilité à 1 minute pour chaque page et chaque point de terminaison critiques.
Vérifier ce qui casse, pas seulement ce qui se charge
Les incidents que la surveillance ne voit pas sont détectés par les clients, souvent des heures plus tard. Validez le contenu des pages importantes, surveillez les points de terminaison d’API dont dépendent les applications et ajoutez des heartbeats à vos tâches planifiées. Chaque incident signalé d’abord par un client révèle une lacune dans votre surveillance.
Réduire le temps de prise en charge
N’envoyer que des alertes confirmées
Une prise en charge lente est généralement un problème de confiance. Si la moitié des alertes sont fausses, les gens apprennent à attendre de voir. Confirmez chaque panne par une seconde vérification avant d’alerter, et supprimez les moniteurs qui alertent sans que personne n’ait à agir. Notre guide pour réduire les fausses alertes entre dans le détail.
Envoyer les alertes sur le bon canal
Un e-mail envoyé à 03:12 sera lu à 07:30. Envoyez les moniteurs critiques vers un canal qui atteint le téléphone de la personne d’astreinte et vers une messagerie d’équipe pour les autres, et laissez les moniteurs moins urgents sur l’e-mail. Uptimecheck vous permet de choisir les canaux d’alerte par moniteur : e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks et notifications push sur votre téléphone, sur toutes les offres. L’escalade peut retenir un canal de 5 à 60 minutes et n’alerter que si la panne est toujours en cours et que personne ne l’a prise en charge.
Clarifier les responsabilités
Une alerte envoyée à cinq personnes n’est souvent prise en charge par aucune. Désignez un responsable par service et une personne d’astreinte par créneau. Les autres reçoivent l’information, pas la responsabilité. Avec les plannings d’astreinte d’Uptimecheck, chacun prend son tour, avec des remplacements en cas d’arrêt maladie ou d’échange, et les alertes push atteignent la personne d’astreinte du moment.
Réduire le temps de réparation
Rédiger des runbooks pour les pannes connues
La plupart des incidents se répètent. Le disque se remplit, un pool de workers est saturé, le renouvellement d’un certificat échoue. Un court runbook par moniteur transforme une investigation à moitié endormie en simple checklist :
Runbook : le paiement renvoie 503
1. Consulter le tableau de bord du serveur : CPU, mémoire, disque sur web-01 et web-02.
2. Vérifier l’état de PHP-FPM : sudo systemctl status php8.3-fpm
3. Si les workers sont saturés : sudo systemctl restart php8.3-fpm
4. Rechercher les tâches longues : ps aux –sort=-%cpu | head
5. Toujours en échec après 10 minutes ? Escalader au développeur principal.
Gardez le lien vers le runbook là où arrive l’alerte, par exemple épinglé dans le canal d’incident, pour qu’il soit à portée de doigt.
Mettre la cause et le symptôme côte à côte
Quand la vérification d’un site web échoue, la première question est généralement de savoir si le serveur manque de mémoire, de CPU ou de disque. Avoir les métriques du serveur à côté des vérifications de disponibilité réduit cette étape d’une session SSH à un simple coup d’œil.
Garder un retour arrière simple
Beaucoup d’incidents commencent par un déploiement. Si revenir en arrière tient en une commande, le rétablissement prend quelques minutes. S’il faut une réunion, il prend une heure.
Mettre à jour la page de statut tôt
Une page de statut ne raccourcit pas la panne elle-même, mais elle raccourcit ce que les clients vivent le plus mal : l’incertitude. Elle évite aussi que le support soit submergé pendant que l’équipe corrige le problème. Une page de statut reliée à vos moniteurs affiche le composant touché dès l’ouverture de l’incident ; ajoutez une courte note sur ce que vous faites et sur l’heure de la prochaine mise à jour.
Améliorer le MTBF
Pour avoir moins d’incidents, il faut tirer les leçons de ceux que vous avez eus. Après chaque incident important, rédigez un postmortem sans recherche de coupable, convenez d’une ou deux actions et suivez-les jusqu’à leur réalisation. En quelques mois, les mêmes pannes cessent de revenir et le MTBF augmente.
Commencez à mesurer avec de vrais horodatages. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.