MTTD, MTTR, SLO, presupuestos de errores y burn rate en infraestructura de IA

Las métricas SRE convierten la fiabilidad de la IA y de la infraestructura en algo que los equipos pueden medir y gobernar. El MTTD te dice con qué rapidez se detectan los problemas y el MTTR, con qué rapidez se restablece el servicio. Los SLO fijan el objetivo de fiabilidad, el presupuesto de errores cuantifica cuánta falta de fiabilidad es aceptable y la burn rate muestra a qué velocidad se está gastando ese presupuesto.

En infraestructura de IA, estas métricas tienen que ir más allá del tiempo de actividad de las aplicaciones. Pueden aplicarse al éxito del entrenamiento, al éxito de la inferencia, al throughput de tokens, al tiempo hasta el primer token, a la disponibilidad de los aceleradores, a la recuperación ante fallos y a otras rutas críticas de las que depende convertir cómputo en un servicio estable.

¿Qué es el MTTD?

El tiempo medio de detección (Mean Time to Detect, MTTD) mide cuánto tarda el sistema o el equipo de operaciones en detectar un incidente después de que empiece.

Una fórmula sencilla es:

MTTD = Sum of detection delays / Number of incidents

Lo difícil es definir cuándo empieza un incidente. En un evento de hardware, el inicio puede ser el primer error ECC. En un incidente de servicio, puede ser la primera petición que incumple el indicador de servicio, y en un problema de refrigeración, la primera vez que se supera un umbral. Elige una regla para cada clase de incidente y aplícala siempre igual.

Un MTTD bajo significa que los problemas se ven pronto; uno alto significa que los fallos pueden afectar a las cargas de trabajo durante demasiado tiempo antes de que alguien se entere. La detección automática puede reducir el MTTD, pero solo si las alarmas tienen sentido. Una tormenta de alarmas en la que nadie confía puede detectar el problema en segundos sobre el papel mientras la respuesta humana sigue siendo lenta, así que el MTTD debe leerse junto con la calidad de las alarmas y la consolidación de incidentes.

¿Qué es el MTTR?

Mean Time to Repair, Recover, Resolve o Restore se abrevia normalmente como MTTR, pero cada organización usa la segunda palabra de forma distinta, así que define la tuya. En operaciones de infraestructura, la versión más útil suele ser el tiempo hasta restablecer el servicio.

Una fórmula sencilla es:

MTTR = Sum of restoration durations / Number of incidents

Otra vez, define las marcas de tiempo de inicio y fin. ¿El reloj arranca con el fallo o con la detección? ¿Se detiene cuando se repara el dispositivo o cuando se restablece el servicio que ve el usuario? Cada respuesta te da una métrica distinta.

En un incidente de entrenamiento de IA, el servicio puede darse por restablecido cuando el trabajo se reanuda desde un checkpoint en recursos sanos, aunque la GPU averiada se repare más tarde. Suele ser una métrica operativa mejor porque mide cuánto tiempo estuvo interrumpido el trabajo productivo. El tiempo de reparación del hardware puede seguirse aparte.

¿Cómo se aplican el MTTD y el MTTR a los fallos de GPU?

Ante un fallo de GPU, el MTTD mide con qué rapidez la plataforma identifica que la tarjeta o el nodo ya no está sano. El MTTR mide con qué rapidez la carga de trabajo afectada vuelve a un estado sano con el proceso de recuperación definido.

Un buen ciclo de tolerancia a fallos puede reducir el MTTR así:

Detectar la tarjeta defectuosa
Dejar de programar trabajo en ella
Encontrar el trabajo afectado
Elegir un checkpoint válido
Asignar recursos sanos de reemplazo
Reiniciar el trabajo
Validar que avanza

Por eso importan la salud del hardware y su integración con el planificador. Si el equipo necesita 20 minutos para averiguar qué trabajo usa la tarjeta, esa búsqueda pasa a formar parte del MTTR. Si un checkpoint tiene seis horas de antigüedad, el servicio puede restablecerse rápido pero el negocio pierde igualmente seis horas de cómputo, y ese trabajo perdido debe medirse por separado.

