Observabilidad con IA en Netflix: cómo un grafo de conocimiento convierte 38 millones de eventos por segundo en diagnósticos automáticos

Un incidente reciente en Netflix necesitó cuatro horas desde la primera alerta hasta su resolución, nueve equipos y más de 30 ingenieros para resolver ese problema y otros tres relacionados. En un caso, el equipo que recibió el ticket ya llevaba horas depurando el mismo fallo. La causa era casi absurda: un servicio recortó su propia capacidad por considerarse poco crítico y provocó errores en cascada hasta los dispositivos de los usuarios. Esa anécdota, contada en QCon London 2026 por los ingenieros Prasanna Vijayanathan y Renzo Sanchez-Silva, resume por qué Netflix está apostando por la observabilidad con IA: cuando los datos viven en silos, las personas hacen de pegamento, y eso no escala.

Las cifras explican el problema. Netflix alcanzó 65 millones de streams simultáneos en el combate Jake Paul vs. Mike Tyson, procesa más de 2.000 millones de peticiones diarias desde sus aplicaciones y maneja más de 38 millones de eventos de logging por segundo, a lo que se suman miles de microservicios y miles de experimentos A/B en paralelo. Según los ponentes, a esta escala ya no es un problema de herramientas, sino de ingeniería de datos. Su respuesta es E2EGraph, un grafo de conocimiento que modela cada experiencia de usuario como una red de sesiones, clientes, servicios e infraestructura. Los nodos son sesiones, apps, microservicios y componentes de red. Las aristas son peticiones y dependencias, enriquecidas con latencia, tasa de error, impacto en calidad de experiencia (QoE), versiones y geografía.

La pieza clave es una ontología operativa: una especificación formal de tipos, propiedades y relaciones, expresada en tripletas (sujeto, predicado, objeto) como "api-gateway | ownedBy | Team Bedrock" o "INC-5377 | affects | api-gateway". Como explicó Sanchez-Silva, no se trata solo del dato, sino de las relaciones entre datos. Hoy conecta 12 espacios de nombres operativos (Slack, alertas, métricas, logs, incidentes y más) y unifica la telemetría MELT (métricas, eventos, logs y trazas). Sobre esa base construyen AutoSRE, una arquitectura de agentes tipo "mezcla de expertos". Un agente coordinador descompone una pregunta como "¿por qué empeora el tiempo de carga en la UI de TV?" y la reparte entre agentes especializados (métricas en Atlas, alertas en Radar, experimentos en ABlaze, plataformas cliente, despliegues). Todos consultan el mismo grafo, y el coordinador sintetiza la causa más probable: un rollout, un experimento mal configurado o una dependencia degradada.

Un matiz importante: la charla es un plano de arquitectura y una hoja de ruta, no un caso con ROI publicado. Netflix no ha divulgado reducciones concretas del tiempo de resolución. La predicción de fallos y la autocuración (rollbacks dirigidos, redirección de tráfico, cambios en feature flags, ajustes de capacidad) figuran como próximos pasos.

Qué puedes aplicar en tu empresa: lecciones de observabilidad con IA

No necesitas 38 millones de eventos por segundo para encontrar lo útil. El patrón se resume en una idea: antes de poner agentes de IA, ordena el conocimiento. Netflix no empezó por el modelo, sino por la estructura de los datos. Un enfoque similar aparece en su Model Lifecycle Graph para gestionar cientos de modelos de machine learning: los grafos se usan como capa que une lo que antes estaba disperso.

Pasos concretos para empezar:

Mide tu coste de coordinación. Cuenta cuántos equipos y horas consume un incidente típico, y cuánto tiempo se pierde en saber quién debe atenderlo. Esa es tu línea base.

Define un vocabulario común. Acuerda qué es una aplicación, un incidente, un despliegue, un experimento y quién es el propietario de cada uno. Esa es tu ontología mínima, y empieza con una docena de conceptos, no con cientos.

Conecta primero las fuentes de mayor valor: alertas, despliegues y propiedad de servicios. Casi siempre explican la mayoría de las causas raíz.

Guarda instantáneas del estado. Netflix captura el grafo en el momento de una regresión para comparar el estado sano con el degradado. Es barato y muy útil.

Usa agentes especializados, no uno que lo sepa todo. Cada agente consulta una fuente; un coordinador integra. Es más fácil de depurar y de evaluar con rigor, como hizo Elastic con sus agentes.

Otro detalle valioso es el Knowledge Flywheel: observar, enriquecer e inferir, de modo que cada vuelta codifica conocimiento para la siguiente. Netflix lo combina con un segundo ciclo de código en el que Claude trabaja como co-desarrollador en un git worktree aislado y propone un pull request que una persona revisa y fusiona. La IA acelera, pero el humano mantiene el control.

Cuándo conviene adoptar automatización del triaje y la causa raíz

El momento adecuado llega cuando tu problema ya no es la falta de datos, sino el tiempo perdido en correlacionarlos. Las señales son claras: incidentes que atraviesan varios equipos, alertas sin contexto, tickets mal asignados y conocimiento atrapado en chats. Los resultados tempranos se ven en el triaje y la reducción de reasignaciones, como en el caso de Miro, que redujo los bugs de días a horas con IA.

Errores a evitar: saltar a la autocuración sin tener primero diagnóstico fiable, modelar demasiado pronto cientos de entidades y dejar que los agentes actúen sin revisión humana en producción. Siguiendo la secuencia de Netflix (detectar, priorizar por impacto en usuarios, asignar, explicar la causa, predecir y recién después actuar), cada etapa genera confianza para la siguiente.

La lección de fondo es que la observabilidad con IA no empieza con un modelo más potente, sino con un grafo que le dé contexto. Si hoy un incidente en tu empresa necesita media docena de equipos para encontrar al responsable, ¿cuánto de ese tiempo se evitaría con una ontología compartida de solo diez conceptos?