davidtoribioeu/Plan2026
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
Plan2026/11-decision-ia-agentes.md

15 KiB
Raw Blame History

Decision: IA y agentes para operaciones de infraestructura

Contexto

Gestionamos 100-500 servidores PVE/PBS con un equipo tecnico reducido. Ya tenemos decidido: Ansible + Semaphore (automatizacion), n8n (orquestacion futura), Netbox (inventario), Zammad (tickets), VictoriaMetrics + Loki (metricas/logs), Wazuh (seguridad), Grafana (dashboards). La pregunta es: como integramos IA para que nos ayude operativamente.

Dos dimensiones: uso interactivo (tecnico + IA) y agentes automatizados (IA trabaja sola o semi-sola).

8.1 Claude Code interactivo: copiloto para tecnicos

Que es

Claude Code es un CLI que se instala en una maquina Linux. El tecnico abre terminal, ejecuta claude, y trabaja de forma conversacional. Claude Code puede leer ficheros, ejecutar comandos, buscar en el codigo, y generar scripts/playbooks.

Donde se instala

En la VM Bastion (ya existe, SSH jump host). El tecnico hace SSH al bastion y desde ahi usa Claude Code con acceso a:

  • Repos Forgejo clonados (playbooks Ansible, scripts)
  • CLI de PBS via SSH a los nodos (proxmox-backup-manager)
  • CLI de ZFS via SSH
  • Logs locales y remotos
  • API de Netbox, PBS, PVE (curl)

Casos de uso reales

Escenario Que hace el tecnico Que hace Claude Code
GC lleva 3 dias "revisa el GC del cliente ACME" Lee logs, estado del job, uso de disco, diagnóstica
Cliente nuevo "genera playbook para cliente X, 200GB, sync desde pbs3343" Genera YAML validado siguiendo el patron existente
Alerta Wazuh "analiza esta alerta de file integrity" Lee evento, correlaciona con logs, valora si es falso positivo
Script heredado "que hace status_disk.sh y como mejorarlo" Lee, documenta, sugiere mejoras
Incidencia disco "el pool9 del pbs tiene IO alto" Revisa iostat, zpool status, encuentra el dataset problematico
Post-mortem "genera el timeline del incidente de ayer" Lee logs de Loki, Wazuh, metricas, construye cronologia

Implementacion

# En VM Bastion (Debian 12)
curl -fsSL https://claude.ai/install.sh | bash
# Configurar API key
export ANTHROPIC_API_KEY="sk-ant-..."

