Agentic SRE — CultureTech Playbook

El contexto

“AIOps con LLMs” es una promesa popular. La realidad: la mayoría de los demos impresionantes son agentes que correlacionan logs y producen una respuesta plausible — sin garantías de corrección, sin rollback, sin auditoría.

Para SRE eso no sirve. SRE opera infraestructura crítica. Un agente que “vibe-checks” una corrupción de Kafka y reinicia el cluster sin confirmación humana es un incident en sí mismo.

Este playbook describe cómo aplicar agentes a SRE manteniendo el rigor operacional que la disciplina exige.

3 reglas fundamentales

Regla 1: el estado del agente es legible

Cada agente debe tener una máquina de estados finitos explícita. No basta con “el LLM razona”. Estados como:

• idle — esperando señal.
• triaging — clasificando una alerta.
• executing-runbook — ejecutando paso de runbook X.
• escalating-human — el caso excedió la confianza del agente.

El humano que opera debe poder responder “¿qué está haciendo el agente ahora?” mirando el estado, no infiriendo del último log.

Regla 2: los runbooks son contratos, no sugerencias

El agente debe ejecutar runbooks declarados, no inventar pasos. Cada runbook es un grafo de pasos con:

• Pre-condición verificable.
• Acción concreta.
• Post-condición verificable.
• Mecanismo de rollback.

El LLM elige qué runbook ejecutar, no qué pasos individuales tomar. Esto es similar a cómo un humano SRE consulta su wiki — la diferencia es disciplina, no creatividad.

Regla 3: el agente es observable como cualquier otro sistema

Cada acción del agente queda registrada con:

• Trigger que la inició.
• Razonamiento del LLM (prompt + output).
• Runbook elegido + estado de ejecución.
• Resultado (éxito, fallo, escalación).

Esto va al mismo pipeline de observabilidad que el resto de la infra. Cuando el agente falla, falla con contexto.

Anti-patrones

Anti-patrón 1: dejar al agente decidir runbooks dinámicamente

Sucede cuando el LLM no solo elige runbook sino que escribe los pasos en el momento. Imposible de auditar, imposible de testear.

Fix: runbooks son artefactos versionados en repo. El agente elige entre runbooks existentes.

Anti-patrón 2: confianza ilimitada

Cuando el agente puede ejecutar acciones destructivas (reiniciar clusters, eliminar pods, etc.) sin confirmación humana en ningún caso.

Fix: definir un threshold de confianza. Bajo X% confianza, el agente escala a humano antes de actuar. Y para acciones destructivas específicas (definidas en lista), siempre escala, sin importar confianza.

Anti-patrón 3: un solo agente monolítico

Cuando hay un solo “SRE Agent” que cubre Kafka, Kubernetes, PostgreSQL, y todo lo demás. La complejidad explota, la auditoría se hace imposible.

Fix: un agente por dominio (Themis sigue este patrón). El dominio de Kafka tiene su propio agente con su propia FSM y sus propios runbooks. El de Kubernetes otro.

Caso de uso típico

Agente recibe alerta kafka-consumer-lag > 1h en topic crítico.

1. Estado: triaging.
2. Razonamiento: “Lag alto en topic X. Runbooks candidatos: restart-consumer-group, scale-consumer, check-broker-health.”
3. Acción: consultar métricas para escoger entre los tres. Detecta que broker tiene CPU 95%.
4. Estado: executing-runbook: check-broker-health.
5. Acción del runbook: check de procesos, GC pause, network.
6. Resultado: GC pause de 2.5s detectado.
7. Estado: escalating-human. Razón: la acción correctiva (ajustar XX:MaxGCPauseMillis) requiere restart del broker. No es destructiva por sí sola, pero la lista explícita la marca como “requiere confirmación humana”.
8. Humano oncall recibe Slack con: alerta original + razonamiento completo + runbook propuesto. Aprueba o ajusta.

Total tiempo desde alerta a propuesta: 90 segundos. Sin agente, mismo diagnóstico tarda 15-30 minutos de un SRE.

Cuándo NO usar agentic SRE

• Equipo de SRE chico (<5 personas). El overhead de mantener runbooks + observabilidad del agente excede el ahorro.
• Infraestructura simple (un monolito + DB). No hay suficiente densidad de alertas para justificar.
• Sin cultura de runbooks pre-existente. Agentic SRE amplifica buena disciplina, no la crea.

¿Te interesa explorar?

Si tienes equipo SRE y quieres conversar el caso de uso específico: Technical Deep Dive de 60 min, gratis.