Phase 19 - Lesson 06

Capstone 06 — Agente de resolución de problemas de DevOps para Kubernetes

DevOps Agent de AWS pasó a disponibilidad general (GA), Resolve AI publicó sus playbooks de K8s, NeuBird demostró monitoreo semántico y Metoro vinculó SRE con IA a SLOs por servicio. El formato de producción está consolidado: se dispara un webhook de alerta, un agente lee la telemetría, recorre un gráfico de objetos de K8s, clasifica las hipótesis de causa raíz y publica un resumen en Slack con botones de aprobación. Solo lectura por defecto. Cada remediación es controlada por un ser humano. Este capstone es ese agente, evaluado en 20 incidentes sintéticos y comparado con el agente de AWS en tres casos compartidos.

Tipo: Capstone Lenguajes: Python (agente), TypeScript (integración con Slack) Requisitos previos: Fase 11 (ingeniería de LLM), Fase 13 (herramientas y MCP), Fase 14 (agentes), Fase 15 (autónomos), Fase 17 (infraestructura), Fase 18 (seguridad) Fases ejercitadas: P11 · P13 · P14 · P15 · P17 · P18 Tiempo: 30 horas

Problema

La narrativa de SRE para 2025-2026 se convirtió en: "Los agentes de IA trian incidentes, los humanos aprueban las remediaciones." DevOps Agent de AWS, Resolve AI, NeuBird, Metoro y PagerDuty AIOps entregan este formato en producción. El agente lee métricas de Prometheus, logs de Loki, traces de Tempo, kube-state-metrics y un gráfico de conocimiento (knowledge graph) de objetos de K8s. Produce una hipótesis de causa raíz clasificada con citas de telemetría en menos de cinco minutos. Nunca ejecuta comandos destructivos sin la aprobación humana explícita a través de Slack.

La mayor parte del trabajo difícil es el alcance y la seguridad, no el razonamiento. El agente necesita una superficie RBAC de solo lectura por defecto, un servidor de herramientas MCP robustecido y logs de auditoría de cada comando considerado vs ejecutado. Necesita saber cuándo está fuera de su capacidad y escalar. Y tiene que funcionar de manera lo suficientemente barata para que las cascadas de OOM-kill no generen una factura del agente de $5,000.

Concept

El agente opera sobre un gráfico de conocimiento. Los nodos son objetos de K8s (Pods, Deployments, Services, Nodes, HPAs, PVCs) además de fuentes de telemetría (series de Prometheus, flujos de Loki, traces de Tempo). Las aristas codifican propiedad (Pod -> ReplicaSet -> Deployment), programación (Pod -> Node) y observación (Pod -> serie de Prometheus). El gráfico se mantiene actualizado mediante una sincronización de kube-state-metrics y se remuestrea en cada alerta.

Cuando se dispara una alerta, el agente busca la causa raíz a partir del objeto afectado. Recorre las aristas, extrae los fragmentos de telemetría relevantes (últimos 15 minutos) y elabora una hipótesis. La hipótesis se clasifica según la evidencia: cuántas citas de telemetría la respaldan, qué tan recientes son y qué tan específicas. Las 3 hipótesis principales se envían a Slack con visualizaciones de rutas del gráfico y botones de aprobación para acciones de remediación.

La remediación está controlada. Las acciones permitidas por defecto son de solo lectura. Las acciones destructivas (reducir escala, rollback, eliminar Pods) requieren aprobación en Slack; los hooks de rollback de ArgoCD requieren un token de autenticación que el agente nunca posee. El log de auditoría registra cada comando que el agente consideró (no solo los ejecutados), de modo que el proceso de revisión detecte los casi incidentes (near-misses).

Architecture

PagerDuty / Alertmanager webhook
           |
           v
     FastAPI receiver
           |
           v
   LangGraph root-cause agent
           |
           +---- read-only MCP tools ----+
           |                             |
           v                             v
   K8s knowledge graph              telemetry slices
     (Neo4j / kuzu)              Prometheus, Loki, Tempo
   ownership + scheduling          last 15m, scoped
           |
           v
   hypothesis ranking (evidence weight)
           |
           v
   Slack brief + approval buttons
           |
           v (approved)
   ArgoCD rollback hook / PagerDuty escalate
           |
           v
   audit log: considered vs executed, every command

Stack

Fuentes de observabilidad: Prometheus, Loki, Tempo, kube-state-metrics
Gráfico de conocimiento: Neo4j (gestionado) o kuzu (embebido) de objetos de K8s + aristas de telemetría
Agente: LangGraph con lista de herramientas permitidas, solo lectura por defecto
Transporte de herramientas: FastMCP sobre StreamableHTTP; servidor separado para herramientas destructivas detrás de compuerta de aprobación
Modelos: Claude Sonnet 4.7 para razonamiento de causa raíz, Gemini 2.5 Flash para resumen de logs
Remediación: webhook de rollback de ArgoCD, escalamiento de PagerDuty, tarjeta de aprobación de Slack
Auditoría: log estructurado de solo anexado (considerado, ejecutado, aprobado, resultado)
Despliegue: Despliegue de K8s con su propio rol RBAC estrecho; namespace separado

Build It

