En 2013 teníamos algo así como 500 abonados y la sensación de que habíamos resuelto el problema. La red funcionaba. Los clientes pagaban. El equipo éramos cuatro personas y nos manejábamos. Entonces empezamos a crecer más rápido de lo que habíamos previsto, y descubrimos algo que nadie te cuenta cuando montas un ISP: cada vez que multiplicas tu base por 2x o 3x, la infraestructura que funcionaba perfectamente antes empieza a crujir en un punto diferente.
Este post es la historia de esos cuellos de botella, en orden cronológico más o menos, y de cómo los fuimos resolviendo sin necesitar financiación externa. No es una historia de éxito fácil. Es una historia de decisiones, algunas buenas y algunas que nos costaron más de lo que debieron.
El primer cuello de botella: el router de borde
El primero llegó antes de los 1.000 abonados. Nuestro router de borde era un MikroTik CCR1036 que habíamos dimensionado para el doble de lo que teníamos entonces. El problema no fue el hardware, sino que le habíamos ido añadiendo funciones sin planificación: firewall stateful con reglas que habían crecido orgánicamente durante años, NAT, QoS, monitorización de flujos con Netflow, y el CGNAT que habíamos añadido cuando empezamos a quedarnos sin IPs públicas.
Con 800 abonados activos en horas punta, la CPU llegaba al 70-80% y los picos de latencia en la red empezaban a ser visibles. La solución no fue comprar un router más caro inmediatamente. Fue primero auditar qué hacía realmente el router y qué de eso podíamos mover a otro sitio.
Resultado: separamos el CGNAT a una máquina Linux dedicada, movimos el Netflow a un sensor aparte, y simplificamos las reglas de firewall eliminando las que habían quedado obsoletas. La CPU bajó al 30-40% y ganamos otros 18 meses de vida al hardware. Moraleja: antes de comprar más hardware, entiende qué está haciendo el que tienes.
El segundo: la OLT se quedó corta de puertos PON
A los 1.500 abonados, la OLT original (4 tarjetas GPON, 64 puertos PON activos) estaba al 85% de ocupación. No podíamos añadir más tarjetas porque ya habíamos llenado los slots disponibles. Teníamos que decidir: ¿segunda OLT o nueva OLT de mayor capacidad?
Elegimos añadir una segunda OLT del mismo fabricante, lo que nos permitió mantener la gestión unificada y reutilizar parte de la configuración. El coste fue considerable, pero lo financiamos con los depósitos de instalación de los nuevos abonados y el incremento de facturación mensual de los últimos seis meses. No necesitamos financiación externa porque habíamos estado generando caja positiva de forma consistente.
Lo que aprendí de esto: la capacidad de la OLT tiene que planificarse con al menos 18 meses de vista. El proceso de compra, entrega, instalación y migración de servicios a una nueva OLT tarda más de lo que parece cuando estás en plena operación. Si esperas a estar al 90% de capacidad para iniciar el proceso, ya vas tarde.
El tercero y el que más nos dolió: el RADIUS
FreeRADIUS sobre una máquina virtual con 4 GB de RAM y una base de datos MySQL que nunca habíamos optimizado. Durante años funcionó perfectamente. Hasta que llegamos a unos 2.000 abonados con sesiones activas simultáneas y empezamos a ver timeouts de autenticación esporádicos.
Los timeouts de RADIUS son especialmente traicioneros porque el síntoma visible para el abonado es que «el internet no conecta» o «la fibra parece caída». El diagnóstico diferencial entre un problema de RADIUS y un problema de la red de acceso tarda tiempo si no tienes la monitorización bien montada. Tuvimos tres incidencias en dos meses antes de aislar que el problema era el RADIUS y no la red.
La solución fue una combinación de: migración de MySQL a PostgreSQL con la configuración optimizada para el patrón de acceso de RADIUS (muchas escrituras de accounting), aumento de recursos de la VM, y sobre todo añadir un segundo servidor RADIUS en hot standby. El coste fue principalmente tiempo de ingeniería, no hardware nuevo.
Desde entonces mantenemos el principio de que cualquier componente crítico del plano de control (RADIUS, DNS recursivo, NTP) tiene al menos dos instancias activas.
El cuarto: el billing manual que ya no daba más
Llegados a los 2.500 abonados, el proceso de facturación mensual era una pesadilla. Teníamos una hoja de cálculo que alguien (yo, en su día) había ido haciendo crecer hasta convertirse en un monstruo de macros y referencias cruzadas. La generación de facturas tardaba dos días, las reclamaciones de cobro se gestionaban a mano, y cada vez que añadíamos un producto nuevo o cambiábamos una tarifa, había que modificar la hoja de varias formas que nadie excepto yo entendía del todo.
Esto es lo que hizo nacer BERP. No fue una decisión estratégica de «vamos a construir nuestro propio ERP para ISPs». Fue una necesidad concreta: los ERPs y softwares de billing para ISPs que existían en el mercado español en ese momento o eran demasiado caros para nuestro tamaño, o no integraban bien con nuestra infraestructura técnica (RADIUS, GPON, operaciones en campo), o los dos.
Empezamos construyendo solo lo que nos hacía falta: billing automatizado integrado con RADIUS, gestión de contratos, mandatos SEPA y generación de remesas bancarias. Con el tiempo le fuimos añadiendo gestión de tickets, gestión de inventario de red, portal del cliente, y la integración con la provisión automática de GPON.
Hoy BERP lo usan otros operadores además de nosotros. Puedes ver más en bayma.es/berp. Pero el origen fue puro dolor operativo a los 2.500 abonados.
El quinto: la provisión manual de GPON
Cuando hacíamos 5 instalaciones al día, la provisión manual de ONTs era perfectamente manejable. Cuando llegamos a 20-25 instalaciones diarias en temporada alta, el técnico de backoffice dedicaba 3-4 horas al día solo a provisión: entrar a la OLT, añadir el número de serie, asignar el perfil, verificar la activación, actualizar el ticket. Por instalación, unos 10-15 minutos de trabajo administrativo que se podía automatizar por completo.
La automatización de la provisión GPON fue la primera que implementamos y la que más retorno inmediato tuvo. Con la integración entre BERP y la OLT via API, el técnico de campo captura el número de serie de la ONT con el móvil, lo introduce en la app, y la provisión ocurre automáticamente. El tiempo administrativo por instalación bajó de 10-15 minutos a menos de 1 minuto.
Multiplicado por 20 instalaciones diarias, son casi 3 horas de trabajo recuperadas cada día. En un equipo pequeño, eso es enorme.
Lo que subcontratamos (y no me arrepiento)
No todo lo hicimos internamente. Hay dos áreas que decidimos subcontratar desde que el volumen lo justificó:
Monitorización 24/7: Zabbix nos da la visibilidad técnica, pero tener a alguien que responda activamente a las alertas a las 3 de la mañana requiere guardias o subcontratación. Durante un tiempo lo gestionamos internamente con guardias rotativas que nos pasaban una factura enorme en horas extra y desgaste del equipo. Pasar a un SOC externo especializado en redes para la cobertura nocturna fue una decisión que mejoró tanto los números como el bienestar del equipo.
Backups y recuperación ante desastres: Diseñamos la arquitectura internamente pero la operación de los backups (verificación, rotación, tests de restauración trimestrales) la delegamos en un proveedor externo. Un backup que nadie verifica es un backup que no existe.
El resumen de lo que aprendí
Crecer de 500 a 5.000 abonados sin romper la infraestructura y sin financiación externa es posible, pero requiere que cada euro de inversión en infraestructura se anticipe al cuello de botella, no que lo reactive. El margen operativo de un ISP de tamaño medio permite financiar el crecimiento si se gestiona bien la caja y se evitan las inversiones de pánico («el router está al 90%, compramos uno nuevo urgente»).
Los componentes que más atención merecen en orden de impacto cuando escala: RADIUS (plano de control crítico), router de borde (primero optimizar, luego escalar), OLT (planificación con 18 meses de vista), y el billing / operaciones (el mayor asesino de productividad a partir de cierto volumen).
Y automatiza pronto. La provisión GPON, la facturación, las notificaciones de incidencia. Cada proceso manual que eliminas es tiempo que el equipo puede dedicar a crecer, no a gestionar lo que ya tienes.
Si estás en ese momento de crecimiento y no sabes qué paso dar, cuéntanos. En bayma.es/operadores puedes ver cómo trabajamos con otros operadores en crecimiento. Una conversación de 30 minutos a veces aclara más que meses de dudas.
También en Bayma: Si estás creciendo como ISP, uno de los cuellos de botella que nadie menciona es la atención telefónica. Cuando tienes 300 clientes llamando tras una incidencia masiva, el equipo técnico no puede atender el teléfono. En Bayma usamos Baxilio, nuestra plataforma de centralita virtual con agente IA, precisamente para este tipo de situaciones.