El artículo sobre cómo la infraestructura de IA puede recuperar automáticamente los trabajos de entrenamiento tras un fallo de GPU o de servidor explica este ciclo de recuperación en detalle.

¿Qué es un SLO?

Un objetivo de nivel de servicio (Service Level Objective, SLO) es un valor objetivo para un indicador de nivel de servicio durante un periodo definido. La guía SRE de Google trata los SLO como objetivos de fiabilidad del servicio basados en indicadores de nivel de servicio medibles.

Para un servicio de inferencia, algunos indicadores posibles son:

Tasa de éxito de peticiones
Tasa de éxito de tokens
Latencia
Tiempo hasta el primer token
Throughput de tokens
Tasa de timeouts

Para un servicio de entrenamiento, algunos indicadores posibles son:

Éxito al arrancar trabajos
Éxito al completar tareas
Tiempo en cola
Éxito de los checkpoints
Tiempo de recuperación
Disponibilidad de recursos

Para la infraestructura, algunos indicadores posibles son:

Disponibilidad de aceleradores
Disponibilidad de red
Latencia de almacenamiento
Éxito del aprovisionamiento
Respuesta en la reparación de hardware

No crees SLO para cada métrica. Elige los indicadores que representan la fiabilidad que ve el usuario o la que importa al negocio.

¿Cómo se define el SLO de un servicio de IA?

Define el servicio, el indicador, el objetivo, la ventana de medición y la población de eventos. Por ejemplo:

Servicio: endpoint de inferencia en producción
Indicador: peticiones correctas / peticiones elegibles
Objetivo: 99.9 por ciento
Ventana: 30 días móviles
Exclusiones: mantenimiento definido explícitamente o tráfico de prueba no facturable

El número exacto es una decisión de negocio, y el método pesa más. Dos equipos pueden declarar un SLO del 99.9 por ciento contando peticiones distintas, y entonces cualquier comparación carece de sentido. Mantén la definición exportable y versionada.

El modelo operativo de origen también admite niveles de servicio como Gold, Silver y Bronze, para que cada modelo tenga umbrales distintos. Puede ser útil cuando un servicio exige una latencia estricta y otro funciona en modo best effort.

¿Qué es un presupuesto de errores?

Un presupuesto de errores (error budget) es la cantidad de falta de fiabilidad que permite el SLO durante la ventana de medición. Si el SLO es un 99.9 por ciento de éxito, el presupuesto de errores es el 0.1 por ciento restante según esa definición.

Para un SLO basado en peticiones:

Error budget = Total eligible events × Allowed failure fraction

Si hay 1,000,000 de peticiones elegibles y el SLO permite un 0.1 por ciento de fallos:

1,000,000 × 0.001 = 1,000 allowed failed requests

Los fallos siguen siendo indeseables. El presupuesto da a la organización un límite cuantitativo para equilibrar fiabilidad y velocidad de cambio. Si el presupuesto está sano, el equipo tiene margen para el riesgo normal de las entregas, y si se agota, el trabajo de fiabilidad pasa a tener prioridad. El modelo SRE de origen aplica justo este principio: cuando el presupuesto cruza el umbral, las publicaciones pueden congelarse hasta saldar la deuda de fiabilidad.

¿Qué significa burn rate?

La burn rate (tasa de consumo) mide con qué rapidez consume el servicio su presupuesto de errores en comparación con el ritmo que lo gastaría de forma uniforme a lo largo de toda la ventana. Una burn rate de 1 significa que el servicio consume el presupuesto al ritmo medio que lo agotaría justo al cerrar la ventana. Una burn rate mayor que 1 significa que se consume más deprisa, y una muy alta significa que el servicio puede quedarse sin margen enseguida si la situación continúa.

La burn rate es útil porque los recuentos brutos de errores pueden engañar. Diez fallos en un minuto pueden ser graves para un servicio con poco volumen y despreciables para uno con muchísimo. La burn rate relaciona los fallos con el SLO y con el presupuesto que queda.

