Automatización en entornos de alto riesgo: cuando el margen de error es casi cero
En 2009, Netflix publicó el primer paper sobre Chaos Engineering: la idea de inyectar fallas deliberadas en sistemas de producción para encontrar debilidades antes de que las fallas reales las encuentren. La práctica se volvió influyente en la industria del software y generó una ola de entusiasmo en equipos de operaciones de infraestructura.
Unos años después, un ingeniero de NOC en un ISP de Latinoamérica con 80.000 suscriptores leyó sobre Chaos Engineering y se entusiasmó. Quiso aplicar la filosofía a las operaciones de red. Propuso hacer ejercicios de “caída controlada” para probar los mecanismos de redundancia.
La propuesta fue rechazada. No por resistencia al cambio, sino porque el contexto era radicalmente diferente: en Netflix, una falla afecta la reproducción de videos. En un ISP, una falla puede interrumpir el servicio de hospitales, sistemas de alarma, y negocios que dependen de conectividad para facturar.
Este es el punto central: las filosofías de automatización y resiliencia que funcionan en entornos de bajo riesgo no se pueden trasladar directamente a redes ISP en producción. Necesitan ser adaptadas, y esa adaptación requiere cambios en cómo se piensa la automatización, no solo en qué herramientas se usan.
La asimetría del riesgo en redes ISP
En software, la reversibilidad es alta. Un deploy de código que sale mal generalmente puede revertirse en minutos. La blast radius de un error en un microservicio suele ser limitada a un porcentaje de usuarios, y con feature flags o circuit breakers, la contención es rápida.
En redes ISP, la asimetría es diferente:
Un cambio de configuración mal aplicado puede interrumpir el servicio a miles de usuarios en segundos, y el rollback puede tardar minutos que se sienten como horas.
Un error en una política de routing puede propagar rutas incorrectas a peers de tránsito antes de que el equipo lo detecte, generando incidentes que involucran a terceros fuera del control de la organización.
La infraestructura de red es, en muchos casos, infraestructura crítica real: hospitales, servicios de emergencia, empresas de logística, y sistemas de pago dependen de la conectividad que un ISP provee.
Esta asimetría no significa que no se deba automatizar. Significa que la filosofía con la que se diseñan los sistemas de automatización tiene que reflejar esa asimetría desde el principio.
Las filosofías que necesitan adaptación
“Move fast and break things”
Esta filosofía, popular en startups de software, es el opuesto exacto de lo que se necesita en redes ISP de producción. Pero la versión más sofisticada de la misma idea —”iterar rápido, fallar rápido, aprender rápido”— sí es aplicable, con un ajuste importante:
El “fallar rápido” en redes no puede ser en producción.
En software, el ciclo de feedback puede ser producción directamente. En redes ISP, el ciclo de feedback tiene que ser:
- Lab que replica producción → fallar aquí, aprender aquí
- Ventana de mantenimiento en horario de bajo impacto → validar en producción con riesgo controlado
- Rollout gradual con monitoreo activo → expandir solo si los primeros segmentos son exitosos
El ritmo de iteración en automatización de redes puede ser rápido — pero las iteraciones en producción tienen que ser de bajo impacto por diseño, no por suerte.
“Primero automatizá, luego validá”
En entornos de bajo riesgo, la lógica de automatizar primero y validar después tiene cierta racionalidad: lanzar algo imperfecto y corregir en base a feedback real.
En redes ISP, esa lógica invierte el orden correcto. La automatización de redes tiene que ser validada antes de llegar a producción, no en producción.
Esto implica un nivel de rigor en testing que no es habitual en proyectos de automatización de redes iniciales:
- Testing funcional en lab: el agente hace lo que tiene que hacer en condiciones normales
- Testing de condiciones límite: qué pasa cuando el equipo no responde, cuando la sesión SSH cae a mitad del cambio, cuando la validación post-cambio detecta un estado inesperado
- Testing de interoperabilidad: el agente funciona correctamente con todas las versiones de firmware y todos los modelos de equipos que están en producción
- Testing de rollback: el mecanismo de rollback efectivamente revierte el cambio en las condiciones en que se necesita
La tentación de saltear pasos del testing porque “el lab no refleja exactamente producción” es real. La respuesta correcta es mejorar el lab para que refleje mejor la producción, no saltear el testing.
“Confiá en el sistema, no en las personas”
Esta filosofía —propia de la cultura SRE y DevOps— implica reemplazar procesos que dependen de la intervención humana correcta por sistemas que garantizan resultados correctos independientemente del operador.
En redes ISP, esto es correcto en principio pero requiere una precaución: los sistemas de automatización en redes ISP necesitan override humano claro y siempre disponible.
Un agente de automatización de redes bien diseñado debe:
- Tener un mecanismo de pausa o cancelación que cualquier ingeniero pueda activar inmediatamente
- Requerir aprobación humana explícita para cambios de alto impacto (cambios de política de routing, modificaciones de configuración de equipos de core)
- Generar alertas que un operador humano ve antes de que el agente complete cambios críticos
La automatización reduce la dependencia de intervención humana para tareas rutinarias. No elimina el criterio humano para decisiones de alto impacto.
Los principios que sí funcionan en alto riesgo
Principio 1: Cambios pequeños, frecuentes y verificables
El mayor factor de riesgo en un cambio de red no es la complejidad de la operación en sí — es el tamaño del delta entre el estado anterior y el estado posterior. Un cambio que modifica 80 parámetros en 200 equipos simultáneamente es exponencialmente más difícil de diagnosticar si algo sale mal que un cambio que modifica 3 parámetros en 10 equipos.
La automatización de redes permite hacer cambios pequeños y frecuentes de manera eficiente. Aprovechar esa capacidad para reducir el tamaño de cada cambio individual es una estrategia de reducción de riesgo, no de aumento de trabajo.
Principio 2: Validación en múltiples puntos del cambio
Un cambio de red bien diseñado tiene validación en tres momentos:
Pre-cambio: el estado de la red antes del cambio es el esperado. Las condiciones para ejecutar el cambio están presentes. No hay incidentes activos que afecten los equipos involucrados.
Durante el cambio: el agente monitorea indicadores de impacto mientras aplica la configuración. Si los indicadores se deterioran por encima de un umbral, el agente detiene el rollout y espera confirmación.
Post-cambio: el estado de la red después del cambio es el esperado. Los servicios afectados siguen funcionando correctamente. No hay nuevos incidentes generados por el cambio.
Esta validación en tres puntos convierte el cambio de un acto de “aplicar y rezar” a un proceso verificable con criterios objetivos de éxito.
Principio 3: Blast radius limitado por diseño
Todo sistema de automatización de redes debe tener límites explícitos en cuántos equipos puede afectar en una sola ejecución, independientemente de lo que se le pida.
Estos límites no son configuraciones de usuario — son restricciones del sistema:
# Límites hardcodeados en el agente de automatización
max_devices_per_run: 50
max_concurrent_changes: 5
max_percentage_of_fleet: 10
require_approval_above: 20
Si un operador quiere aplicar un cambio a todos los 600 equipos, el sistema debe requerir que ese proceso se ejecute en múltiples ciclos con validación entre cada uno, no en una sola ejecución masiva.
Principio 4: Observabilidad antes que automatización
No se puede automatizar confiablemente lo que no se puede observar. Antes de automatizar cualquier proceso en una red ISP de alto riesgo, el equipo debe tener visibilidad clara sobre:
- El estado de las sesiones de routing (BGP, IS-IS, OSPF) en tiempo real
- Los indicadores de tráfico por enlace (utilización, drops, errores)
- Los logs de cambios de configuración de todos los equipos
- Los eventos de protocolo relevantes (BGP state changes, interface flaps, convergencia IGP)
Si un cambio automatizado afecta negativamente alguno de estos indicadores, el equipo necesita saber en segundos, no en minutos. La latencia de detección en redes ISP es el factor crítico: los incidentes que tardan 10 minutos en detectarse ya tienen impacto significativo en los usuarios.
El perfil de equipo que puede operar automatización de alto riesgo
La automatización no reduce la necesidad de ingenieros con criterio técnico profundo. La eleva.
Un sistema de automatización de redes de alto riesgo necesita ser diseñado, mantenido, y operado por ingenieros que entienden profundamente los protocolos de red que el sistema manipula. La automatización no oculta la complejidad de la red — la expone de una manera diferente.
El perfil correcto para este trabajo combina:
- Conocimiento de redes: entender qué hace realmente cada cambio de configuración y cuáles son sus implicaciones en el plano de control y datos
- Criterio de ingeniería de software: diseñar sistemas que manejan correctamente los errores, tienen tests, y son mantenibles
- Cultura de seguridad operativa: intolerancia a los atajos que reducen la confiabilidad por conveniencia
Este perfil no es común. Es la razón por la que la automatización de redes en ISPs de alto riesgo beneficia del trabajo con especialistas externos que tienen experiencia en este dominio específico.
Cómo puede ayudar Ayuda.LA
En Ayuda.LA diseñamos e implementamos automatización de redes para ISPs en Latinoamérica con criterios de alto riesgo incorporados desde el diseño. No creemos en la automatización a cualquier costo — creemos en automatización que reduce el riesgo operativo en lugar de aumentarlo.
Si estás evaluando un proyecto de automatización de red y querés asegurarte de que sea adecuado para tu entorno de producción, podemos hacer una revisión de diseño antes de que avances.
La automatización que falla en producción no es mejor que no tener automatización. Es peor: crea la ilusión de control sin la realidad de él.