Phase 17 - Lesson 23

SRE para IA — Respuesta a incidentes multiagente, Runbooks, Detección predictiva

El AI SRE utiliza LLMs respaldados por datos de infraestructura (logs, runbooks, topología de servicios) a través de RAG para automatizar las fases de investigación, documentación y coordinación. El patrón de arquitectura para 2026 es la orquestación multiagente: agentes especializados (logs, métricas, runbooks) coordinados por un supervisor; la IA propone hipótesis y consultas, mientras que los humanos aprueban las decisiones de juicio. Datadog Bits AI y Azure SRE Agent ofrecen esto como productos administrados. Los runbooks están evolucionando: NeuBird Hawkeye utiliza evaluación adversaria (dos modelos analizan el mismo incidente; concordancia = confianza, desacuerdo = incertidumbre); la memoria operativa persiste a pesar de la rotación del equipo. La auto-reparación (auto-remediation) sigue siendo cautelosa: la IA sugiere, los humanos aprueban. Las acciones totalmente autónomas son limitadas (reiniciar un pod, revertir un despliegue específico) con salvaguardas estrictas — cualquiera que intente vender "configúralo y olvídate" está exagerando. Frontera emergente: predicción previa al incidente. Investigaciones del MIT reportan que un LLM entrenado con logs históricos + temperaturas de GPU + patrones de error de API predijo el 89% de las caídas de servicio con 10-15 minutos de anticipación. Proyección: el 95% de los LLMs empresariales tendrán failover automatizado para finales de 2026.

Tipo: Learn Lenguajes: Python (stdlib, simulador de triaje de incidentes multiagente de juguete) Prerrequisitos: Phase 17 · 13 (Observability), Phase 17 · 24 (Chaos Engineering) Tiempo: ~60 minutos

Objetivos de Aprendizaje

• Diagramar la arquitectura de AI SRE multiagente: supervisor + agentes especializados (logs, métricas, runbooks) + puerta de control de aprobación humana.
• Explicar por que la auto-reparación es limitada (reiniciar pod, revertir despliegue) en lugar de amplia (reestructurar la arquitectura del servicio).
• Nombrar el patrón de evaluación adversaria (NeuBird Hawkeye): dos modelos coinciden = confianza; no coinciden = escalamiento.
• Citar el resultado del MIT de un 89% de detección temprana y la restricción operativa: las predicciones sin acción son solo paneles (dashboards).

El Problema

Un ingeniero de guardia recibe una alerta (paged) a las 3 a.m. "Alta tasa de errores en checkout". Revisa Datadog, Loki, tres runbooks y el registro de despliegue. 30 minutos después, se da cuenta de que la causa raíz es un OOM en vLLM debido a un pico de caché KV. Reinicia el pod; el error se resuelve.

En 2026, los primeros 20 minutos de esa investigación son automatizables. Agrupar registros por servicio, correlacionar con despliegues recientes, compararlos con runbooks: todo esto es RAG + uso de herramientas (tool-use). Un agente supervisado puede realizar un primer filtrado de triaje y presentar una hipótesis antes de que el humano abra Datadog.

La auto-reparación totalmente autónoma es un problema diferente. Reiniciar un pod: seguro. Escalar la piscina de GPUs: seguro si la política lo permite. Rearquitectar el servicio: absolutamente no. La disciplina radica en trazar esta delgada línea de límites.

El Concepto

Arquitectura multiagente

          Incidente
              │
              ▼
         Supervisor
         /    |    \
        ▼     ▼     ▼
Agente Log  Agente Métrica Agente Runbook
        │     │     │
        └─────┴─────┘
              │
              ▼
        Hipótesis + evidencia
              │
              ▼
      Aprobación humana
              │
              ▼
        Acción (limitada)

El supervisor divide el incidente en subconsultas. Los agentes especializados tienen acceso a herramientas (búsqueda de logs, PromQL, recuperación de documentos). El supervisor sintetiza y presenta la hipótesis + evidencia al humano. El humano aprueba o redirecciona.

Alcance de la auto-reparación

