De la prueba de concepto a producción: cómo construir un agente de automatización de red que no falle
El escenario se repite con frecuencia en equipos de redes: un ingeniero motivado arma un laboratorio, construye un agente de automatización con Python y Ansible, ejecuta cambios en equipos de prueba, y el sistema funciona impecablemente. El equipo aprueba el PoC. Se decide llevar el agente a producción.
Tres semanas después, el agente está pausado. Causó un incidente menor al asumir un estado de la red que ya no era cierto. El equipo volvió a los cambios manuales “por seguridad”.
Este patrón no es un fracaso de la herramienta ni del ingeniero. Es el resultado de no haber diseñado el agente para las condiciones reales de producción desde el principio. La diferencia entre un PoC que funciona en un lab y un agente que opera en producción sin fallar no está en la lógica del script — está en cómo el sistema maneja la incertidumbre, los errores, y los estados inesperados.
Por qué el PoC funciona y producción no
Un laboratorio de automatización de redes tiene condiciones que raramente se dan en producción:
Estado conocido y controlado. En el lab, el ingeniero sabe exactamente el estado de cada equipo antes de ejecutar el agente. En producción, eso no siempre es cierto. Un equipo puede estar en medio de una actualización de firmware, tener una sesión SSH abierta por otro operador, o tener una configuración que fue modificada manualmente horas antes sin actualizar la fuente de verdad.
Topología estable. En el lab no hay incidentes activos, interfaces caídas por mantenimiento de terceros, o segmentos de red con latencia elevada que hacen que los timeouts de conexión fallen aleatoriamente.
Sin efectos secundarios. En el lab, si algo sale mal, se reinicia el equipo virtual y se empieza de nuevo. En producción, un comando ejecutado a medias puede dejar un equipo en un estado inconsistente que es difícil de diagnosticar.
Un solo operador. En el lab, solo el agente toca los equipos. En producción, hay ingenieros que hacen cambios manuales, scripts de monitoreo que abren sesiones, y sistemas de backup que compiten por el acceso.
El PoC no falla porque sea un mal diseño. Falla porque fue diseñado para las condiciones del lab, no para las condiciones de producción.
Los cuatro problemas que matan los agentes en producción
1. Ausencia de pre-validación del estado
El error más común: el agente asume que el estado de la red es el que debería ser según la fuente de verdad (NetBox, un archivo YAML, una base de datos), sin verificarlo antes de ejecutar.
El problema: La fuente de verdad tiene deriva. Un equipo que según NetBox tiene una sesión BGP activa puede tenerla caída por un mantenimiento no registrado. Si el agente hace cambios asumiendo que esa sesión está activa, puede causar un corte.
La solución: Toda operación del agente debe comenzar con una fase de pre-validación que lea el estado actual del equipo y lo compare contra el estado esperado. Si hay discrepancia, el agente debe detenerse y alertar — nunca continuar ciegamente.
def pre_validate(device, expected_state):
current_state = get_device_state(device)
discrepancies = compare_states(current_state, expected_state)
if discrepancies:
raise PreValidationError(
f"Estado inesperado en {device}: {discrepancies}. Operación abortada."
)
return True
2. Falta de idempotencia
Un agente idempotente puede ejecutarse múltiples veces y producir el mismo resultado. Un agente no idempotente puede causar problemas si se ejecuta dos veces —por un retry automático, un operador que lo lanza manualmente, o una falla a mitad de camino.
El problema: Si el agente agrega una entrada a una ACL y se ejecuta dos veces, agrega la misma entrada dos veces. Dependiendo del vendor, eso puede ser inofensivo o causar un comportamiento inesperado.
La solución: Antes de aplicar cualquier cambio, verificar si el estado deseado ya existe. Si ya existe, no aplicar el cambio. Este patrón —”verificar antes de cambiar”— es la base de la idempotencia en automatización de redes.
Herramientas como Ansible tienen idempotencia incorporada en sus módulos de red. Si escribís scripts Python con Netmiko, la idempotencia es tu responsabilidad explícita.
3. Ausencia de rollback automatizado
Todo cambio en producción debe tener un rollback ejecutable en segundos, no en minutos. En automatización, el rollback manual no escala: si el agente aplicó cambios en 50 equipos y algo salió mal, no podés hacer rollback manual en 50 equipos a tiempo.
El problema: Los agentes de PoC típicamente no implementan rollback. El ingeniero que lo construyó asumió que si algo fallaba, alguien lo revertiría manualmente.
La solución: Antes de aplicar cualquier cambio, capturar el estado actual de la configuración del equipo (o del fragmento que se va a modificar). Si la validación post-cambio falla, el agente debe revertir automáticamente a ese estado capturado.
def apply_with_rollback(device, change):
snapshot = capture_config_snapshot(device)
try:
apply_change(device, change)
if not post_validate(device, change.expected_state):
raise PostValidationError("Validación post-cambio fallida")
except Exception as e:
logger.error(f"Falla en {device}, iniciando rollback: {e}")
restore_snapshot(device, snapshot)
raise
4. Manejo deficiente de errores parciales
Un agente que aplica cambios en múltiples equipos secuencialmente o en paralelo puede fallar a mitad de camino. Si los primeros 20 equipos recibieron el cambio y los últimos 30 no, la red queda en un estado inconsistente.
El problema: El agente de PoC termina abruptamente cuando encuentra un error y deja el trabajo a medias. No hay notificación clara de cuántos equipos fueron modificados y cuántos no.
La solución: Definir explícitamente el comportamiento ante fallas parciales antes de escribir el agente:
- Fail fast: ante el primer error, detener todo y hacer rollback de los cambios ya aplicados. Apropiado para cambios interdependientes.
- Fail slow: continuar con los equipos restantes, registrar los errores, y reportar el resultado completo al final. Apropiado para cambios independientes entre equipos.
- Umbral de falla: continuar mientras el porcentaje de fallas esté por debajo de un umbral configurado (por ejemplo, abortar si más del 10% de los equipos falla).
El modelo de agente que sí funciona en producción
Un agente de automatización de red listo para producción tiene esta estructura:
1. INVENTARIO → Obtener lista de equipos desde la fuente de verdad
2. PRE-VALIDACIÓN → Verificar estado actual de cada equipo
3. SNAPSHOT → Capturar configuración actual antes de cambiar
4. EJECUCIÓN → Aplicar cambios con manejo de errores y límites de concurrencia
5. POST-VALIDACIÓN → Verificar que el estado post-cambio es el esperado
6. ROLLBACK → Revertir automáticamente si la validación falla
7. REPORTE → Registrar resultado detallado por equipo y notificar
Cada fase es explícita, testeable de forma independiente, y tiene un comportamiento definido ante fallas.
Llevar el agente a producción: el plan de despliegue
El rollout de un agente de automatización a producción debe ser gradual:
Semana 1 — Solo lectura. El agente corre contra equipos de producción pero solo en modo lectura. Pre-valida, genera snapshots, verifica el estado, y reporta — sin aplicar cambios. Esto valida que el agente puede conectarse a todos los equipos y que la pre-validación funciona correctamente contra el estado real de la red.
Semana 2-3 — Un segmento de bajo riesgo. El agente aplica cambios en un conjunto pequeño de equipos (5-10) de menor criticidad, con un ingeniero monitoreando la ejecución en tiempo real.
Semana 4 en adelante — Expansión gradual. Incrementar el alcance del agente en función de los resultados. Establecer métricas de éxito claras: tasa de fallas, tiempo de ejecución, cantidad de rollbacks activados.
De herramienta a infraestructura
Un agente de automatización que pasa a producción deja de ser una herramienta de un ingeniero y se convierte en infraestructura operativa. Eso implica que necesita:
- Versionado y revisión de código. Todos los cambios al agente pasan por pull request y revisión, igual que el código de software.
- Tests automatizados. Un suite de tests que valida que el agente funciona correctamente antes de cada despliegue.
- Monitoreo y alertas. El agente mismo es monitoreado: sus ejecuciones quedan registradas, sus fallas generan alertas, y su rendimiento se mide en el tiempo.
- Documentación operativa. El agente tiene un runbook que cualquier miembro del equipo puede seguir para operarlo, diagnosticar fallas, y ejecutar rollbacks manuales si es necesario.
La automatización de redes no falla porque la tecnología sea mala. Falla cuando se trata como un script de uso personal en lugar de como infraestructura de producción.
Cómo puede ayudar Ayuda.LA
En Ayuda.LA diseñamos e implementamos agentes de automatización de red para ISPs y empresas enterprise en Latinoamérica que funcionan en producción desde el primer día. No entregamos PoCs — entregamos sistemas operativos con validación, rollback, y monitoreo incorporados.
Si tenés un proyecto de automatización estancado porque el PoC no escala, o si querés construir automatización de red desde el principio con criterios de producción, hablemos.
Conversemos sobre tu proyecto →
La diferencia entre un PoC y un sistema de producción no es cuánto código tiene — es cuántas formas de fallar tiene en cuenta.