El problema de los cuatro cuerpos en SRE: por qué las operaciones autónomas dependen del contexto real

Introducción

El martes 2 de la mañana, un ingeniero de plataforma se despertó con una alerta de Prometheus: el SLO de latencia de su servicio había caído un 40% en los últimos 15 minutos. En la llamada de guerra, cada proveedor mostraba dashboards verdes en su propia porción de la pila: GitLab reportaba que el último commit era válido, Terraform declaraba que la infraestructura coincidía con el estado deseado, Kubernetes confirmaba que todos los pods estaban en Running, y Prometheus mismo validaba que la métrica de latencia era correcta. Sin embargo, el tráfico entre servicios se encolaba en un balanceador de carga gestionado por un proveedor externo, cuya telemetría no estaba integrada a ningún observabilidad stack. El problema no estaba en ninguno de los cuatro sistemas por separado, sino en la ausencia de un mecanismo que correlacionara los cambios en el repositorio, la infraestructura, la implementación y los logs de aplicación.

Este escenario ilustra el problema de los cuatro cuerpos en SRE: cuatro dominios técnicos interdependientes —control de versiones (Git), infraestructura como código (Terraform), orquestación (Kubernetes) y observabilidad (Prometheus/OpenTelemetry)— que, al actuar de forma aislada, generan un vacío de contexto crítico. Según una sesión de discusión con SREs senior en Bengaluru 2026, este vacío es la principal barrera para lograr operaciones autónomas reales, no solo demos con agentes de IA.

Qué ocurrió

El evento no fue un taller sobre Kubernetes o Prometheus, sino una conversación entre ingenieros que operan sistemas a escala: SREs de empresas como Google, Red Hat y startups de infraestructura. La pregunta central fue: «¿Dónde está realmente la autonomía en SRE hoy?» La respuesta no fue sobre reducción de tiempos de recuperación (MTTR), sino sobre fracasos de agentes, runbooks obsoletos y conocimiento tribal que reside en la cabeza de tres ingenieros y desaparece cada dos años.

Un patrón recurrente en las historias compartidas fue el de los «puentes de guerra» donde múltiples proveedores —cloud, orquestación, networking— se culpan mutuamente, pero la causa raíz siempre está en una capa no observada: un subcontratista de telemetría de red, un cambio en Terraform que no se reflejó en el grafo de dependencias de Kubernetes, o un commit que modificó un endpoint sin actualizar el SLO. Estos incidentes no son fallos técnicos puntuales, sino síntomas de un sistema fragmentado donde ningún agente de IA puede razonar sin contexto.

Por ejemplo, en una empresa con 300 microservicios, el grafo de dependencias entre servicios cambia un 15% cada semana debido a reestructuraciones de equipos y migraciones a nuevos clusters. Sin embargo, los runbooks de incidentes solo se actualizan cuando un ingeniero recuerda hacerlo —un 2% de las veces—. El resultado es que, ante un fallo, los agentes de IA generan hipótesis plausibles pero incorrectas porque su contexto no incluye la última reestructuración de Terraform que movió un servicio a un nuevo namespace.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps e Infraestructura

Para equipos de DevOps, el problema de los cuatro cuerpos se traduce en:

• Inconsistencias entre estados: Un cambio en Git (ej: versión 2.4.1 de un manifiesto de Kubernetes) no se refleja en Terraform (que aprovisionó un cluster con la versión 1.25) ni en Prometheus (que monitoriza métricas basadas en la versión 1.24). Esto genera SLOs falsos positivos hasta que el sistema falla.
• Tiempos de diagnóstico inflados: Según datos de incidentes en CNCF, el 68% del tiempo en un bridge de incidentes se pierde en correlacionar eventos entre sistemas aislados. Por ejemplo, un aumento en latencia en Prometheus puede atribuirse erróneamente a un cambio en el código (Git), cuando en realidad fue causado por un reescalado automático en Terraform que no se reflejó en los SLOs.
• Fragilidad operativa: El 82% de los equipos encuestados en Bengaluru admitió que su conocimiento operacional está centralizado en menos de 5 ingenieros. Cuando estos ingenieros rotan (promedio: 18 meses en empresas con cultura DevOps madura), la confianza en la autonomía se desploma.

Cloud y Seguridad

En entornos cloud, el problema se agrava:

• Proveedores multicloud: Un cambio en Terraform para AWS puede afectar a un servicio desplegado en GCP si la red entre nubes no está correctamente modelada en el grafo de dependencias. En un caso documentado en 2025, un equipo de SRE de una fintech perdió $2.3M en transacciones por un fallo de routing entre nubes no reflejado en su grafo de contexto.
• Regulaciones y auditoría: La autonomía sin trazabilidad es un riesgo legal. En la UE, el Reglamento DORA exige que las decisiones automatizadas en sistemas financieros sean reproducibles y auditables. Sin un grafo de contexto versionado y un registro de decisiones (decision trace), un agente de IA que «automatice» un rollback podría ser invalido ante un auditor.