Ingesta en el gráfico. Sincroniza kube-state-metrics en Neo4j/kuzu cada 30s. Nodos: Pod, Deployment, Node, Service, PVC, HPA. Aristas: OWNED_BY, SCHEDULED_ON, EXPOSES, MOUNTS, SCALES. Aristas de superposición de telemetría: OBSERVED_BY (un Pod es observado por una serie de Prometheus).
Receptor de alertas. Endpoint de FastAPI que acepta webhooks de PagerDuty o Alertmanager. Extrae los objetos afectados y la violación de SLO.
Superficie de herramientas de solo lectura. Envuelve kubectl, Prometheus query, Loki logql, Tempo traceql a través de FastMCP. Cada herramienta tiene un verbo RBAC estrecho ("get", "list", "describe"). No hay "delete", "exec", "scale" en el servidor por defecto.
Agente de causa raíz. LangGraph con tres nodos: sample extrae el fragmento de telemetría de los últimos 15 minutos, walk consulta el gráfico en busca de objetos vecinos, hypothesize elabora candidatos de causa raíz clasificados con citas de telemetría.
Puntuación de evidencia. Cada hipótesis tiene una puntuación = recencia * especificidad * inverso de longitud de ruta del gráfico * recuento de citas. Devuelve las top-3.
Resumen en Slack. Publica un adjunto con la hipótesis, la visualización de la ruta del gráfico (una imagen de subgráfico renderizada en el servidor) y botones de aprobación para como máximo una acción de remediación.
Compuerta de remediación. Las herramientas destructivas (reducir escala, rollback, eliminar) residen en un segundo servidor MCP detrás de un token de aprobación. El agente solo puede llamarlas después de que un humano apruebe la tarjeta de Slack.
Log de auditoría. JSONL de solo anexado: para cada comando candidato, registra si fue considerado, si fue ejecutado y quién lo aprobó. Envía a S3 diariamente.
Suite de incidentes sintéticos. Construye 20 escenarios: cascada de OOMKill, DNS flap, oscilación de HPA, llenado de PVC, vecino ruidoso, sidecar defectuoso, mal despliegue de ConfigMap, rotación de certificados, retroceso de descarga de imagen (image-pull backoff), etc. Califica al agente en precisión de causa raíz y tiempo hasta la hipótesis.

Use It

webhook: alert.pagerduty.com -> checkout-api SLO breach, error rate 14%
[graph]   affected: Deployment checkout-api (3 Pods, Node ip-10-2-3-4)
[walk]    neighbors: ReplicaSet checkout-api-abc, Service checkout-api,
           recent rollout 14m ago
[sample]  prometheus error_rate 14%, up-trend; loki 500s on /api/v2/pay
[hypo]    #1 bad rollout: latest image checkout-api:v2.41 fails /healthz
           citations: deploy.yaml (rev 42), prometheus errorRate, loki 500 stack
[slack]   [ROLL BACK to v2.40]  [ESCALATE]  [IGNORE]
           (approval required; agent does not roll back unilaterally)

Ship It

outputs/skill-devops-agent.md es el entregable. Dado un cluster de K8s y una fuente de alertas, el agente produce hipótesis de causa raíz clasificadas y un flujo de remediación controlado por Slack.

Peso	Criterio	Cómo se mide
25	Precisión de RCA en suite de escenarios	≥80% de causa raíz correcta en 20 incidentes sintéticos
20	Seguridad	El protector de acción destructiva nunca se dispara sin aprobación en Slack en el log de auditoría
20	Tiempo hasta la hipótesis	p50 por debajo de 5 minutos desde la alerta hasta el resumen en Slack
20	Explicabilidad	Cada hipótesis tiene rutas de gráfico y citas de telemetría
15	Integración completa	PagerDuty, Slack, ArgoCD y Prometheus funcionando de extremo a extremo
100

Exercises

Ejecuta tu agente en los mismos tres incidentes en los que se demuestra el DevOps Agent de AWS. Publica la comparación lado a lado. Reporta dónde diverge el agente.
Agrega una auditoría de "casi incidente" (near-miss) que marque cualquier comando que el agente consideró que habría sido destructivo sin aprobación. Mide la tasa de casi incidentes durante una semana.
Cambia el modelo de hipótesis de Claude Sonnet 4.7 a un Llama 3.3 70B auto-hospedado. Mide la diferencia de precisión de RCA y el costo en dólares por incidente.
Construye un filtro causal: distingue los picos de telemetría correlacionados de una causa raíz real. Entrena un clasificador pequeño en las etiquetas de los 20 escenarios.
Agrega una simulación de rollback (dry-run): rollback de ArgoCD contra un clúster de staging con el mismo manifiesto. Verifica el plan de rollback en un clúster activo antes del botón de aprobación en Slack.

Key Terms

Término	Lo que la gente dice	Lo que realmente significa
Gráfico de conocimiento de K8s	"Gráfico del clúster"	Nodos = objetos de K8s + series de telemetría; aristas = propiedad, programación, observación
Solo lectura por defecto	"RBAC de alcance acotado"	La cuenta de servicio del agente solo tiene verbos get/list/describe; los verbos destructivos residen en un servidor separado detrás de aprobación
Log de auditoría	"Considerado vs ejecutado"	Registro de solo anexado de cada comando candidato, si se ejecutó y quién lo aprobó
Clasificación de hipótesis	"Puntuación de evidencia"	Recencia × especificidad × inverso de longitud de ruta del gráfico × recuento de citas
Tarjeta de aprobación de Slack	"Compuerta HITL"	Mensaje interactivo de Slack con botones de remediación; el agente no puede continuar hasta que un humano haga clic
Cita de telemetría	"Puntero de evidencia"	Una consulta de Prometheus, selector de Loki o URL de trace de Tempo que respalda una afirmación
MTTR	"Tiempo de resolución"	Tiempo transcurrido desde que se dispara la alerta hasta la recuperación del SLO