MTTR, MTTF et l'Équation de Disponibilité

Deux métriques, une formule, un insight : réduire le MTTR est presque toujours plus efficace que d'empêcher les pannes.

Votre SLO mesure une disponibilité. Cette disponibilité est la résultante de deux forces opposées : la fréquence à laquelle votre système tombe en panne, et la vitesse à laquelle vous le réparez. Agir sur l'une ou l'autre a le même effet mathématique — mais des coûts très différents.

Définitions

MTTF (Mean Time To Failure) : durée moyenne de fonctionnement entre deux pannes. Plus il est élevé, plus votre système est fiable. MTTR (Mean Time To Recovery) : durée moyenne entre le début d'une panne et le retour à la normale. Il inclut la détection, le diagnostic, la correction et la vérification. MTBF (Mean Time Between Failures) = MTTF + MTTR.

La formule de disponibilité

La disponibilité se calcule directement à partir du MTTF et du MTTR. C'est le ratio du temps "en bonne santé" sur le temps total. Exemple : si votre service tombe en panne en moyenne toutes les 15 jours (MTTF = 21 600 min) et que vous le réparez en 21,6 minutes en moyenne, vous atteignez exactement 99,9 % de disponibilité — soit le budget d'erreur d'un SLO 99,9 % consommé en totalité.

Disponibilité = MTTF / (MTTF + MTTR)

Le levier MTTR est souvent plus efficace

Réduire le MTTR de moitié a exactement le même effet sur la disponibilité que doubler le MTTF. Mathématiquement, M/(M+T/2) = 2M/(2M+T). Mais améliorer le MTTF signifie réduire la fréquence des pannes — ce qui nécessite souvent une refonte d'infrastructure, plus de tests, du chaos engineering. Améliorer le MTTR, c'est écrire de meilleurs runbooks, automatiser les rollbacks, améliorer les dashboards et entraîner l'astreinte. C'est généralement plus rapide et moins coûteux.

Le temps de détection, partie cachée du MTTR

La plupart des équipes mesurent le MTTR à partir de l'acquittement de l'alerte, pas du début réel de la panne. Le MTTD (Mean Time To Detect) — le temps entre la panne et la première alerte — est souvent invisible dans les post-mortems. Un service qui tombe à 2h du matin et n'est détecté qu'à 8h a un MTTR réel de 6h+ même si la résolution a pris 20 minutes. Vos SLO mesurent la disponibilité réelle, pas celle à partir de l'alerte.

Pièges courants

! Mesurer le MTTR depuis l'acquittement de l'alerte : vous sous-estimez votre MTTR réel d'un facteur 2 à 10 selon votre couverture d'alerting.
! Considérer les pannes comme indépendantes : deux services dans la même région AWS tombent souvent ensemble — votre MTTF effectif est bien inférieur au MTTF isolé.
! Optimiser uniquement le MTTF : si votre MTTR est de 4h et votre MTTF de 30 jours, réduire les pannes de 20 % ne vous fait gagner que 4 minutes de disponibilité par mois. Réduire votre MTTR à 30 min vous en fait gagner plus de 3h.