Reduce el costo de las caídas de IA: SLOs, respaldos y presupuestos de inactividad

downtime_cost = duration_min × revenue_per_min × failure_fraction; si downtime_cost > downtime_budget, la dependencia falla. El incidente de Microsoft es el caso de prueba: los reportes de usuarios sobre problemas de Outlook aumentaron bruscamente en Downdetector, y la autenticación se vio afectada. Una dependencia de servicio que puede fallar es una superficie con costo, no una dependencia aguas arriba neutral. La solución no son más paneles. Es un mapa de dependencias, un SLO, un respaldo, un presupuesto de inactividad y un ejercicio de fallo que demuestre que el respaldo funciona.

Traza el incidente de Microsoft como una ruta de funcionalidad, comprobando cada estado contra downtime_budget. Mala configuración de autenticación: una posible mala configuración impidió que los componentes de autenticación se desplegaran como se esperaba, por lo que la autenticación es la dependencia que hay que mapear y el estado que hay que comprobar contra downtime_budget. Impacto en múltiples servicios: el incidente afectó Exchange Online y algunos otros servicios. El impacto reportado se extendió a múltiples servicios de Microsoft 365. Esa ruta del usuario es la superficie del SLO y el estado que hay que comprobar contra downtime_budget. Restauración parcial: la conectividad de los buzones volvió a la normalidad mientras continuaba la restauración de la búsqueda, por lo que el respaldo degradado debe mantener downtime_cost por debajo de downtime_budget.

Mapea la dependencia antes de definir el SLO

Comienza con un mapa de dependencias que nombre la superficie de fallo, no el proveedor. Para cada ruta de servicio de IA, lista las dependencias que pueden bloquear una solicitud: autenticación, autorización, inferencia de modelo, recuperación, búsqueda, embedding, almacenamiento, feature flags, telemetría y limitación de tasa. Para cada una, responde a tres preguntas. ¿Cuál es el resultado visible para el usuario si falla? ¿Cuál es el respaldo? ¿Cuál es el presupuesto de inactividad, expresado como un límite en moneda por incidente? Si no puedes responder a las tres, la dependencia no está lista para tráfico de producción.

Una dependencia de autenticación suele ser la más peligrosa porque puede fallar antes de que tu código se ejecute. Una API de modelo puede fallar después de que ya hayas gastado tokens. Una dependencia de búsqueda puede fallar en silencio al devolver resultados obsoletos, vacíos o de baja calidad. Una dependencia de almacenamiento puede fallar al añadir latencia que hace que toda la experiencia se sienta rota. Cada una necesita un respaldo diferente. No las trates como intercambiables.

Define SLOs que coincidan con la ruta del usuario

Un SLO es una promesa sobre una ruta del usuario, no sobre un servicio. No definas un SLO para la disponibilidad del modelo si la ruta del usuario es hacer una pregunta y obtener una respuesta citada. El SLO debe cubrir la ruta completa: autenticación, recuperación, inferencia, generación de respuesta y entrega. Si alguna dependencia falla, el SLO debe decirte si el usuario obtuvo una respuesta útil, una respuesta degradada o ninguna respuesta en absoluto.

Usa los presupuestos de error como mecanismo de control. Si una dependencia consume demasiado presupuesto de error, dejas de añadir funcionalidades que dependen de ella. Añades respaldos. Añades caché. Añades disyuntores de circuito. Añades mensajes de producto más claros. El presupuesto no es una métrica de vanidad. Es el punto en el que la ingeniería deja de optimizar para el camino feliz y empieza a pagar por el camino de fallo.

Un buen SLO tiene tres propiedades. Es observable desde la ruta del usuario. Es verificable en un ejercicio de fallo. Está vinculado a una decisión de costo. Si el SLO es solo un porcentaje en un panel, es decoración. Si cambia lo que lanzas, lo que guardas en caché y lo que le dices al usuario, es un control operativo.

Define el respaldo y limita el costo de inactividad

Un respaldo es una decisión de producto, no solo técnica. Para cada dependencia, elige el modo degradado de antemano. Si la autenticación está degradada, ¿permites una sesión limitada de solo lectura? Si la búsqueda está degradada, ¿proporcionas respuestas en caché con una advertencia de frescura? Si la inferencia de modelo está degradada, ¿recurre a un modelo más pequeño, a una respuesta basada en reglas o a una cola? Si el almacenamiento está degradado, ¿proporcionas contexto obsoleto o bloqueas la solicitud? El respaldo debe ser lo suficientemente explícito para que un usuario pueda saber que el sistema está degradado sin leer una página de estado.

Luego limita el costo de inactividad. El presupuesto de inactividad es un límite en moneda por incidente: la pérdida máxima aceptable por un fallo de dependencia antes de cambiar la arquitectura. Si se excede el presupuesto, la dependencia ya no es una dependencia. Es un punto único de fallo que debe eliminarse, replicarse o reemplazarse. El presupuesto debe revisarse después de cada incidente, no solo después de una caída mayor. Si una dependencia consume presupuesto repetidamente, la respuesta no es subir el SLO. La respuesta es reducir el poder de la dependencia sobre el producto.

Ejecuta ejercicios de fallo que prueben el respaldo, no solo la alerta. Apaga la dependencia. Simula una mala configuración. Devuelve resultados de búsqueda obsoletos. Aumenta la latencia. Fuerza que la autenticación falle para un subconjunto de usuarios. Luego mide la ruta del usuario. ¿Se activó el respaldo? ¿Reflejó el SLO la degradación? ¿El mensaje de producto coincidió con el estado real? ¿La ruta del usuario se mantuvo dentro del límite en moneda? Si el ejercicio solo demuestra que se disparó una alerta, no ha demostrado nada útil.

La lista de verificación se aplica al estado de restauración parcial del incidente de Microsoft. Mapea la dependencia de autenticación. Define un SLO en la ruta del usuario en múltiples servicios. Define el respaldo para la restauración continua de la búsqueda. Limita el costo de inactividad. Ejecuta el ejercicio. Un producto de IA es tan confiable como su dependencia de servicio más débil, y el costo de esa debilidad no es abstracto. La conectividad de los buzones estaba normal mientras continuaba la restauración de la búsqueda, por lo que la ruta del usuario sigue degradada; el respaldo se cumple solo si esa ruta degradada mantiene downtime_cost por debajo de downtime_budget, de lo contrario reduce o elimina la dependencia de búsqueda.