El tiempo medio hasta la falla (MTTF) es el tiempo promedio que un sistema o activo no reparable (como una bombilla) funciona antes de experimentar una falla que lo hace no disponible o estar fuera de especificación.
Las empresas utilizan este indicador clave de rendimiento (KPI) de confiabilidad para estimar la vida útil esperada de un componente técnico o mecánico.
En DevOps, el MTTF suele ser una medida de cuánto tiempo permanece un servicio disponible para los usuarios antes de fallas impactantes y tiempo de inactividad.
Un MTTF bajo o decreciente advierte a los desarrolladores e ingenieros de confiabilidad del sitio que la infraestructura, el código o las dependencias son frágiles y requieren mejoras para aumentar su confiabilidad. Un MTTF alto significa que el entorno de producción permanece estable durante períodos más largos entre incidentes y fallas importantes y, por lo tanto, que un equipo de TI ejecuta una arquitectura de TI sólida y entrega aplicaciones de software de forma segura.
Las métricas de MTTF, junto con otras métricas de mantenimiento, como el tiempo medio entre fallas (MTBF), ayudan a los equipos de DevOps a mejorar la capacidad y la planificación del ciclo de vida de una variedad de componentes de TI (incluidos nodos de red, contenedores y servicios gestionados), lo que reduce la probabilidad de interrupciones inesperadas.
Estas métricas también permiten a las empresas realizar un seguimiento de la confiabilidad del equipamiento a través de versiones, para que puedan determinar si el código, infraestructura como código (IaC) y los cambios de configuración hacen que los sistemas sean más resilientes, en lugar de solo hacerlos más rápidos de enviar.
El MTTF representa el tiempo operativo promedio hasta la falla para una población de elementos idénticos. En su forma más simple, el MTTF divide el tiempo total de funcionamiento de todos los activos por el número total de fallas de activos.
Donde “horas de funcionamiento totales” es la suma de la vida útil de cada elemento hasta que falla (o hasta que se detenga la observación), y “número de fallas” es el número de elementos que realmente fallaron:
MTTF = Total de horas de funcionamiento de todos los elementos/Número total de fallas
Tomemos como ejemplo un clúster de contenedores.
Los contenedores son instancias efímeras que normalmente no se reparan. Cuando un contenedor falla o deja de funcionar correctamente, las herramientas de orquestación de contenedores (como Kubernetes) simplemente destruyen el contenedor y crean uno nuevo.
Un equipo de TI que ejecuta un servicio web sin estado en 50 contenedores de aplicaciones idénticos puede calcular el MTTF midiendo cuánto tiempo se ejecuta cada contenedor (desde la creación hasta la falla) y dividiéndolo por la cantidad de contenedores fallidos. En su evaluación, el equipo descubre que el grupo de 50 contenedores funcionó durante un total de 200 horas, y cinco contenedores fallaron en el proceso.
MTTF = 200 horas de tiempo de funcionamiento/5 fallas = 40 horas
El MTTF para los contenedores de este clúster es de 40 horas.
El MTTF no es una fórmula perfecta ni exacta para los casos de uso del mundo real, por lo que los equipos de DevOps generalmente lo utilizan como una aproximación de la durabilidad de los componentes y en el contexto de otros KPI de gestión de incidentes, como el tiempo medio de reparación (MTTR) y el MTBF. En este caso, el MTTF puede ayudar a los equipos a estimar cuántos reinicios necesitará el clúster de contenedores cada día, para que puedan asignar el tamaño del clúster y los recursos de autoescalado de forma adecuada.
Sin embargo, cuanto más precisos sean los datos operativos y de fallas, y cuantos más datos incluyan los equipos, más precisos serán los cálculos de MTTF.
Manténgase al día sobre las tendencias más importantes e intrigantes de la industria sobre IA, automatización, datos y más con el boletín Think. Consulte la Declaración de privacidad de IBM.
El seguimiento del MTTF permite a los equipos cuantificar la confiabilidad del sistema y tomar decisiones informadas sobre gestión de activos, fomentando una mejor planificación e impulsando diseños y procesos más resilientes. Ayuda a las empresas a priorizar:
El MTTF proporciona una visión clara y numérica de la vida útil de un activo antes de la falla, de modo que los equipos pueden evaluar objetivamente la confiabilidad en lugar de depender de anécdotas.
El MTTF también aísla la confiabilidad inherente de los componentes o servicios del MTTR, que mide la rapidez con la que los equipos solucionan los problemas del sistema cuando ocurren. Cuando el MTTF se cae para un servicio, a menudo indica problemas más profundos de diseño o dependencia (una biblioteca defectuosa, por ejemplo). Los equipos pueden utilizar esas señales para iniciar la resolución de problemas y localizar la causa principal de las fallas del sistema.
Al realizar un seguimiento de las métricas de fallas a lo largo del tiempo, los equipos pueden identificar los servicios frágiles y priorizar las mejoras para reducir la frecuencia de incidentes en el futuro.
El monitoreo del MTTF puede ayudar a las empresas a optimizar las prácticas de gestión de mantenimiento y adoptar un enfoque más proactivo para la resolución de problemas.
En lugar de tareas de mantenimiento basadas en el tiempo o ad hoc (como “reiniciar el servicio X todos los domingos”), los equipos pueden usar MTTF observado para programar el mantenimiento antes de la ventana de falla típica (“reciclar pods al 80 % de su edad de falla típica”).
De hecho, los gerentes de TI y los equipos de mantenimiento pueden codificar runbooks (los conjuntos detallados de instrucciones para completar las tareas de TI) con orientación explícita basada en el MTFF. Por ejemplo, podrían incluir una instrucción de tarea como "Si el servicio X estuvo funcionando más tiempo que su MTTF típico y muestra señales de alerta temprana (errores, latencia), desactivarlo y resetear proactivamente, en lugar de esperar una falla grave".
En la gestión de incidentes, el MTTF puede representar el tiempo medio entre la detección de un defecto y la falla completa del sistema, indicando cuánto tiempo es probable que el sistema siga funcionando en un estado degradado o inseguro. Conocer esta ventana de degradación ayuda a los equipos a decidir si tienen minutos, horas o días para implementar un arreglo antes de que el componente se apague.
También ayuda a reducir la gravedad de los incidentes. En lugar de tener que improvisar ante una falla inesperada, el personal de TI puede ejecutar los cambios o las conmutaciones por error que ha planificado, probado y preparado con antelación.
La incorporación del MTTF en los KPI de DevOps impulsa a los equipos de TI a diseñar con miras a la confiabilidad y la degradación gradual, en lugar de centrarse únicamente en la velocidad de entrega. Los equipos pueden comparar el MTTF entre componentes para informar las opciones de arquitectura, como reemplazar componentes de bajo rendimiento y rediseñar servicios.
Observar el MTTF ayuda a los arquitectos de TI a decidir dónde son necesarias las redundancias. Por ejemplo, un servicio crítico con un MTTF bajo probablemente necesitará réplicas, clústeres de conmutación por error o disyuntores (que evitan que los servicios intenten repetir operaciones fallidas) para funcionar correctamente.
El MTTF también proporciona a los arquitectos una métrica de orientación para combinar servicios. Si una aplicación depende de una cadena de dependencias de bajo MTTF (que fallarán con más frecuencia), los equipos de DevOps pueden optar por desacoplarlas o agregar rutas de respaldo para evitar fallas en cascada entre los servicios.
El MTTF ayuda a los equipos de DevOps a priorizar la deuda técnica al convertir las quejas vagas de “esto se siente frágil” en riesgos de confiabilidad mensurables que pueden clasificarse y sobre los cuales pueden tomar acciones. Pueden utilizar los datos del MTTF para crear un backlog de confiabilidad ordenado por el MTTF y el impacto del incidente, de modo que los refactores, rediseños y actualizaciones de dependencias se dirijan a las áreas que más dañan la estabilidad del sistema.
Además, los datos del MTTF permiten a las empresas vincular la deuda técnica con los resultados empresariales, al mostrar la frecuencia con la que se interrumpe un servicio y el tiempo de inactividad o las molestias que esto causa a los usuarios a lo largo del tiempo. Esto ayuda a los ingenieros a proporcionar argumentos basados en evidencia para pagar la deuda. En lugar de confiar en la intuición, pueden decir "este módulo falla cada N días y genera el X % de nuestros incidentes", lo que resuena más con los equipos de liderazgo y de producto.
Los SLO son objetivos de rendimiento acordados para un servicio en particular durante un período específico. Ayudan a definir el estado esperado de los servicios y agilizan la toma de decisiones en torno a las modificaciones del sistema.
Los SLO de disponibilidad dictan la ventana de tiempo de inactividad aceptable de un servicio, conocida como presupuesto de error. Los presupuestos de error están diseñados para ayudar a las empresas a equilibrar la innovación y la estabilidad. Si el presupuesto es saludable, los equipos pueden priorizar de forma segura la entrega de características. Si está casi agotado, deberían cambiar el enfoque a la confiabilidad.
Un servicio con un MTTF bajo puede consumir rápidamente el presupuesto de errores, lo que indica que el SLO no es realista para el diseño actual o que los equipos de TI deben aumentar la confiabilidad del servicio para aumentar el MTTF.
El MTTF y el MTBF son métricas de confiabilidad que describen cuánto tiempo tiende a funcionar el equipamiento, pero se aplican a diferentes tipos de activos y ciclos de vida. Mientras que el MTTF representa el tiempo promedio hasta la primera falla de un componente, el MTBF representa el tiempo promedio entre ciclos de falla.
El MTTF estima el tiempo promedio de funcionamiento de un activo no reparable hasta una falla permanente, luego de lo cual debe ser reemplazado. Asume que un solo evento de falla pondrá fin a la vida útil de un componente.
El MTTF se aplica a componentes de hardware que se reemplazan directamente, como discos de almacenamiento, unidades centrales de procesamiento (CPU) y cables. También se aplica a componentes de software como contenedores y microservicios, que finalmente se sustituyen por una nueva versión o un servicio diferente en lugar de repararse in situ.
El MTBF mide la cantidad promedio de tiempo entre fallas consecutivas de activos reparables, incluidos servidores, componentes de red y código de software, que se reparan y vuelven a funcionar después de averías. Asume que un equipamiento fallará, será reparado y luego volverá a fallar, por lo que la vida útil del sistema comprende varios ciclos de “falla → reparación”.
En conjunto, las métricas del MTTF y MTBF informan cómo los equipos de TI abordan la gestión de incidentes y servicios de TI.
En muchas arquitecturas, los componentes no reparables (seguidos con MTTF) están integrados dentro de sistemas grandes, complejos y reparables (seguidos con MTBF), por lo que el MTTF puede ayudar a los equipos a predecir cuándo los mecanismos internos forzarán una falla que contribuya al MTBF del sistema más grande.
Supongamos que los datos de observabilidad revelan que un microservicio de procesamiento de pagos dentro de una aplicación de venta minorista tiene un MTTF de 1000 horas antes de que una fuga de memoria crítica provoque que se bloquee irremediablemente. Los equipos de DevOps pueden programar y automatizar reinicios de microservicios a las 800 horas para evitar una cadena de fallas que harían que el MTBF de la aplicación cayera en picada.
Como tal, el reemplazo preventivo del microservicio no reparable aumenta directamente la confiabilidad de toda la aplicación.
Ambas métricas también son fundamentales para la planificación de disponibilidad y mantenimiento. El MTTF apoya decisiones sobre la gestión de inventario y el almacenamiento de piezas de repuesto, mientras que el MTBF apoya decisiones sobre los calendarios de mantenimiento preventivo y la frecuencia esperada de interrupciones.
Utilizado junto con métricas de tiempo de reparación, como MTTR, MTTF y MTBF, permite a los planificadores estimar el tiempo de actividad del sistema, presupuestar las piezas de repuesto y ajustar los sistemas de TI para una confiabilidad óptima.
El proceso para aumentar el MTTF de un activo varía ampliamente según el sistema en cuestión, sus dependencias, el ecosistema DevOps más grande en el que opera y los objetivos comerciales más amplios. Sin embargo, suele implicar ciertas prácticas clave, entre ellas:
Aproveche el poder de la IA y la automatización para resolver problemas de manera proactiva en toda la pila de aplicaciones.
Utilice el software y las herramientas de DevOps para crear, desplegar y gestionar aplicaciones nativas de la nube en múltiples dispositivos y entornos.
Acelere la agilidad y el crecimiento empresarial: modernice continuamente sus aplicaciones en cualquier plataforma con nuestros servicios de consultoría en la nube.