¿Por qué usar varias ventanas de burn rate?

Varias ventanas ayudan a detectar tanto los incidentes rápidos como la degradación lenta de la fiabilidad. El SRE Workbook de Google describe las alertas multiventana y de burn rate múltiple como una forma de detectar un consumo relevante del SLO sin disparar el ruido de alertas.

Una ventana corta es sensible a los fallos rápidos, y una más larga confirma que la situación dura lo suficiente como para importar. También puedes definir rutas de alerta separadas para consumo rápido y consumo lento. El consumo rápido significa que el presupuesto desaparece deprisa y exige una respuesta urgente. El consumo lento significa que el servicio se degrada durante un periodo más largo y puede necesitar trabajo de fiabilidad planificado.

El modelo operativo de origen usa este mismo concepto con alertas multiventana y de burn rate múltiple. El objetivo es alertar solo cuando el objetivo de fiabilidad corre peligro de verdad.

¿Cómo se aplican los SLO a los servicios de tokens?

Los servicios de tokens pueden usar indicadores que reflejen tanto la disponibilidad como la calidad de la entrega. El material de origen menciona medidas como la tasa de éxito de tokens, el throughput, el tiempo hasta el primer token, la latencia por token y la tasa de timeouts, así que un servicio de modelos puede tener varios SLO. Por ejemplo:

Tasa de éxito de peticiones
Éxito en la generación de tokens
Tiempo hasta el primer token
Continuidad del streaming
Latencia total
Tasa de timeouts

No metas todos los indicadores en una puntuación compuesta si representan experiencias de usuario distintas. Un servicio puede tener una tasa de éxito excelente y una latencia pésima, y el usuario seguirá viendo un mal servicio. Con SLO separados, el modo de fallo queda a la vista.

¿Cómo se aplica SRE a los servicios de entrenamiento?

El SRE de entrenamiento debe centrarse en la fiabilidad del ciclo de vida de los trabajos. Algunos indicadores útiles:

Tiempo de admisión en cola
Éxito al arrancar trabajos
Éxito al completar trabajos
Éxito de los checkpoints
Éxito de la recuperación
Cómputo medio perdido tras un fallo
Disponibilidad de recursos
Tasa de fallos repetidos

Un trabajo de entrenamiento que falla tras 18 horas y se reinicia desde un checkpoint de hace 17 horas está técnicamente recuperado, pero sale caro en términos operativos, y ese cómputo perdido debe verse. Del mismo modo, un planificador puede tener una disponibilidad altísima mientras los usuarios esperan horas por la clase de recurso que pidieron. La fiabilidad del servicio abarca toda la experiencia de conseguir cómputo útil, más allá de que el proceso del planificador esté en marcha.

¿Qué es la tasa de remediación automática?

La tasa de remediación automática mide qué parte de los incidentes elegibles se resuelve mediante acciones automatizadas aprobadas, sin ejecución manual. Una definición sencilla:

Automatic-remediation ratio = Automatically resolved eligible incidents / Total eligible incidents

Define qué significa "elegible". Los incidentes de alto riesgo no deben contarse como fallos de la automatización si la política exige a propósito una aprobación humana.

El modelo SRE de origen separa los incidentes por nivel de riesgo. Los eventos transitorios conocidos pueden recuperarse solos, los incidentes de riesgo controlado pueden ejecutar scripts aprobados con rollback y los cambios con riesgo requieren aprobación en un flujo de trabajo y ejecución canary. Así la tasa de automatización tiene sentido, porque mide la automatización dentro del límite aprobado.

¿Qué es la reducción del toil?

La reducción del toil mide cuánto trabajo operativo manual y repetitivo se ha eliminado o acortado. Algunos indicadores posibles:

Intervenciones manuales por incidente
Minutos de operador por incidente
Número de acciones repetidas automatizadas
Órdenes de trabajo completadas sin ejecutar comandos a mano
Tiempo dedicado a inspecciones rutinarias
Recurrencia de incidentes repetidos

