Phase 17 - Lesson 24

Ingeniería del caos para LLMs en producción

La ingeniería del caos para LLMs es una disciplina propia en 2026. Prerrequisitos antes de ejecutar experimentos en producción: SLI/SLO definidos, observabilidad de trazas+métricas+registros, rollback automatizado, runbooks y personal de guardia. La arquitectura tiene cuatro planos: control (programador de experimentos), objetivo (servicios, infraestructura, almacenes de datos), seguridad (protecciones + aborto + filtros de tráfico), observabilidad (métricas + trazas + registros) y retroalimentación (para ajustes de SLO). Las barreras de protección (guardrails) son obligatorias: las alertas de tasa de consumo (burn-rate) pausan los experimentos si el consumo diario del presupuesto de errores es mayor a dos veces el esperado; las ventanas de supresión + la correlación de ID de traza eliminan el ruido de las alertas. Cadencia: pequeño experimento canario semanal + revisión de SLO; game day mensual + postmortem; auditoría de resiliencia trimestral entre equipos + mapeo de dependencias. Experimentos específicos de LLM: sobrecarga de memoria, fallos de red, caídas del proveedor, prompts malformados y tormentas de desalojo (eviction storms) en la caché KV. Herramientas: Harness Chaos Engineering (recomendaciones derivadas de LLM, reducción del radio de impacto, integración con herramientas MCP); LitmusChaos (CNCF); Chaos Mesh (CNCF nativo de Kubernetes).

Tipo: Learn Lenguajes: Python (stdlib, ejecutor de experimentos de caos de juguete) Prerrequisitos: Phase 17 · 23 (SRE for AI), Phase 17 · 13 (Observability) Tiempo: ~60 minutos

Objetivos de Aprendizaje

• Nombrar los cinco prerrequisitos de la ingeniería del caos (SLI/SLO, observabilidad, rollback, runbooks, personal de guardia) y explicar por qué omitir cualquiera de ellos interrumpe la práctica.
• Diagramar los cuatro planos (control, objetivo, seguridad, observabilidad) y el ciclo de retroalimentación hacia el SLO.
• Enumerar cinco experimentos específicos de LLM (sobrecarga de memoria, fallo de red, caída del proveedor, prompt malformado, tormenta de desalojo en la caché KV).
• Elegir una herramienta (Harness, LitmusChaos o Chaos Mesh) dada la pila tecnológica.

El Problema

Las pruebas de caos en pilas tradicionales están consolidadas. Las pilas de LLM añaden nuevos modos de fallo. Un prompt de 4K tokens con un carácter dañado paraliza el tokenizador durante 12 segundos. Un proveedor upstream devuelve 429; tu pasarela reintenta la solicitud; tu servicio sufre un OOM debido a la concurrencia amplificada por los reintentos. Una tormenta de desalojo de la caché KV bajo una carga repentina genera cascadas de re-prellenado inicial (re-prefill) que saturan el procesamiento informático.

Ninguno de estos fallos aparece en las pruebas unitarias. La ingeniería del caos es la forma de descubrirlos antes de que lo hagan los usuarios.

El Concepto

Prerrequisitos

No ejecutes experimentos de caos en producción sin:

1. SLI/SLO — definido service-level indicators and objectives.
2. Observabilidad — trazas, métricas y registros conectados a paneles (dashboards).
3. Rollback automatizado — rollback de banderas de política (Phase 17 · 20).
4. Runbooks — estructurados (Phase 17 · 23).
5. Personal de guardia — alguien para responder.

La falta de cualquiera de ellos significa que el caos se convertirá en un incidente real.

Cuatro planos + retroalimentación

Plano de control (control plane) — programador de experimentos (flujo de trabajo de Litmus, programación de Chaos Mesh, interfaz de usuario de Harness).

Plano objetivo (target plane) — servicios, pods, nodos, balanceadores de carga, almacenes de datos.

Plano de seguridad (safety plane) — botón de apagado de emergencia (kill switch), ventanas de supresión, límites de radio de impacto, compuertas de presupuesto de errores.

Plano de observabilidad (observability plane) — métricas normales + correlación de ID de traza para distinguir fallos inducidos por el caos de los fallos naturales.

Ciclo de retroalimentación — los hallazgos alimentan los ajustes de SLO, actualizaciones de runbooks y correcciones de código.

