Diseñando la Automatización de Redes a Escala on Designing Network Automation at Scale

01 - El Imperativo de la Automatización

Mon, 10 Nov 2025 00:00:00 +0000

1. El Imperativo de la Automatización#

“Automatizar o no automatizar — esa es la cuestión.”

Desde que llegaron el Software-Defined Networking (SDN) y el DevOps, los ingenieros han debatido si la automatización de redes es necesaria, un lujo o simplemente una sobreingeniería. ¿La respuesta? Depende. Los hiperscaladores la necesitan: empezaron a principios de los años 2010 porque no tenían otra opción. Las pequeñas empresas quizás no necesiten automatización completa en absoluto. La mayoría de las redes se sitúan en algún punto intermedio. La cultura, las habilidades, la madurez de las herramientas y las prioridades del negocio determinan la velocidad de adopción. Hoy, todos esos factores se están alineando. La automatización se está volviendo inevitable.

02 - Principios de Diseño

Sun, 30 Nov 2025 00:00:00 +0000

2. Principios de Diseño#

Un equipo de automatización de redes pasó seis meses construyendo un sistema del que estaban genuinamente orgullosos. Extraía la intención de un modelo de datos estructurado, generaba configuraciones de dispositivos a través de un motor de plantillas, validaba los cambios contra una biblioteca de políticas y los aplicaba mediante NETCONF con soporte completo de reversión. Arquitectónicamente, era sólido. La demo para la dirección fue bien. Luego lo entregaron al equipo de operaciones de red.

03 - Pensamiento Arquitectónico

Wed, 10 Dec 2025 00:00:00 +0000

3. Pensamiento Arquitectónico#

Este capítulo introduce los fundamentos de este libro. Explica por qué necesitas adoptar esta mentalidad, introduce un marco de referencia propuesto por el Network Automation Forum (NAF), y muestra cómo aprovecharlo en tus proyectos.

La Parte 2 profundiza en estos temas. En este capítulo, solo los presentaremos para dar una visión de alto nivel antes de entrar en los detalles. Esto importa porque una vez que describamos cada bloque de construcción, tener la imagen general te ayuda a conectar los puntos.

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.

Prefacio

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

Prefacio#

La automatización de redes ya no es un lujo ni una tecnología experimental: se ha convertido en una necesidad operativa. Desde los centros de datos hiperscala que gestionan cientos de miles de dispositivos hasta las redes empresariales que equilibran sistemas heredados con servicios cloud-native, la complejidad y la escala de las redes modernas exigen enfoques sistemáticos y arquitectónicos para la automatización.

Este libro surge de años de experiencia práctica diseñando, construyendo y operando sistemas de automatización de redes en distintos entornos y escalas organizativas. Representa una síntesis de lecciones aprendidas, patrones observados y principios descubiertos a través de la implementación real de plataformas de automatización.

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.

10 - Ingeniería de Plataforma y CI/CD

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

(Traducción pendiente)

11 - Escala y Fiabilidad

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

(Traducción pendiente)

12 - Seguridad y Cumplimiento

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

(Traducción pendiente)

13 - El Cambio Cultural

Sun, 19 Apr 2026 00:00:00 +0000

13. El Cambio Cultural#

La convocatoria de reunión llegó un jueves, con el título “Actualización sobre la estructura del equipo de red”. Jordi llevaba quince años como ingeniero de red. Tenía el CCIE. Había sobrevivido a tres adquisiciones, dos consolidaciones de NOC y un incidente de enrutamiento BGP tan grave que se convirtió en un caso de estudio interno. Asumió que era una actualización de plantilla.

No lo era.

Su manager explicó que el equipo de red se reorganizaría bajo Platform Engineering. El nombre del equipo cambiaría a Network Automation Platform. El trabajo evolucionaría: menos aprovisionamiento manual, más construcción y operación de los sistemas de automatización que gestionarían el aprovisionamiento. La nueva descripción del puesto ya estaba escrita. Se titulaba “Network Platform Engineer”.

14 - La Automatización como Producto

Tue, 05 May 2026 00:00:00 +0000

14. La Automatización como Producto#

Seis meses antes de la conversación que cambió la manera de trabajar del equipo, el equipo de plataforma de red había entregado algo genuinamente impresionante. Dos años de esfuerzo constante habían producido una plataforma de provisioning que gestionaba el onboarding de sucursales de extremo a extremo: una interfaz de autoservicio para solicitudes de sedes, un flujo de trabajo de validación en bucle cerrado que detectaba errores de configuración antes del despliegue, y un panel operativo que hacía seguimiento de la salud del servicio en trescientas ubicaciones. El equipo había pasado de ventanas de cambio de veinticuatro horas a despliegues automatizados de cuarenta minutos. Estaban orgullosos de ello, y con razón.

15 - Automatización de Bucle Cerrado

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

(Traducción pendiente)

16 - Redes Autocurativas

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

(Traducción pendiente)

17 - Redes Autónomas

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

(Traducción pendiente)

Acerca del Autor

Sun, 10 May 2026 00:00:00 +0000

Acerca de Christian Adell#

Staff Network Developer en CoreWeave | Barcelona, España

Christian Adell ha desarrollado su carrera en torno al desarrollo de software aplicado a la automatización de redes. Tiene una amplia experiencia en el diseño e implementación de soluciones de automatización de redes a escala.

Contacto#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

Libros Publicados#

Christian es autor y coautor de varios libros influyentes sobre automatización de redes:

Network Programmability and Automation, 2nd Edition

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 2nd Edition

Conferencias y Participación Comunitaria#

Christian es un ponente activo en grandes conferencias de networking y eventos comunitarios:

Aviso Legal

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

Aviso Legal#

Aviso de Copyright#

El contenido de este sitio, incluyendo texto, diagramas y ejemplos, es propiedad intelectual del autor bajo la Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional (CC BY-NC-ND 4.0).

Eres libre de

Compartir — copiar y redistribuir el material en cualquier medio o formato, con la atribución adecuada

Bajo las siguientes restricciones:

Atribución — Debes dar el crédito adecuado a Christian Adell Querol, proporcionar un enlace a la licencia e indicar si se realizaron cambios.
NoComercial — No puedes utilizar el material con fines comerciales.
SinObraDerivada — No puedes remezclar, transformar ni construir sobre el material para su distribución.

Notas Importantes