El toil es algo más que "trabajo que a la gente no le gusta". Parte del trabajo manual tiene valor porque exige criterio. La meta es automatizar las acciones repetitivas y previsibles para que los ingenieros se centren en el diagnóstico, la capacidad, la fiabilidad y la mejora. Mide el tiempo que realmente se ahorra; si no, la "automatización" puede acabar siendo un recuento de funciones sin ningún beneficio operativo.

¿Cómo se conectan las revisiones de incidentes con las métricas SRE?

La revisión posterior a un incidente debe convertir los fallos individuales en cambios en el sistema de fiabilidad. La revisión debe conservar:

Cronología
Causa raíz
Factores contribuyentes
Brecha de detección
Brecha de recuperación
Impacto en el servicio
Cómputo perdido
Impacto en el SLO
Consumo del presupuesto de errores
Acciones de mejora
Responsable
Fecha límite

Si el MTTD fue malo, mejora la detección. Si el MTTR fue malo, mejora los runbooks, la asignación de responsables, los checkpoints o la automatización. Si el mismo fallo sigue consumiendo el presupuesto de errores, arregla el problema de fiabilidad de fondo en lugar de mejorar solo el proceso de respuesta. La revisión debe alimentar la base de conocimiento para que los incidentes futuros aprovechen lo aprendido.

¿Cómo afectan los presupuestos de errores a las decisiones de publicación?

Los presupuestos de errores ofrecen un control medible para las publicaciones. Si el servicio está holgadamente dentro de su SLO y le queda presupuesto, las publicaciones normales pueden seguir según la política. Si el presupuesto está casi agotado, los cambios de alto riesgo pueden frenarse, y una vez agotado, el equipo puede congelar las publicaciones no esenciales y priorizar el trabajo de fiabilidad.

Así la discusión pasa de las opiniones a los datos. Los equipos de producto ven la restricción de fiabilidad, los de operaciones pueden mostrar la tendencia de consumo y la dirección ve la fecha prevista de agotamiento. Ahí es donde el presupuesto de errores se gana su sitio como herramienta de gestión.

¿Cómo apoya AIOps a SRE?

AIOps puede reducir el MTTD detectando y correlacionando fallos más deprisa, y puede reducir el MTTR identificando las causas probables y recomendando o ejecutando remediaciones aprobadas. SRE aporta el marco de medición que te dice si esas mejoras son reales.

Si un sistema de AIOps promete un diagnóstico más rápido, compara el MTTD antes y después. Si se añade recuperación automática, compara el MTTR y la recurrencia. Si mejora la correlación de alarmas, compara la carga de trabajo de los operadores y el volumen de incidentes falsos. Si la fiabilidad empeora mientras crece la automatización, la automatización ha fracasado.

La relación entre ambos se trata en cómo AIOps reduce el ruido de alarmas, identifica causas raíz y determina el impacto en el negocio.

¿Qué debe mostrar un panel de SRE?

Un panel de SRE útil debe mostrar el rendimiento de la fiabilidad, el estado del presupuesto, el riesgo de incidentes y el esfuerzo operativo. Como mínimo:

MTTD
MTTR
Cumplimiento del SLO
Presupuesto de errores restante
Burn rate
Previsión de agotamiento del presupuesto
Número de incidentes
Nivel de riesgo
Tasa de remediación automática
Tendencia del toil
Incidentes repetidos
Estado de las acciones posteriores a incidentes

Un ejemplo de plataforma que aplica estas medidas desde la infraestructura hasta los servicios de tokens es Sensaka.

Si yo introdujera SRE en una infraestructura de IA, empezaría con tres servicios críticos en lugar de 100 métricas. Define uno o dos SLO para cada uno, mide el MTTD y el MTTR, crea un presupuesto de errores de 30 días y revisa cada incidente que se coma una parte relevante de él. Cuando las definiciones inspiren confianza, amplía el sistema.