Las salvaguardas son obligatorias

• Alerta de tasa de consumo (burn-rate): pausa el experimento si el consumo diario del presupuesto de errores supera dos veces el esperado.
• Ventanas de supresión: silencia las alertas no relacionadas con el experimento dentro del radio de impacto durante la ejecución.
• Correlación de ID de traza: todos los errores inducidos por experimentos llevan una etiqueta para que el personal de guardia pueda desduplicarlos.

Cinco experimentos específicos de LLM

1. Sobrecarga de memoria: fuerza una tormenta de preemoción de caché KV enviando solicitudes de contexto largo con alta concurrencia. Observa: ¿el servicio descarta la carga de forma controlada o colapsa?
2. Fallo de red: corta la conectividad entre la pasarela de inferencia y el proveedor. Observa: ¿se activa el plan de contingencia (fallback) dentro del SLA? (Phase 17 · 19)
3. Simulación de caída del proveedor: devuelve 100% 429 desde OpenAI. Observa: ¿el enrutamiento realiza failover hacia Anthropic? (Phase 17 · 16, 19)
4. Prompt malformado: inyecta una carga útil que paralice el tokenizador (por ejemplo, unicode profundamente aninado, un punto de código UTF-8 gigante). Observa: ¿una sola solicitud bloquea un worker?
5. Tormenta de desalojo en la caché KV: fuerza el desalojo saturando el presupuesto de bloques de vLLM. Observa: ¿LMCache se recupera o el servicio se degrada?

Cadencia

• Semanal: pequeños experimentos canarios en staging, quizás 5% en producción.
• Mensual: game day programado sobre un escenario específico; asistencia de varios equipos; postmortem.
• Trimestral: auditoría de resiliencia entre equipos; actualización del mapa de dependencias.

Herramientas

• Harness Chaos Engineering: comercial; recomendaciones de experimentos derivadas de IA; reducción del radio de impacto; integración con herramientas MCP.
• LitmusChaos: graduado de CNCF; basado en flujos de trabajo de Kubernetes.
• Chaos Mesh: sandbox de CNCF; estilo CRD nativo de Kubernetes.
• Gremlin: comercial; amplio soporte.
• AWS FIS / Azure Chaos Studio: ofertas administradas en la nube.

Comenzar con poco

Primer experimento: eliminar un pod (pod-kill) de una réplica de decodificación bajo tráfico estable. Observa el enrutamiento y la recuperación. Si esto funciona y parece seguro, avanza hacia el caos de red.

Primer experimento específico de LLM: inyecta un error 429 de un proveedor durante 5 minutos. Observa el fallback. La mayoría de los equipos descubren que su contingencia no estaba completamente probada.

Números que debes recordar

• Four planes: control, target, safety, observability.
• Pausa por tasa de consumo: 2 veces la queima diaria esperada del presupuesto.
• Cadencia: experimento canario semanal, game day mensual, auditoría trimestral.
• Cinco experimentos de LLM: memoria, red, proveedor, prompt malformado, tormenta de caché KV.

Úsalo

code/main.py simula tres experimentos de caos con compuertas en el plano de seguridad. Reporta qué experimentos activarían el aborto por tasa de consumo.

Entrégalo

Esta lección produce outputs/skill-chaos-plan.md. Dada la pila y la madurez, selecciona los primeros tres experimentos y las herramientas.

Ejercicios

1. Ejecuta code/main.py. ¿Qué experimento activa la compuerta de la tasa de consumo y por qué?
2. Diseña los primeros cinco experimentos de caos para un servicio RAG basado en vLLM. Incluye los criterios de éxito.
3. Tu alerta de tasa de consumo pausó un experimento. ¿Cómo determinas la causa raíz: caos o natural?
4. Argumenta si el caos debería ejecutarse en producción o solo en staging. ¿Cuándo es producción la respuesta correcta?
5. Nombra tres modos de fallo específicos de LLM que el caos de red genérico no puede reproducir.

Términos Clave

Leituras Adicionales

• DevSecOps School — Chaos Engineering 2026 Guide
• Ankush Sharma — Observability for LLMs (book)
• LitmusChaos (CNCF)
• Chaos Mesh (CNCF)
• Harness Chaos Engineering
• AWS FIS