Parte 2: Bloques Arquitectónicos on Designing Network Automation at Scale

04 - Fuente de Verdad

Sun, 15 Feb 2026 00:00:00 +0000

4. La Fuente de Verdad#

Un nuevo servicio tenía que estar en producción antes de fin de semana. El cambio era sencillo: una nueva VLAN, una nueva subred, reglas de firewall actualizadas y una nueva comunidad BGP en los routers de borde. El ingeniero de red sabía exactamente qué hacer. Lo que siguió fueron cuatro días de coordinación entre cinco sistemas: la herramienta de IPAM para reservar la subred, el CMDB para registrar el servicio, la plataforma de gestión del firewall para aplicar la nueva política, el sistema de configuración de routers para la comunidad BGP y la plataforma de monitorización para añadir los nuevos umbrales. Cada sistema tenía su propia interfaz, su propio modelo de datos y su propio flujo de aprobación. Y como no había una referencia compartida, el ingeniero tuvo que llevar el contexto manualmente: copiando valores de un sistema al siguiente, esperando que nada cambiara entre pasos.

05 - Ejecución

Sat, 01 Nov 2025 00:00:00 +0000

5. Ejecución#

El playbook había funcionado perfectamente durante meses: diez switches de acceso en el laboratorio, dos minutos de principio a fin, resultados limpios cada vez. Cuando el equipo decidió desplegarlo en el inventario completo de 800 switches, nadie esperaba problemas. Los primeros 600 dispositivos se actualizaron sin incidentes. Luego el trabajo se ralentizó. Luego se bloqueó. El servidor RADIUS, que recibía de repente 150 solicitudes de autenticación SSH simultáneas, empezó a rechazar conexiones. Ansible quedó bloqueado en 150 dispositivos a mitad de la ejecución. Un ingeniero mató el trabajo.

06 - Observabilidad

Mon, 12 Jan 2026 00:00:00 +0000

6. Observabilidad#

El módulo de ventilación de un router troncal de un proveedor de servicios falló silenciosamente durante la noche. No hubo alertas. El subsistema de gestión térmica de las tarjetas de línea detectó el aumento de temperatura y comenzó a reducir la velocidad de los ASICs de reenvío para proteger el hardware. El rendimiento en un enlace de tránsito en producción cayó un 40 %. El sistema de monitorización no vio nada: los sensores térmicos que sondeaba estaban en el supervisor del chasis, no en las tarjetas de línea individuales. Los sondeos SNMP se ejecutaban cada cinco minutos e informaban del dispositivo como sano. Los contadores de interfaz mostraban un menor rendimiento, pero no había ningún umbral configurado para ese patrón porque el enlace siempre había estado muy por debajo de su capacidad.

07 - Orquestación

Fri, 20 Mar 2026 00:00:00 +0000

7. Orquestación#

El equipo de red había hecho todo bien. Tenían una Fuente de Verdad sólida, playbooks bien probados para cada operación y un runbook claro para ejecutarlos. Sobre el papel, desplegar un nuevo servicio de VLAN estaba completamente automatizado. En la práctica, llevaba medio día y requería a una ingeniera en concreto.

Esa ingeniera conocía la secuencia. Primero, validar que los datos del SoT estuvieran completos. Luego ejecutar el playbook de pre-verificación. Luego revisar la salida, buscar dispositivos fallidos y decidir si continuar. Luego lanzar el playbook de despliegue. Luego esperar. Luego ejecutar el playbook de validación. Luego actualizar manualmente el ticket de ServiceNow. Si algún dispositivo fallaba a mitad del proceso, revertirlo antes de que los demás se vieran afectados. Lo tenía todo en un runbook, paso a paso, en un documento compartido que nadie más había interiorizado del todo.

08 - Presentación

Sat, 28 Mar 2026 00:00:00 +0000

8. La Capa de Presentación#

La automatización de VLANs llevaba seis semanas en marcha. El equipo de red estaba orgulloso de ella. Cada mañana llegaban tres o cuatro nuevas solicitudes de servicio de los equipos de aplicaciones, y el Orquestador las gestionaba sin que nadie del equipo de red tocase un teclado. Los despliegues funcionaban. Los switches estaban configurados. La red estaba sana.

La escalada llegó un jueves. El responsable del equipo de aplicaciones preguntaba por qué las solicitudes de VLAN tardaban entre tres y cinco días laborables cuando el portal mostraba “enviada”. El equipo de red revisó su cola: cero solicitudes pendientes, todos los despliegues exitosos. La automatización había procesado cada solicitud en menos de veinte minutos desde su recepción. Pero los tickets de ServiceNow seguían mostrando “En progreso”, porque nadie había escrito la integración que los actualizaría.

09 - La Red

Sun, 29 Mar 2026 00:00:00 +0000

9. La Red#

La automatización de VLANs llevaba tres semanas funcionando en el laboratorio. Tres switches, uno de cada proveedor, todos los flujos de trabajo pasando. El equipo se sentía seguro. En el primer despliegue en producción, 23 de los 800 switches de campus fallaron. Todos HPE. Todos con una versión de firmware que nadie había documentado.

El playbook comprobaba la respuesta de error de cada dispositivo tras enviar la configuración de VLAN. En el firmware HPE moderno, una VLAN ya existente devuelve el código de error duplicate-vlan. En esta versión anterior del firmware, la misma condición devolvía vlan-exists. El playbook se había escrito para tratar duplicate-vlan como una señal de idempotencia, es decir, “esto ya existe, está bien”. No se había escrito para manejar vlan-exists, por lo que trataba esa respuesta como un fallo. Un tercio de la flota HPE reportó fallo. El rollback se ejecutó limpiamente. El ticket del equipo de aplicaciones permaneció abierto tres horas más mientras el equipo de red auditaba manualmente qué switches habían sido configurados realmente y cuáles no.