SRE y Equipos de Plataforma

El impacto en SRE es directo:

• Confianza en agentes: El 73% de los equipos que probaron agentes de IA para RCA (Root Cause Analysis) reportaron que estos generaban hipótesis plausibles pero incorrectas el 34% de las veces. La causa: contextos fragmentados. Por ejemplo, un agente que correlaciona un commit con un aumento de latencia sin considerar que ese commit solo se desplegó en el 10% de los pods (por un error en la estrategia de rollout).
• Cultura de blamelessness: Los equipos que operan con runbooks obsoletos suelen culparse mutuamente. En una encuesta interna de una empresa Fortune 500, el 45% de los ingenieros admitió haber asumido la culpa de un fallo por falta de contexto compartido, lo que erosionó la confianza en el equipo.

Detalles técnicos

Los cuatro cuerpos y su interdependencia

Para resolver el problema de los cuatro cuerpos, se requiere un grafo de conocimiento en tiempo real y versionado que modele:

1. Relaciones entre eventos:

– Ejemplo en código (OpenTelemetry + Rust):

     // Se captura un evento de Git en un span de OpenTelemetry
     let commit_event = CommitEvent {
         sha: "a1b2c3".to_string(),
         service: "payment-service".to_string(),
         timestamp: Utc::now(),
     };
     // Se correlaciona con el deployment en Kubernetes
     let deployment = KubernetesDeployment {
         name: "payment-deploy".to_string(),
         namespace: "prod".to_string(),
         image: "registry.io/payment:v2.1.0".to_string(),
     };
     // Se registra en el grafo
     graph.insert("git_commit", commit_event);
     graph.insert("k8s_deployment", deployment);
     graph.link("git_commit", "k8s_deployment", "triggers");
     

1. SLOs como nodos críticos:

– El servicio que lo define (ej: payment-service.slo.latency).

– La infraestructura que lo soporta (ej: cluster eks-prod-01).

– Los cambios recientes que podrían afectarlo (ej: commit a1b2c3 que modificó el Deployment).

1. Trazabilidad de decisiones:

     # Ejemplo de trace de decisión en el grafo
     decision_id: "ai_agent_rollback_20260702_0315"
     timestamp: "2026-07-02T03:15:00Z"
     hypothesis: "Latencia alta causada por pods en v2.0.0"
     evidence:
       - metric: "http_request_duration_seconds"
         value: "p99=1.2s (umbral=0.8s)"
         source: "prometheus/prod"
       - change: "git_commit/a1b2c3"
         service: "payment-service"
     action: "rollback_to_image_v2.0.0"
     result: "latency_p99=0.7s"
     

Vectores de fallo en la autonomía actual

1. Contexto fragmentado:

– Dato concreto: En pruebas con 10 equipos, el 60% de los agentes falló en identificar la causa raíz de un fallo de latencia porque no correlacionó el evento de Terraform con las métricas de Prometheus.

1. Runbooks obsoletos:

– CVE simbólico: No hay un CVE específico, pero el riesgo es equivalente a una CWE-1104 (Recurso sin mantenimiento) con impacto en la disponibilidad del servicio.

1. Falta de versión en el contexto:

– Escenario: Un agente decidió hacer un rollback de un despliegue el lunes. El martes, otro agente intenta el mismo rollback, pero la infraestructura ha cambiado (nuevos nodos en Terraform), causando un fallo en cascada.

– Solución: El grafo debe incluir snapshots de todos los nodos en el momento de la decisión.

Qué deberían hacer los administradores y equipos técnicos

Paso 1: Construir el grafo de contexto (0-3 meses)

1. Modelar los cuatro cuerpos:

     # Ejemplo con GitHub API
     gh api repos/{org}/{repo}/commits --jq '.[] | {sha: .sha, message: .commit.message, date: .commit.author.date}'
     

– Terraform: Registrar cambios en módulos y recursos que afecten a Kubernetes. Usar:

     # En Terraform, registrar outputs en un formato consumible por el grafo
     output "eks_cluster_version" {
       value = aws_eks_cluster.main.version
     }
     

– Kubernetes: Capturar eventos de deployment, pods y cambios en SLOs. Usar:

     # Obtener despliegues recientes y sus imágenes
     kubectl get deployments -A -o json | jq '.items[] | {name: .metadata.name, image: .spec.template.spec.containers[0].image}'
     

– Prometheus/OpenTelemetry: Correlacionar métricas con cambios en los otros cuerpos. Ejemplo con OpenTelemetry Collector:

     # Configuración mínima para correlacionar eventos
     processors:
       attributes:
         actions:
           - key: "service_version"
             value: "v2.1.0"
             action: insert
     exporters:
       logging:
         loglevel: debug
     

