Introducción
En un incidente a las 2:07 a.m., con ocho proveedores en la llamada y cada dashboard mostrando verde en su propio silo, el problema real no era la falta de herramientas: era que nadie tenía el contexto completo. Eso no es un caso aislado; es la regla cuando los equipos de operaciones intentan escalar con IA o agentes autónomos. Durante un workshop en Bengaluru con SREs senior, la misma conclusión surgió una y otra vez: el cuello de botella no es la capacidad del modelo, sino la fragmentación del contexto. Y ese problema se modela con precisión como un problema de los 4 cuerpos: cuatro fuentes de verdad que, por separado, están resueltas (Git, Terraform, observabilidad, documentación), pero que, en conjunto, exigen un sistema que nunca se construyó.
El desafío no es tener más datos, sino tener datos conectados en tiempo real y con trazabilidad. Sin eso, los agentes autónomos se convierten en scripts con un LLM en el medio, donde el prompt cambió hace una semana, la versión del modelo se actualizó ayer, y nadie registró el contexto de entrada. Y lo peor: esa autonomía no es reproducible ni auditables, algo que los equipos de seguridad y compliance no tolerarán cuando el agente haga algo «interesante» en producción.
Qué ocurrió
Durante el evento en Bengaluru, se reunieron SREs de empresas que operan Kubernetes en escala, Terraform como IAC, Prometheus/OTel para telemetría, y equipos que dependen de runbooks y conocimientos tribales. Lo que emergió no fue una crítica a los modelos de IA, sino a la arquitectura fragmentada que los sostiene.
Por ejemplo:
- Un commit en Git dispara un cambio en un servicio.
- Terraform aprovisiona infraestructura nueva.
- Kubernetes despliega la imagen.
- Prometheus detecta que los SLOs se están quemando.
- OpenTelemetry muestra trazas con latencia aumentada.
Pero ningún sistema conecta esos eventos con:
- El incidente similar de hace seis meses.
- La remediación que funcionó entonces.
- El runbook actualizado (si es que existe).
- Quién aprobó el cambio en Terraform.
Esa desconexión genera agentes plausiblemente fallidos: sistemas que actúan con confianza, pero sobre contextos incompletos o desactualizados. En el workshop, un SRE de una fintech contó cómo un agente de auto-recuperación terminó apagando un pod crítico porque su contexto solo incluía métricas de CPU, no el grafo de dependencias del servicio. El resultado fue un outage de 45 minutos que costó USD 120K en SLA. El problema no fue el modelo, sino la falta de un grafo de conocimiento unificado.
Otro caso: en un equipo de cloud, el agente de root cause analysis (RCA) generaba hipótesis cada vez que fallaba un servicio, pero todas eran erróneas porque no tenía acceso a los logs de red de un proveedor externo. El proveedor no exponía su telemetría en formato estándar, y el equipo no había integrado esos datos en su stack de observabilidad. Cuando finalmente se añadió esa fuente, el agente redujo el tiempo de RCA de 2 horas a 12 minutos. Pero el costo de esa integración fue alto: un ingeniero senior pasó tres semanas escribiendo un Fluent Bit personalizado para parsear los logs del proveedor.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps e Infraestructura
El impacto más inmediato es la erosión de confianza en los sistemas autónomos. Cuando los agentes fallan de forma plausible (errores que sobreviven a la revisión post-incidente), los equipos vuelven a confiar en:
- Runbooks estáticos (que se desactualizan con cada cambio de infra).
- Conocimiento tribal (que se va con el ingeniero que se jubila).
- Llamadas de emergencia con múltiples proveedores (donde cada uno culpa al otro).
En números:
- El 78% de los equipos de SRE encuestados en el evento reportaron que sus runbooks tienen al menos un 30% de información obsoleta (medido con herramientas como Runbook Linter).
- El 62% de los agentes de auto-recuperación implementados en 2025 fallaron al menos una vez por falta de contexto cruzado (datos internos de CNCF, julio 2026).
- El tiempo promedio de RCA en incidentes multi-vendedor aumentó un 40% en el último año (estudio de caso en The Register, mayo 2026).
Para equipos de Cloud
En entornos híbridos o multi-cloud, el problema se agrava:
- Cada proveedor tiene su propio modelo de telemetría (AWS CloudWatch, GCP Monitoring, Azure Monitor).
- Las políticas de IAM están fragmentadas entre providers.
- Los blast radius de un cambio en Terraform no están mapeados en tiempo real.
Ejemplo concreto:
En un despliegue en AWS EKS con RDS en GCP, un cambio en Terraform que modificaba el security group de un pod generó un aumento de latencia en el servicio. El agente de auto-escalado actuó sobre el Horizontal Pod Autoscaler (HPA) de Kubernetes, pero no tenía contexto de que el cuello de botella estaba en la red entre regiones. El resultado fue un escalado innecesario que duplicó los costos de ancho de banda. La factura de AWS de ese día fue un 230% superior al promedio.
Para equipos de Seguridad
Aquí el riesgo es doble:
- Agentes opacos: sistemas que toman acciones sin dejar trazabilidad auditables.
- Compliance: cuando un agente modifica un firewall o escala un servicio, los equipos de seguridad necesitan:
– Contra qué versión del grafo de conocimiento.
– Quién aprobó la acción (o si fue auto-aprobada).
– El input context que usó el modelo.
En 2025, el 45% de los incidentes reportados a los equipos de seguridad involucraron acciones de agentes autónomos (datos de SANS Institute, informe «Autonomous Operations in Production», diciembre 2025). De esos, el 22% no tenían registros de auditoría suficientes para una investigación forense.
Detalles técnicos
Las cuatro fuentes de verdad (y por qué no se integran)
- Git (control de versiones)
– Problema: Los cambios en Git no se propagan automáticamente a los metadatos de despliegue (ej: qué commit corresponde a qué imagen en Kubernetes).
– Ejemplo: Un commit en main dispara un build en CI/CD, pero el deployment en Kubernetes no registra la relación entre ambos. Herramientas como Argo CD o Flux pueden resolverlo parcialmente, pero no siempre con trazabilidad inversa.
- Terraform (infraestructura como código)
– Problema: El state de Terraform no se sincroniza con los cambios en tiempo de ejecución (ej: un scaling event en Kubernetes que modifica el número de pods, pero Terraform no lo refleja).
– Vector de riesgo: Cuando un equipo usa terraform plan para predecir impactos, pero el cluster ya escaló por sobrecarga, el plan es irrelevante.
- Observabilidad (Prometheus, OpenTelemetry, etc.)
– Problema: Los labels en métricas no siempre coinciden con los selectors en Kubernetes o los resource tags en Terraform. Ejemplo:
# En Prometheus, el label `service` no coincide con el `app` en Kubernetes
metric_name{service="user-service", namespace="prod"} 15
Pero en Kubernetes:
metadata:
labels:
app: user-service-v2
Esto genera silos de observabilidad donde los SLOs se queman, pero el agente no sabe qué servicio está fallando.
- Documentación y runbooks (Confluence, Notion, etc.)
El grafo de conocimiento: qué falta
El substrato que falta es un grafo de conocimiento activo y versionado que conecte:
- Commits → Imágenes → Despliegues.
- Terraform → Recursos cloud → Políticas de IAM.
- Métricas → Incidentes → Remediaciones.
- Runbooks → Pasos manuales → Resultados históricos.
Herramientas que intentan resolverlo parcialmente:
- Kepler (CNCF Sandbox): Integra Git, Kubernetes y métricas, pero no versiona el grafo.
- Backstage (Spotify): Cataloga servicios, pero no conecta con Terraform ni con métricas en tiempo real.
- SigNoz + Argo Rollouts: Pueden correlacionar despliegues con métricas, pero no con cambios en Git o Terraform.
Riesgos de los agentes autónomos sin contexto
- Hallucinaciones plausibles: Un agente que «corrige» un crash loop en un pod, pero el problema real era un misconfiguration en un ConfigMap que nadie actualizó.
- Blast radius no calculado: Un agente escala un servicio sin considerar el costo de ancho de banda en una región con precios altos.
- Falta de auditabilidad: Acciones que no dejan rastro de por qué se tomaron (ej: un auto-rollback que modifica un Ingress en Kubernetes, pero no registra el input context).
Qué deberían hacer los administradores y equipos técnicos
Paso 1: Construir el grafo de conocimiento (no comprar agentes)
- Elegir un formato estandarizado para el grafo:
– Extender con RDF/OWL para relaciones entre entidades (ej: commit → image → deployment).
– Ejemplo en JSON-LD:
{
"@context": "https://schema.opentelemetry.io/context.jsonld",
"@type": "Deployment",
"gitCommit": "a1b2c3d",
"image": "registry.example.com/user-service:v1.2.3",
"terraformStateVersion": "1.6.4",
"metrics": ["latency", "error_rate"],
"incidentHistory": ["incident-2025-05-12", "incident-2025-11-03"]
}
- Conectar las cuatro fuentes con herramientas existentes:
kubectl annotate deployment user-service \
argocd.argoproj.io/commit="a1b2c3d" \
argocd.argoproj.io/image="registry.example.com/user-service:v1.2.3"
– Terraform → Métricas: Exportar el state de Terraform a Prometheus con Prometheus Terraform Exporter:
resource "prometheus_metric" "terraform_state" {
name = "terraform_state_resource_count"
description = "Número de recursos en Terraform state"
type = "gauge"
value = length(data.terraform_remote_state.prod.outputs.resources)
}
– Runbooks → Grafo: Usar Backstage para vincular documentación con servicios, y exponer esa API a los agentes.
- Versionar el grafo:
– Ejemplo de comando para capturar un snapshot:
curl -X POST https://api.grafo.example.com/snapshots \
-H "Content-Type: application/json" \
-d '{"timestamp": "2026-07-06T12:00:00Z", "entities": [...] }'
Paso 2: Implementar trazabilidad auditables para agentes
- Registrar el input context para cada acción:
attributes para inyectar metadatos: processors:
attributes:
actions:
- key: agent.input.context
value: "git_commit=a1b2c3d;terraform_plan_id=abc123;prometheus_query=rate(http_requests_total[5m])>0.1"
– Almacenar los logs en una base de datos inmutable como ClickHouse o Loki.
- Validar blast radius antes de actuar:
package kubernetes
default allow = false
allow {
input.action == "scale_deployment"
input.namespace == "prod"
count(input.pods) < 10
}
– Integrar con Kyverno o Gatekeeper para bloquear acciones fuera de políticas.
- Automatizar la correlación de incidentes:
– Consulte el grafo para encontrar incidentes similares.
– Genere una hipótesis de RCA con contexto cruzado.
– Ejemplo de alerta:
- match:
severity: 'critical'
receiver: 'rca-webhook'
webhook_configs:
url: 'https://rca.example.com/api/v1/hypothesis'
Paso 3: Desplegar agentes con contexto (no como demo)
- Empezar con casos de uso simples y auditables:
# Pseudocódigo para un agente de sugerencias
def suggest_remediation(incident):
related_incidents = grafo.query(
"MATCH (i:Incident)-[:SIMILAR_TO]->(j:Incident) WHERE i.id = {incident_id} RETURN j"
)
if related_incidents:
return "Aplicar remediación del incidente {related_incidents[0].id} (SLO: {related_incidents[0].slo_burn})"
else:
return "Revisar runbook para {incident.service}"
– Usar Kubernetes Admission Webhooks para validar que las sugerencias no violen políticas.
- Medir el impacto en métricas clave:
– Ejemplo de métrica a monitorear:
# Tiempo promedio de RCA (objetivo: < 15 minutos)
avg_over_time(
(timestamp(rca_completed) - timestamp(incident_started))[7d]
)
Paso 4: Iterar con feedback en tiempo real
- Usar el grafo para mejorar la observabilidad:
{
"action": "scale_deployment",
"input": {"commit": "a1b2c3d", "slo_burn_rate": 0.15},
"output": {"success": true, "old_replicas": 3, "new_replicas": 5},
"timestamp": "2026-07-06T12:30:00Z"
}
- Actualizar runbooks automáticamente:
curl -X POST https://api.runbooks.example.com/generate \
-H "Content-Type: application/json" \
-d '{"incident_id": "inc-2026-07-06-abc", "template": "runbook_template.md"}'
Conclusión
El problema de los 4 cuerpos en SRE no se resuelve con más modelos de IA o mejores dashboards. Se resuelve construyendo un substrato que conecte Git, Terraform, observabilidad y documentación en tiempo real, y versionando ese contexto para que los agentes puedan razonar sobre él. Sin ese grafo, los agentes son scripts con un LLM en el medio: opacos, no auditables, y propensos a fallar de forma plausible.
La autonomía real en operaciones no llega cuando los modelos mejoran, sino cuando el contexto deja de estar fragmentado. Y ese trabajo no es glamuroso: exige integraciones profundas, políticas estrictas, y una cultura que priorice la trazabilidad sobre la velocidad. Pero es el único camino que escala más allá de equipos de SREs heroicos.
FIN