MTBF (Mean Time Between Failures)

MTBF (Mean Time Between Failures) est une métrique de fiabilité (reliability) mesurant le temps moyen entre deux incidents/pannes consécutifs pour un système. Originaire du hardware engineering (durée de vie des composants), adoptée en SRE pour mesurer la stabilité des services. Calcul : MTBF = total operational time / number of failures during that time.

Exemple : un service tourne 720h dans un mois et expérimente 4 incidents → MTBF = 180h. Plus le MTBF est élevé, plus le système est fiable.

Différence avec MTTR : MTBF mesure fréquence des pannes (combien souvent), MTTR mesure durée de résolution (combien longtemps). Availability liée : Availability = MTBF / (MTBF + MTTR). Pour 99.9% availability (8.76h downtime/an), si MTTR = 30min, MTBF doit être ≥ 500h ; si MTTR = 5min, MTBF peut être 83h. Optimiser availability = augmenter MTBF (moins de pannes) ET réduire MTTR (récupérer plus vite).

Distinguer MTBF de MTTF (Mean Time To Failure) : MTTF s'applique à non-repairable systems (lifetime d'un composant unique) ; MTBF s'applique à repairable systems (services qui peuvent être réparés et redémarrés). Software services = MTBF context.

Factors améliorant MTBF :
(1) Quality engineering : tests rigoureux (unit, integration, E2E, chaos engineering, load testing) ; code reviews ; static analysis ; type safety ; production-ready checklist avant launch nouveau service.
(2) Architecture resilience : avoid SPOF (single point of failure) ; redundancy multi-AZ ; auto-failover ; circuit breakers prevent cascading failures ; bulkheads (isolate failure domains) ; rate limiting prevent overload ; graceful degradation.
(3) Capacity planning : load forecasting ; headroom CPU/memory/IOPS ; auto-scaling correctly tuned ; load testing for peak scenarios (Black Friday) ; chaos game days.
(4) Change management : safe deployments (canary, blue-green, feature flags) ; comprehensive testing in CI/CD ; automated rollback ; deployment windows for risky changes.
(5) Infrastructure quality : reliable hardware/cloud regions ; proper monitoring of dependencies (databases, caches, message queues) ; managed services where possible (vs DIY).
(6) Operational excellence : runbooks, post-mortems, incident review pour learn-and-improve ; SRE practices ; error budgets ; on-call rotations preventing burnout.

Google SRE practice — error budgets : si SLO = 99.9% availability, error budget = 0.1% downtime allowed (43.2 min/month). Si team brûle le budget rapidement (many incidents), feature velocity slows down pour focus sur reliability. Si budget reste plein, can take more deployment risks pour innovation. Crée tension productive entre vélocité et stabilité.

MTBF dans hardware vs software : MTBF spécifié par vendor pour disques (e.g., 1.4M hours pour enterprise SSD = ~160 years) — mais sample size based, not guarantee for specific unit. Software MTBF rarely cited explicitly, mais incident frequency dashboards (incidents/month, MTBF derivée) standard dans SRE reports.

Alternative metric : SLO error budget consumption (% du budget utilisé sur fenêtre glissante 28-30 days) — more actionable que raw MTBF, aligns avec business commitments aux clients. Compétences SRE pratiques.