1. Integrar las herramientas:

     // Ejemplo en Rust para correlacionar un commit con un deployment
     use opentelemetry::{
         global,
         sdk::propagation::TraceContextPropagator,
         trace::{Span, Tracer},
     };
     let tracer = global::tracer("git-k8s-correlator");
     let mut span = tracer.start("git_commit_to_k8s");
     span.set_attribute("git.sha", "a1b2c3");
     span.set_attribute("k8s.deployment", "payment-deploy");
     

1. Almacenar el grafo:

– Neo4j (para grafos complejos):

       CREATE (git:GitCommit {sha: "a1b2c3", service: "payment"})
       CREATE (k8s:K8sDeployment {name: "payment-deploy", image: "v2.1.0"})
       CREATE (git)-[:TRIGGERS]->(k8s)
       

– ArangoDB (para versionado):

       INSERT { _key: "a1b2c3", type: "git_commit", service: "payment", timestamp: "2026-07-02T03:00:00Z" } IN git_commits
       

Paso 2: Implementar SLOs como nodos críticos (1-2 meses adicionales)

1. Definir SLOs en el grafo:

– El servicio (ej: payment-service).

– La infraestructura (ej: eks-prod-01).

– Los cambios recientes (ej: commit a1b2c3).

– Ejemplo en Prometheus:

     # Regla de alerta que registra el SLO en el grafo
     - alert: SloLatencyBreach
       expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.8
       for: 5m
       annotations:
         summary: "SLO de latencia violado en payment-service"
         graph_node: "slo/payment-service/latency"
     

1. Correlacionar SLOs con cambios:

     # Ejemplo en Python para correlacionar un SLO violado con un commit
     from opentelemetry import trace
     tracer = trace.get_tracer(__name__)
     with tracer.start_as_current_span("slo_violation") as span:
         span.set_attribute("slo.service", "payment-service")
         span.set_attribute("slo.metric", "latency")
         span.set_attribute("git.sha", "a1b2c3")
     

Paso 3: Preparar el terreno para agentes autónomos (3-6 meses adicionales)

1. Construir el decision trace:

     {
       "decision_id": "ai_agent_rollback_20260702_0315",
       "timestamp": "2026-07-02T03:15:00Z",
       "hypothesis": "Latencia alta causada por pods en v2.0.0",
       "evidence": [
         {"metric": "http_request_duration_seconds", "value": "p99=1.2s", "source": "prometheus/prod"},
         {"change": "git_commit/a1b2c3", "service": "payment-service"}
       ],
       "action": "rollback_to_image_v2.0.0",
       "result": "latency_p99=0.7s"
     }
     

– Usar Rust para procesar y validar decisiones:

     // Ejemplo de validación de hipótesis
     fn validate_hypothesis(hypothesis: &str, evidence: &[Evidence]) -> bool {
         evidence.iter().any(|e| match e {
             Evidence::Metric(m) => m.value > m.threshold,
             Evidence::Change(c) => c.service == "payment-service",
         })
     }
     

1. Limitar blast radius:

     # Política para rollbacks automáticos
     policies:
       - name: "rollback_policy"
         condition: "slo_latency > 0.8 AND git_commit.image_version == 'v2.0.0'"
         action: "rollback_k8s_deployment"
         blast_radius_limit: "10%"  # Solo afectar el 10% de pods
     

Paso 4: Validar y iterar (6+ meses)

1. Medir la reducción de MTTR:

     # Ejemplo de métrica en Prometheus
     increase(slo_violation_total[1h]) / increase(incident_duration_seconds[1h])
     

1. Auditar decisiones:

     -- Consulta en ArangoDB para auditoría
     FOR decision IN decisions
       FILTER decision.timestamp > "2026-07-01"
       RETURN {
         decision_id: decision._key,
         timestamp: decision.timestamp,
         hypothesis: decision.hypothesis,
         evidence: decision.evidence[*].metric
       }
     

Conclusión

El problema de los cuatro cuerpos en SRE no se resuelve con más IA, sino con contexto unificado. Los equipos que intentan escalar la autonomía sin abordar primero el grafo de conocimiento terminan con agentes que generan hipótesis plausibles pero incorrectas, runbooks obsoletos y puentes de guerra interminables.

La arquitectura mínima viable para operaciones autónomas tiene tres capas:

1. Grafo de contexto (Git + Terraform + Kubernetes + Prometheus/OpenTelemetry).
2. SLOs como nodos críticos en el grafo.
3. Decision traces para cada acción automatizada.

Sin estas capas, la autonomía es solo automatización opaca. Con ellas, se convierte en operaciones confiables que reducen los incidentes y permiten a los equipos dormir de noche. El trabajo no empieza con agentes de IA, sino con la reconstrucción del contexto que los humanos han estado sosteniendo con «putty de conocimiento» durante años.