MTTR vs MTBF para data center: qué métrica reporta primero y por qué

Si tu equipo te reporta un solo número de confiabilidad, ya tiene un problema de fondo. Confiabilidad operativa son dos cosas distintas: qué tan seguido falla, y qué tan rápido lo arreglas. Reportarlas como una sola métrica esconde exactamente la decisión que necesitas tomar.

MTBF (Mean Time Between Failures) y MTTR (Mean Time To Repair) no son opuestas ni redundantes. Cubren dimensiones distintas del mismo sistema y, combinadas, producen la disponibilidad real que puedes prometer.

MTBF: lo que dice la estabilidad del diseño

MTBF mide el tiempo promedio entre fallas. Es una métrica predictiva: cuánto espera tu equipo entre un incidente y el siguiente en condiciones nominales. Sube cuando el diseño del equipo es estable, los procedimientos son repetibles y la operación no introduce variabilidad.

Para reportar MTBF con sentido necesitas telemetría continua (logs de fallas, tickets, mantenimiento mayor). El cálculo clásico es horas operativas entre eventos de falla no planificados. ITIL 4 lo trata dentro de las prácticas de gestión de disponibilidad y capacidad: el MTBF es la base para proyectar carga de mantenimiento y refacciones críticas.

MTTR: la velocidad real del equipo humano y técnico

MTTR mide el tiempo promedio que toma restaurar el servicio después de una falla. Incluye detección, diagnóstico, respuesta, logística de refacciones y reemplazo. Es una métrica reactiva con fuerte dependencia de la operación: un buen diseño no baja MTTR si el equipo no sabe a quién llamar.

MTTR se descompone en cuatro sub-tiempos: detección (alarma que se pierde vs alarma que se ve), diagnóstico (cuánto tardas en saber qué falló), respuesta (tiempo entre diagnóstico y manos en sitio) y reemplazo (refacción disponible + ventana de mantenimiento). Reducir MTTR por debajo de cierto umbral requiere redundancia, no más personal.

Cuál reportar primero (y por qué)

Reporta MTBF antes que MTTR. La razón no es glamour: cuando MTBF crece, tienes menos incidentes y, por lo tanto, menos datos limpios para calcular MTTR. Si primero reportas MTTR y es bajo, no sabes si arreglas rápido porque tienes pocas fallas o porque operas bien.

La trampa del 99,9 %

99,9 % de disponibilidad en un mes son 43 minutos de indisponibilidad tolerable. En un trimestre, 2,1 horas. Para conseguir 99,9 % no necesitas redundancia N+1: necesitas saber cuánto indisponibilidad ya tienes hoy y restársela. Para conseguir 99,99 % necesitas redundancia real y monitoreo 24×7 con respuesta documentada. Para 99,999 % necesitas Tier III o superior y procesos formalizados.

Si prometes 99,9 % sin haber medido tu indisponibilidad actual, estás vendiendo tranquilidad matemática, no un SLA operativo. La diferencia se nota el primer mes cuando el cliente te reclama 47 minutos y tú no tienes el registro para demostrar dónde estuviste esos 47 minutos.

Cómo usarlas en decisiones reales

Si tu MTBF está cayendo y tu MTTR está subiendo, el sistema envejece más rápido de lo que operas. Inviertes en refacciones y en redundancia, no en personal.

Si MTBF está estable pero MTTR está subiendo, el problema es de operación: tu equipo tarda más en responder, no el equipo en fallar. Inviertes en procedimientos, runbooks y manos remotas, no en equipo nuevo.

Si MTBF está subiendo pero MTTR está estable, vas por buen camino en diseño y mantenimiento; el siguiente paso es consolidar MTTR con monitoreo predictivo y SLA interno medible.

Fuentes

[1] IEC 62813 — Mean time to failure (MTTF) and related metrics — https://webstore.iec.ch/publication/8559

[2] ITIL 4 — Practice: Availability Management (Resumen de gestión de disponibilidad) — https://www.axelos.com/certifications/itil-service-management/itil-4-foundation

[3] ISO/IEC 20000-1 — Service management system requirements — https://www.iso.org/standard/70636.html