Seguro (limitado): reiniciar pod, revertir un despliegue específico, escalar pool dentro de límites preaprobados, habilitar una bandera de funcionalidad (feature flag) preaprobada.

Inseguro (amplio): cambiar la topología del servicio, modificar límites de recursos, desplegar código nuevo, cambiar IAM, alterar bases de datos.

Cualquiera que intente vender "configúralo y olvídate" está exagerando. El conjunto seguro crece a medida que madura AI SRE, pero el límite es real.

Evaluación adversaria (NeuBird Hawkeye)

Dos modelos analizan de manera independiente el mismo incidente. Si coinciden en la causa raíz, la confianza es alta. Si no coinciden, se escala al humano con ambas hipótesis visibles. Un patrón simple, pero un filtro efectivo contra causas raíces alucinadas.

Memoria operativa

La rotación del equipo es la muerte silenciosa del SRE tradicional: el conocimiento tribal se va. AI SRE almacena runbooks + post-mortems en una base de datos vectorial; los agentes realizan búsquedas ante cada nuevo incidente. Cuando ingresan nuevos ingenieros, la IA tiene el historial completo.

Predicción previa al incidente

Investigación del MIT de 2025: un LLM entrenado con registros históricos, temperaturas de GPU y patrones de error de API predijo el 89% de las caiones entre 10 y 15 minutos antes de que ocurrieran en el conjunto de prueba.

Control de realidad: las predicciones sin acción son solo paneles. La pregunta operativa es "¿cuando predigamos, qué hacemos?". ¿Drenado preventivo (pre-emptive drain)? ¿Alerta? ¿Autoescalado? La respuesta depende de cada política.

Productos en 2026

• Datadog Bits AI — copiloto de SRE administrado dentro de Datadog.
• Azure SRE Agent — nativo de Azure.
• NeuBird Hawkeye — evaluación adversaria + memoria operativa.
• PagerDuty AIOps — triaje + desduplicación.
• Incident.io Autopilot — comandante de incidentes + coordinación.

Runbooks como código

Los runbooks evolucionan de páginas de Confluence a markdown versionado con secciones estructuradas (síntoma, hipótesis, verificación, acción). Los runbooks estructurados alimentan una mejor recuperación de RAG. Comience cualquier implementación de AI-SRE transformando los runbooks no estructurados en estructurados.

Números que debes recordar

• Detección temprana del MIT: 89% de las caídas, tiempo de anticipación de 10-15 min.
• Triaje multiagente: supervisor + (logs, métricas, runbooks) + humano.
• Conjunto de auto-reparación seguro: reiniciar pod, revertir despliegue, escalar dentro de límites.
• Evaluación adversaria: dos modelos independientes; acuerdo = confianza.

Úsalo

code/main.py simula un triaje multiagente: el agente de log encuentra el error, el agente de métricas detecta el pico de CPU y el agente de runbook lo asocia con un problema conocido. El supervisor clasifica las hipótesis.

Entregalo

Esta lección produce outputs/skill-ai-sre-plan.md. Considerando las guardias actuales, el volumen de incidentes y la madurez del equipo, diseña una implementación de AI SRE.

Ejercicios

1. Ejecuta code/main.py. ¿Qué ocurre si los agentes de log y de métricas no coinciden? ¿Cómo lo resuelve el supervisor?
2. Define tres acciones de auto-reparación "seguras" para tu servicio. Justifica cada una.
3. Escribe una plantilla estructurada de runbook: secciones, campos obligatorios, comandos de verificación.
4. La detección predictiva se activa con 12 min de anticipación. ¿Cuál es tu política: alerta, drenado previo (pre-drain) o ambos?
5. Argumenta si un equipo de 3 personas debería adoptar AI SRE en 2026 o esperar. Considera madurez, volumen y riesgo.

Términos Clave

Leituras Adicionales

• incident.io — AI SRE Complete Guide 2026
• InfoQ — Human-Centred AI for SRE
• DZone — AI in SRE 2026
• Datadog Bits AI
• NeuBird Hawkeye
• awesome-ai-sre