# Crear CLAUDE.md con contexto de la infra
cat > /root/CLAUDE.md << 'EOF'
# Infraestructura DoCloud
- Pool ZFS: pool9 (PBS), pool10 (PVE)
- Playbooks: /opt/ansible/
- Scripts legacy: /root/*.sh
- PBS API: https://localhost:8007
- Netbox API: https://netbox.internal/api/
- Clientes: ver `proxmox-backup-manager datastore list`
EOF

Recursos

  • CPU/RAM: despreciable (solo durante uso interactivo)
  • Coste: API key Anthropic, ~$20-50/mes segun uso del equipo
  • No requiere VM dedicada (va en Bastion existente)

Seguridad

  • El tecnico ya tiene acceso SSH al bastion con sus credenciales
  • Claude Code hereda los permisos del usuario que lo ejecuta
  • No abre puertos, no es un servicio, no tiene persistencia
  • Logs de sesion almacenables para auditoria

8.2 Agentes automatizados via n8n + API Claude

Arquitectura

Los agentes no son procesos permanentes. Son workflows de n8n que se disparan por un trigger (alerta, cron, webhook), enriquecen contexto consultando APIs, llaman a Claude API con un prompt especializado, y actuan sobre el resultado (crear ticket, generar informe, notificar).

Triggers                        Agentes (n8n workflows)           Acciones
┌──────────────┐               ┌─────────────────────┐          ┌──────────────┐
│ Alertmanager ├──────────────►│ Triaje de alertas   ├─────────►│ Ticket Zammad│
│              │               │ (prompt seguridad)  │          │              │
├──────────────┤               ├─────────────────────┤          ├──────────────┤
│ Cron semanal ├──────────────►│ Capacity planning   ├─────────►│ Informe      │
│              │               │ (prompt storage)    │          │ Outline      │
├──────────────┤               ├─────────────────────┤          ├──────────────┤
│ Wazuh alert  ├──────────────►│ Analisis seguridad  ├─────────►│ Ticket Zammad│
│ (nivel ≥10)  │               │ (prompt forense)    │          │ + Mattermost │
├──────────────┤               ├─────────────────────┤          ├──────────────┤
│ Zammad ticket├──────────────►│ Provisioning assist ├─────────►│ MR en Forgejo│
│ (alta-client)│               │ (prompt ansible)    │          │              │
└──────────────┘               └────────┬────────────┘          └──────────────┘
                                        │
                          Consultas read-only
                    ┌───────────┼───────────┐
                    │           │           │
              VictoriaMetrics  Loki      Netbox
              (metricas)      (logs)    (inventario)

Agente 1: Triaje de alertas (mayor ROI)

  • Trigger: Alertmanager envia webhook a n8n
  • Contexto que recopila:
    • Metricas del servidor afectado (VictoriaMetrics API, ultimas 2h)
    • Logs recientes del servidor (Loki API, ultimos 30 min)
    • Datos del servidor en Netbox (cliente, tipo, rol, SLA)
    • Historial de alertas similares (VictoriaMetrics alerts API)
  • Prompt especializado: incluye la definicion de severidades de la empresa, SLAs por cliente, y arboles de decision para problemas comunes (disco, CPU, backup fallido, conectividad)
  • Output: Ticket en Zammad con: severidad calculada, diagnostico, acciones recomendadas, metricas relevantes embebidas
  • Ejemplo real: Alerta "pbs_gc_duration_seconds > 86400 en ACME" → agente consulta tamaño datastore, snapshots, ultimo GC exitoso, y genera: "GC de ACME lleva 26h. Datastore: 1.2TB, 340 snapshots. Ultimo GC exitoso: hace 12 dias. Recomendacion: verificar si hay un sync job concurrente bloqueando. Si no, considerar maintenance-mode y GC forzado."

Agente 2: Capacity planning (semanal)

  • Trigger: Cron lunes 08:00
  • Contexto: Uso de disco de todos los datastores (VictoriaMetrics), quotas ZFS, tendencias 30/60/90 dias
  • Output: Informe en Outline con tabla priorizada:
| Cliente | Usado | Quota | Tendencia 30d | Dias hasta lleno | Accion |
|---------|-------|-------|---------------|------------------|--------|
| ACME    | 82%   | 600GB | +2.1%/semana  | ~45 dias         | Avisar |
| GAMMA   | 91%   | 300GB | +5.3%/semana  | ~12 dias         | URGENTE|
| BETA    | 34%   | 1TB   | estable       | >1 año           | OK     |

Agente 3: Analisis de seguridad (evento Wazuh)

  • Trigger: Wazuh alerta nivel ≥10 via webhook
  • Contexto: Evento Wazuh completo, logs Loki del servidor (misma ventana), eventos correlacionados (mismo servidor, ultima hora), baseline de comportamiento normal del servidor
  • Output: Ticket Zammad clasificado:
    • Falso positivo: justificacion detallada de por que es benigno
    • Incidente real: pasos de respuesta recomendados, basados en el playbook de incidentes (decision-incidentes.md)
    • Indeterminado: que verificaciones adicionales hacer manualmente

Agente 4: Asistente de provisioning

  • Trigger: Ticket Zammad con tag "alta-cliente" o webhook ICSManager
  • Contexto: Datos del cliente (nombre, GB, servidor sync), inventario Netbox (verificar duplicados), recursos disponibles en PVE destino
  • Output: Branch en Forgejo con YAML del cliente listo para revisar, o ticket actualizado con datos validados para lanzar playbook desde Semaphore

Implementacion en n8n

Cada agente es un workflow con estos nodos:

Webhook/Cron → HTTP Request(s) → Claude API → IF/Switch → Action(s)
  (trigger)    (recopilar         (analizar)   (decidir)   (actuar)
                contexto)

El nodo "Claude API" es un HTTP Request a https://api.anthropic.com/v1/messages con:

  • System prompt: instrucciones especializadas del agente + contexto de la infra
  • User message: datos recopilados en los pasos anteriores
  • Modelo: claude-sonnet-4-6 para agentes rutinarios (mas barato, suficiente), claude-opus-4-6 para analisis de seguridad (maximo razonamiento)

Coste estimado

Agente Frecuencia Tokens/ejecucion Modelo Coste/mes
Triaje alertas ~50-100/dia ~3000-5000 Sonnet $15-30
Capacity planning 1/semana ~10000 Sonnet $1-2
Seguridad Wazuh ~5-20/dia ~5000-8000 Opus $10-25
Provisioning ~5-10/mes ~3000 Sonnet $1-2
Total ~$30-60/mes

8.3 Evaluacion de OpenClaw

Que es OpenClaw

OpenClaw (antes Clawdbot/Moltbot) es un agente de IA open-source autonomo creado por Peter Steinberger. Se ejecuta localmente, conecta a LLMs (Claude, GPT, DeepSeek), y usa plataformas de mensajeria (WhatsApp, Telegram, Slack, Discord) como interfaz. Tiene 145k+ estrellas en GitHub y ~400k usuarios.

Caracteristicas principales:

  • Corre localmente, trae tu propia API key
  • Multi-canal: WhatsApp, Telegram, Slack, Signal, Teams, Matrix
  • 100+ AgentSkills precofiguradas (ejecutar shell, gestionar ficheros, web automation)
  • Memoria persistente entre conversaciones
  • Open source (MIT)

Ventajas potenciales para nuestro caso

Ventaja Detalle
Multi-canal Los tecnicos podrian interactuar via Telegram/Mattermost sin SSH
Open source Sin vendor lock-in, personalizable
Skills extensibles Podriamos crear skills para PBS, ZFS, Netbox
Self-hosted Control total de datos

Problemas criticos para nuestro caso

1. Seguridad: INACEPTABLE para infraestructura de produccion

Este es el punto definitivo. OpenClaw tiene vulnerabilidades documentadas graves:

  • Prompt injection via skills: Cisco demostro que skills de terceros pueden hacer data exfiltration sin que el usuario lo note
  • ClawJacked (marzo 2026): Vulnerabilidad que permite a atacantes controlar el agente via WebSocket local y acceder a datos del dispositivo
  • Superficie de ataque amplia: Un agente con acceso a shell en un servidor que gestiona 100-500 servidores de clientes es exactamente el vector de ataque que acabamos de sufrir con el backdoor PAM

Nosotros acabamos de recuperarnos de un credential stealer que tenia acceso shell. Poner un agente de IA con acceso shell y vulnerabilidades conocidas de prompt injection seria repetir el mismo error.

2. Modelo de ejecucion inadecuado

OpenClaw es un agente personal (asistente general) ejecutandose como demonio. Nuestras necesidades son agentes especializados con scope limitado que se ejecutan solo cuando hay un trigger. Diferencia fundamental:

Aspecto OpenClaw Nuestro modelo (n8n + API)
Ejecucion Demonio permanente Bajo demanda (trigger)
Permisos Acceso amplio al sistema Read-only a APIs especificas
Scope General ("haz lo que te pida") Especializado ("triaje de alertas")
Auditoria Logs propios Logs de n8n + Loki
Superficie de ataque WebSocket + shell + mensajeria Solo API HTTP saliente
Acciones Ejecuta directamente Genera recomendaciones, humano aprueba

3. Complejidad innecesaria

  • OpenClaw requiere su propia infraestructura (MongoDB para memoria, gateway, canales)
  • Nosotros ya tenemos n8n (orquestacion) + Zammad (interfaz humana) + Mattermost (chat futuro)
  • Añadir OpenClaw duplica funcionalidad sin añadir valor

4. Gobernanza incierta

  • El creador (Peter Steinberger) se unio a OpenAI en febrero 2026
  • Proyecto con hype extremo pero inmaduro en seguridad
  • China ha restringido su uso en agencias gubernamentales por riesgos de seguridad

Veredicto: NO usar OpenClaw

OpenClaw no encaja en nuestro caso por razones de seguridad y arquitectura. No necesitamos un agente general con acceso al sistema. Necesitamos agentes especializados, scoped, auditables, sin acceso directo a shell.

Nuestro stack ya cubre todo lo que OpenClaw ofrece de forma mas segura:

  • Chat con IA: Claude Code interactivo en Bastion (controlado, sin demonio)
  • Automatizacion con IA: n8n + Claude API (scoped, read-only, auditable)
  • Mensajeria del equipo: Mattermost/Zammad (ya decidido)
  • Ejecucion de tareas: Ansible + Semaphore (aprobacion humana)

Si en el futuro OpenClaw madura en seguridad y necesitamos un asistente conversacional para tecnicos via chat, se puede reevaluar. Pero hoy, con nuestro historial de seguridad, la respuesta es clara: no.

8.4 Orden de implementacion

Fase Que Cuando Dependencias
Fase 0 Claude Code en Bastion Dia 1, tras desplegar Bastion Solo API key Anthropic
Fase 1 Agente triaje de alertas Mes 1-2 n8n desplegado, Alertmanager configurado
Fase 2 Agente capacity planning Mes 2-3 VictoriaMetrics con historico ≥30 dias
Fase 3 Agente analisis seguridad Mes 3-4 Wazuh maduro, baseline establecida
Fase 4 Agente provisioning Mes 4+ Playbooks Ansible estables, Netbox poblado

Principios de diseño de los agentes

  1. Read-only por defecto: Los agentes consultan APIs pero nunca ejecutan comandos en produccion
  2. Humano en el bucle: Las acciones de escritura (tickets, MRs) son para que un humano revise y apruebe
  3. Scope minimo: Cada agente tiene un prompt especializado y solo accede a las APIs que necesita
  4. Auditabilidad: Todo queda en n8n (historial de ejecuciones) + Loki (logs)
  5. Coste controlado: Sonnet para tareas rutinarias, Opus solo para analisis complejos

Resumen

Capa 8: IA y agentes para operaciones

  • 8.1: Claude Code interactivo en VM Bastion (copiloto para tecnicos, dia 1)
  • 8.2: Agentes automatizados via n8n + Claude API (4 agentes especializados, despliegue progresivo meses 1-4)
  • 8.3: OpenClaw evaluado y descartado (riesgos de seguridad inaceptables, arquitectura inadecuada, funcionalidad cubierta por stack existente)
  • 8.4: Orden de implementacion en 4 fases

Recursos adicionales: ninguno (Claude Code en Bastion existente, agentes en n8n ya planificado) Coste operativo: ~$30-60/mes en API Anthropic Herramientas nuevas: ninguna (todo sobre stack ya decidido)