Lecciones del apagón del 28 de abril de 2025: cuando la redundancia deja de ser teórica

La alta disponibilidad no consiste en duplicar equipos. Consiste en comprender qué puede fallar, cómo se propaga el fallo y qué necesitamos para seguir funcionando.

El 28 de abril de 2025, el gran apagón eléctrico que afectó a la península ibérica nos recordó algo que, en ingeniería de infraestructuras, resulta fácil olvidar: la redundancia que diseñamos sobre el papel no siempre coincide con la independencia real de los sistemas.

Acostumbramos a pensar en la continuidad de servicio en términos de routers duplicados, enlaces de distintos operadores, fuentes de alimentación redundantes o centros de datos geográficamente separados.

Sin embargo, todos esos elementos pueden compartir dependencias que no aparecen en nuestros diagramas de red.

Este artículo recoge algunas reflexiones técnicas y escenarios hipotéticos que nos sirven para revisar cómo diseñamos la resiliencia de las infraestructuras.

1. Dos enlaces no siempre significan dos caminos independientes

Imaginemos una empresa con dos conexiones de Internet:

A primera vista, disponemos de dos operadores y dos routers.

Pero ambos enlaces pueden compartir canalizaciones, instalaciones eléctricas o dependencias en la red de transporte.

La redundancia de proveedores no garantiza la independencia de infraestructura.

La primera lección es que debemos investigar los dominios de fallo compartidos antes de dar por redundante una arquitectura.

2. La autonomía eléctrica es una propiedad de toda la cadena

Un SAI no garantiza por sí solo la continuidad del servicio.

Podemos disponer de un router con cuatro horas de autonomía, pero si el switch de acceso, la ONT o el equipo de transmisión del operador se quedan sin alimentación a los veinte minutos, la conectividad desaparecerá igualmente.

Consideremos este escenario:

El punto débil es evidente: la ONT no tiene alimentación de respaldo.

Y hay otro factor menos visible: la autonomía eléctrica de los equipos del operador situados fuera de nuestras instalaciones.

Por eso, una auditoría de continuidad debería incluir el recorrido completo del servicio, desde los dispositivos internos hasta las dependencias externas conocidas.

3. El respaldo LTE o 5G tampoco es infalible

La conectividad móvil suele ser una excelente alternativa a la fibra.

Pero durante una interrupción eléctrica extensa pueden coincidir varios problemas:

• Estaciones base funcionando con baterías de autonomía limitada.

• Congestión por incremento extraordinario del tráfico.

• Pérdida de capacidad en redes de transporte.

• Cobertura disponible, pero sin conectividad de datos útil.

• Degradación progresiva del servicio conforme se agotan las reservas energéticas.

Esto nos obliga a distinguir entre tener señal móvil y disponer de un camino de comunicaciones operativo.

Un router LTE puede indicar una excelente intensidad de señal y, sin embargo, ser incapaz de alcanzar los servicios críticos.

Comprobaciones útiles

En una instalación MikroTik podríamos monitorizar:

/tool netwatch
add host=1.1.1.1 type=icmp interval=30s comment="Prueba conectividad exterior"

Esta comprobación es únicamente ilustrativa: una dirección IP accesible no demuestra que todos los servicios funcionen ni identifica por sí sola qué enlace está siendo utilizado.

En producción utilizaríamos varias sondas, rutas específicas y criterios de recuperación que eviten oscilaciones innecesarias.

4. La alta disponibilidad necesita dominios de fallo independientes

Un diseño simplificado de comunicaciones redundantes podría representarse así:

flowchart TD
    A["Red corporativa"] --> B["Router principal"]
    A --> C["Router secundario"]
    B --> D["Operador de fibra"]
    C --> E["Operador móvil"]
    D --> F["Servicios externos"]
    E --> F
    G["SAI principal"] --> B
    H["SAI independiente"] --> C

Este esquema es deliberadamente sencillo.

La cuestión fundamental no es únicamente disponer de dos routers o dos operadores. También debemos analizar si ambos caminos comparten:

• Alimentación eléctrica.

• Espacios físicos.

• Equipos de conmutación.

• Infraestructura de transporte.

• Sistemas de autenticación.

• Servicios DNS.

• Plataformas de gestión.

Una arquitectura es tan resistente como sus dependencias menos visibles.

5. No todos los servicios necesitan la misma disponibilidad

Una de las conclusiones más importantes es que no siempre resulta razonable diseñar toda una empresa para soportar indefinidamente un apagón generalizado.

La ingeniería debe ser proporcionada.

Un pequeño comercio, una cadena hotelera y un centro de datos tienen necesidades muy diferentes.

Podemos establecer distintos niveles de continuidad:

No se trata de vender siempre el nivel más alto.

Se trata de identificar qué servicios deben continuar funcionando, durante cuánto tiempo y a qué coste.

6. La recuperación también forma parte del diseño

Otro aspecto importante aparece cuando vuelve la electricidad.

No todos los dispositivos arrancan a la misma velocidad ni recuperan sus servicios simultáneamente.

Podemos encontrarnos con:

• Routers operativos antes de que el operador haya recuperado su red.

• Switches PoE con demasiados dispositivos arrancando simultáneamente.

• Túneles VPN que requieren renegociación.

• Servicios DNS o de autenticación todavía indisponibles.

• Equipos que necesitan intervención manual para recuperar su funcionamiento.

La continuidad de negocio no termina cuando regresa la alimentación.

También debemos comprobar que los sistemas recuperan su estado operativo de manera ordenada y verificable.

7. Probar la redundancia antes de necesitarla

Una arquitectura de alta disponibilidad que nunca se ha probado es, en buena medida, una hipótesis.

Por eso conviene realizar pruebas controladas:

1. Desconectar el enlace principal y comprobar la conmutación.

2. Simular la caída de un router.

3. Verificar la autonomía eléctrica real bajo carga.

4. Comprobar la recuperación automática de las VPN.

5. Validar que la monitorización detecta la degradación.

6. Documentar los tiempos de recuperación y las intervenciones necesarias.

Estas pruebas deben planificarse cuidadosamente para evitar interrupciones accidentales de servicios en producción.

8. La lección principal: diseñar para el problema real

En Merática defendemos una idea que aplicamos habitualmente a nuestros proyectos: la ingeniería debe adaptarse a las necesidades del cliente, no al catálogo de soluciones disponibles.

El apagón del 28 de abril de 2025 nos ofrece un buen punto de partida para reflexionar sobre esta filosofía.

Podemos instalar dos routers, tres operadores y múltiples sistemas de alimentación. Pero si no hemos identificado correctamente los riesgos y las dependencias, quizá estemos aumentando el coste y la complejidad sin conseguir la resiliencia esperada.

En cambio, una solución relativamente sencilla, bien diseñada y probada puede ofrecer una continuidad de servicio perfectamente adecuada a las necesidades de una organización.

La pregunta correcta no es ¿cuánta redundancia podemos instalar?, sino ¿qué necesitamos que siga funcionando cuando todo lo demás falle?

Artículo de prueba editorial de Merática. Los ejemplos, consumos, autonomías y arquitecturas son hipotéticos y se incluyen exclusivamente con fines ilustrativos.

Raúl López Nevot
Merática — Ingeniería de redes, sistemas y seguridad.