Gestionar 600 dispositivos con un equipo pequeño: lecciones de estandarización para ISPs
Cuatro ingenieros. Seiscientos veinte dispositivos de red. Tres provincias. Un NOC que opera 24/7 con guardias rotativas.
Este no es un caso hipotético. Es el perfil operativo de varios ISPs regionales de Latinoamérica con los que trabajamos en Ayuda.LA. Y la pregunta que más se repite cuando describimos este escenario es la misma: ¿cómo es posible con tan poca gente?
La respuesta no es que esos ingenieros trabajen 80 horas semanales ni que sean extraordinariamente capaces. La respuesta es que su red está estandarizada de una manera que la mayoría de las redes de tamaño comparable no lo están.
El problema de escala que nadie nombra
Cuando un ISP tiene 50 dispositivos, la heterogeneidad es manejable. Un ingeniero conoce de memoria qué versión de firmware tiene cada router, por qué ese switch de distribución en la zona norte tiene una configuración diferente a los demás, y cuál es el procedimiento manual para aprovisionar un nuevo cliente en cada tipo de equipo.
Cuando esa red crece a 300 o 600 dispositivos, esa heterogeneidad se vuelve un problema operativo grave:
Cada equipo se convierte en un caso especial. No hay dos equipos configurados exactamente igual. Cada cambio requiere revisar la configuración individual antes de ejecutar cualquier cosa. El conocimiento está en la cabeza de las personas, no en los sistemas.
La solución de incidentes escala mal. Un ingeniero que atiende un incidente en un equipo conocido puede resolverlo en 15 minutos. El mismo incidente en un equipo con configuración no estándar puede tardar 2 horas, porque el diagnóstico requiere entender primero cómo está configurado ese equipo específico.
La automatización es casi imposible. Escribir un script que funcione en 600 equipos con 40 variantes de configuración diferentes es un proyecto en sí mismo, más complejo que gestionar los equipos a mano.
La estandarización no es un proyecto de mejora opcional. Es la precondición para poder operar a escala con equipos pequeños.
Los cinco niveles de estandarización
Nivel 1: Estandarización de vendors y modelos
El primer límite que un ISP en crecimiento debe trazar es cuántos vendors y modelos de hardware va a soportar simultáneamente. Cada vendor adicional multiplica la carga operativa:
- Un set separado de expertise técnico para certificaciones y soporte
- Herramientas de gestión diferentes (o adaptaciones para que las herramientas genéricas funcionen con ese vendor)
- Stock de repuestos para cada modelo
- Procedimientos de actualización de firmware separados
- Curva de aprendizaje para cada nuevo integrante del equipo
La recomendación práctica: definir una arquitectura de “vendors elegidos” (a veces llamado “approved hardware list”) con no más de dos vendors por función de red (core, distribución, acceso, CPE). Cualquier equipo fuera de esa lista se gestiona como excepción y tiene una fecha de fin de vida planificada.
Esto no significa no tener equipos de múltiples vendors — en redes heredadas, eso es inevitable. Significa tener una política activa de reducción de variedad, no de acumulación.
Nivel 2: Estandarización de versiones de software
Dentro de cada vendor y modelo, la cantidad de versiones de firmware/OS en producción simultánea debe ser mínima. El objetivo es tener todos los equipos de un mismo modelo en la misma versión (o con diferencia de un parche menor).
Por qué importa: los bugs de firmware que generan comportamientos inesperados son frecuentes en equipos de red. Cuando hay 8 versiones de firmware diferentes en producción, diagnosticar si un problema es de configuración o de firmware requiere verificar si el bug está presente en esa versión específica. Con una o dos versiones activas, ese diagnóstico es inmediato.
Cómo implementarlo: crear un proceso de “standardización de versiones” periódico (semestral o anual) donde se define la versión objetivo para cada plataforma y se planifica el rollout de actualizaciones. El proceso tiene que incluir pruebas en lab antes de producción y un plan de rollback por equipo.
Nivel 3: Estandarización de configuraciones (golden config)
Cada tipo de equipo tiene una configuración base (golden config) que contiene todas las políticas de la organización: protocolos de routing habilitados, políticas de autenticación, configuración de logging, parámetros de QoS, líneas de management.
La configuración específica de cada equipo (nombre, IPs, interfaces conectadas) se genera a partir de esa plantilla base más los parámetros variables de ese equipo.
El beneficio operativo inmediato: cuando se detecta un desvío de la configuración estándar (por un cambio manual no documentado, por un incidente, o por drift acumulado), el equipo tiene una referencia clara contra la cual comparar. La herramienta de validación de compliance no necesita “entender” la red — solo necesita comparar.
Herramientas: Ansible con templates Jinja2 es el estándar para generar configuraciones a partir de plantillas. Nornir con el módulo de compliance puede detectar desvíos automáticamente. Para almacenar las configuraciones versionadas, Git es suficiente.
Nivel 4: Estandarización de naming y numeración
La forma en que se nombran los equipos, las interfaces, los prefijos, y los identificadores de circuitos impacta directamente en la velocidad de diagnóstico durante incidentes.
Un esquema de naming bien diseñado permite que un ingeniero que nunca ha visto ese equipo pueda inferir de su nombre: en qué ciudad está, qué función cumple (core/distribución/acceso), a qué POPs está conectado, y en qué cluster de alta disponibilidad participa.
Ejemplo de esquema:
[ciudad]-[función]-[vendor]-[número]
bzb-core-hw-01 → Bariloche, core, Huawei, router 1
bzb-dist-ck-01 → Bariloche, distribución, Calix, switch 1
bzb-acc-tp-47 → Bariloche, acceso, TP-Link, OLT 47
El esquema debe ser documentado, exhaustivo, y aplicado retroactivamente a todos los equipos nuevos desde el momento en que se define. Los equipos heredados con naming inconsistente se migran en ciclos.
Nivel 5: Estandarización de procedimientos operativos
El último nivel es el más ignorado: los procedimientos para tareas operativas frecuentes deben estar escritos, versionados, y disponibles para todo el equipo.
Esto incluye:
- Aprovisionamiento de nuevos clientes (paso a paso, por tipo de servicio)
- Actualización de firmware (por vendor y modelo)
- Respuesta a incidentes frecuentes (caída de sesión BGP, interface down, pérdida de upstream)
- Procedimiento de cambio de equipo por falla de hardware
Cuando los procedimientos están documentados, un ingeniero junior puede ejecutar operaciones complejas con supervisión mínima. El conocimiento crítico deja de estar concentrado en una o dos personas.
La herramienta que hace posible todo esto: NetBox como fuente de verdad
Ninguno de los cinco niveles de estandarización funciona sin una fuente de verdad centralizada. NetBox es hoy el estándar de facto en ISPs modernos para este rol.
NetBox almacena:
- Inventario de equipos (vendor, modelo, versión de firmware, ubicación)
- Numeración IP (prefijos, IPs asignadas, IPs de management)
- Topología de red (conexiones entre equipos, circuitos, providers)
- Datos de aprovisionamiento (configuraciones, servicios activos por equipo)
Con NetBox bien poblado, los scripts de automatización consumen el inventario desde la API en lugar de archivos estáticos. Cuando un equipo es reemplazado o una IP cambia, la actualización en NetBox se propaga automáticamente a todos los sistemas que consumen esa información.
El requisito crítico: NetBox debe ser la fuente de verdad, no un catálogo que alguien actualiza cuando se acuerda. Esto requiere un proceso disciplinado: ningún equipo se conecta a la red sin estar primero en NetBox, y ningún cambio de IP se aplica sin actualizarse primero en NetBox.
El resultado: operación a escala con equipo pequeño
Un ISP que opera con estos cinco niveles de estandarización implementados tiene capacidades operativas cualitativamente diferentes:
Diagnóstico de incidentes más rápido. Un ingeniero puede entender el contexto de cualquier equipo en segundos, sin necesidad de acceso previo a ese equipo específico.
Onboarding de nuevos ingenieros en días, no meses. Un nuevo integrante del equipo puede empezar a atender incidentes después de una semana de capacitación en los procedimientos documentados, sin necesitar años de experiencia acumulada en esa red específica.
Automatización efectiva. Con configuraciones estandarizadas e inventario en NetBox, escribir un agente que opere sobre 600 equipos es un trabajo de semanas, no meses.
Predictibilidad operativa. Los cambios de mantenimiento tienen resultados predecibles porque los equipos están en estados conocidos. Los incidentes tienen duraciones predecibles porque los procedimientos de resolución son conocidos.
La escala no se resuelve con más personas — se resuelve con menos variedad.
Por dónde empezar
Si tu red tiene más variedad de la que tu equipo puede manejar cómodamente, el camino de estandarización empieza con dos acciones:
-
Auditoría de inventario real. Antes de estandarizar, necesitás saber exactamente qué tenés: cuántos vendors, cuántos modelos, cuántas versiones de firmware, cuántos esquemas de naming distintos. Esta auditoría suele revelar que la situación es más compleja de lo que se creía.
-
Definición del estado objetivo. Qué vendors, qué modelos, qué versiones, qué esquema de naming querés tener en 18 meses. Sin un estado objetivo claro, la estandarización se convierte en una serie de decisiones ad-hoc que no convergen.
En Ayuda.LA hacemos estas auditorías y definimos los planes de estandarización para ISPs en Latinoamérica. El resultado no es un documento — es una hoja de ruta ejecutable con impacto medible en la carga operativa del equipo.
La estandarización no es una restricción a la flexibilidad operativa. Es la condición que hace posible la escala.