La alta disponibilidad (HA, high availability) es una propiedad de la infraestructura que se mide como porcentaje de tiempo en que el servicio está disponible para los usuarios. La diferencia entre un sistema con 99% de uptime y uno con 99,99% no son décimas: son ~3 días al año de caída frente a 52 minutos. Conseguirla no consiste en comprar un producto, sino en eliminar puntos únicos de fallo en cuatro capas —balanceo, cómputo, datos y detección— y en probar periódicamente que el failover funciona. En uno de nuestros casos, una tienda online que se caía en cada campaña pasó del ~98% de disponibilidad al 99,99% tras migrar a una arquitectura redundante con escalado automático; el matiz interesante es que acabó pagando por uso real, no más que antes. Ese es el planteamiento correcto: la HA se dimensiona según lo que cuesta cada hora de caída, no según lo que la técnica permite.
Esta guía explica cómo se construye HA en la práctica, qué componentes implica y cuándo el coste extra está justificado.
¿Qué significa «alta disponibilidad» de verdad?
Se expresa como un número de nueves:
| Nueves | Uptime anual | Downtime al año |
|---|---|---|
| 99% (2 nueves) | 99% | 3,65 días |
| 99,9% (3 nueves) | 99,9% | 8,76 horas |
| 99,95% | 99,95% | 4,38 horas |
| 99,99% (4 nueves) | 99,99% | 52,6 minutos |
| 99,999% (5 nueves) | 99,999% | 5,26 minutos |
Cada nueve adicional cuesta exponencialmente más. Llegar a 99,99% requiere arquitectura redundante en todos los puntos críticos; llegar a 99,999% requiere replicación geográfica y procedimientos operativos muy estrictos.
Pregunta clave antes de empezar: ¿cuánto cuesta una hora de caída? Si la respuesta son cientos de euros, 99,9% sobra. Si son miles, hay que ir a 99,99% mínimo.
Componentes clave
Balanceador de carga
Reparte tráfico entre múltiples instancias backend. Si una cae, el balanceador detecta el fallo (health checks) y deja de enviarle peticiones. Opciones: ALB/NLB en AWS, Application Gateway en Azure, GCP Load Balancing; HAProxy o Nginx self-hosted.
Sin balanceador o con uno solo, no hay HA: ese balanceador es el punto único de fallo. Y el balanceador no solo protege de caídas: también aísla problemas. En una infraestructura que operamos, una única sesión de usuario llegó a saturar la red entre los nodos de la base de datos; la monitorización de tráfico permitió identificarla y bloquearla en el balanceador en minutos, sin que el resto de usuarios notara nada. Esa capacidad de cortar un problema en la puerta es parte del valor de la capa de balanceo.
Múltiples instancias en distintas zonas
Dos backends en la misma zona de disponibilidad no protegen contra fallo de zona. La regla mínima: dos instancias en dos zonas (AZ) distintas. Para HA fuerte, multi-región. Lo mismo aplica fuera del cómputo: un segundo servidor de backups en otra ubicación puede parecer redundancia de más, hasta que una sustitución de hardware en la ubicación principal obliga a tirar de él y el servicio ni se entera. Nos pasó exactamente eso semanas después de montarlo.
Replicación de base de datos
La base de datos suele ser el punto más complicado. Opciones:
- Replica síncrona (HA real, latencia añadida en escritura).
- Replica asíncrona (mejor rendimiento, pequeño riesgo de pérdida de datos en failover).
- Multi-master (compleja, conflictos de escritura).
Servicios gestionados (RDS Multi-AZ, Aurora, Azure SQL HA) cubren la mayoría de casos sin gestionar la replicación manualmente. Y un clúster bien montado permite además operar sin ventanas de corte: hemos migrado el motor de un clúster de base de datos en producción incorporando los nodos nuevos uno a uno al clúster viejo, sin parar el servicio en ningún momento. Esa flexibilidad operativa es un beneficio de la HA que rara vez aparece en los folletos: no solo te protege de fallos, te permite mantener y evolucionar la plataforma sin madrugadas de parada programada.
Failover automático
Cuando el primario cae, el secundario asume su rol sin intervención humana. Tiempo de failover típico:
- RDS Multi-AZ: 30-120 segundos.
- Aurora: 30 segundos.
- Soluciones custom con Keepalived/Pacemaker: 5-30 segundos.
Sin failover automático, una caída a las 03:00 espera al técnico de guardia: ya no es HA. Y la escalada vertical también puede ser parte del plan: en plena campaña de un cliente, con la CPU al 100%, doblamos la capacidad del servidor de 8 a 16 núcleos con menos de un minuto de corte, porque la operación estaba prevista y ensayada. La diferencia entre un susto y una anécdota es casi siempre esa: que el procedimiento existiera antes del incidente.
Monitorización y alertas en tiempo real
Sin observabilidad activa no detectas un fallo parcial: por ejemplo, una instancia que responde 200 OK pero devuelve datos vacíos. Métricas clave: latencia p95, tasa de error, cola de peticiones, conexiones a base de datos.
RPO y RTO: las métricas que faltan en muchos proyectos
- RTO (Recovery Time Objective): cuánto puedes tardar en recuperarte de un incidente.
- RPO (Recovery Point Objective): cuántos datos puedes permitirte perder, medido en tiempo.
Ejemplos típicos:
| Caso | RTO | RPO |
|---|---|---|
| Ecommerce mediano | 1 hora | 15 minutos |
| ERP empresarial | 4 horas | 1 hora |
| Banca / pagos | Minutos | 0 (sin pérdida) |
| Web corporativa | 1 día | 1 día |
Definir RTO y RPO antes de diseñar la infraestructura es lo que evita sobre-ingeniería innecesaria y huecos críticos.
¿Cuándo conviene HA y cuándo no?
Conviene invertir en alta disponibilidad cuando el coste de la caída supera el coste de la redundancia, y no antes. Es una cuenta que se puede hacer en una servilleta: horas de caída esperables al año con la arquitectura actual, multiplicadas por lo que cuesta cada hora (ventas perdidas, personal parado, penalizaciones de SLA con tus propios clientes, daño reputacional), comparado con el sobrecoste anual de la arquitectura redundante. En cuanto la primera cifra dobla a la segunda, la decisión está tomada. Con obligaciones contractuales o sector regulado (banca, sanidad, telco), la cuenta ni siquiera hace falta. En el otro extremo, montar HA para una web corporativa o una herramienta interna no crítica es pagar complejidad operativa permanente por un riesgo que se toleraría sin problema.
Conviene cuando se cumple alguno:
- El coste de una hora de caída supera los miles de euros.
- Hay obligación contractual con SLA hacia tus clientes.
- Estás en un sector regulado (banca, sanidad, telco).
- El tráfico está distribuido geográficamente y necesitas latencia baja en varios continentes.
No conviene (o no aún) cuando:
- Web corporativa interna, blog, herramientas no críticas.
- Producto en fase muy temprana donde aún se valida el problema.
- La operación interna no soporta complejidad operativa adicional.
El error más común es construir HA por costumbre técnica sin haber definido si el negocio lo necesita.
Buenas prácticas
- Probar el failover periódicamente. Una HA que nunca se ha activado no se sabe si funciona. Lo hemos comprobado en carne ajena: un backup de producción restaurado en un entorno de pruebas que no arrancaba, porque el cifrado usaba la llave de otro nodo. Se diagnosticó y resolvió en menos de una hora, pero si esa restauración se hubiera necesitado durante un incidente real, esa hora habría sido de caída. Las pruebas existen para que los fallos aparezcan en el ensayo.
- No solo redundar el cómputo: la base de datos, la cola de mensajes, el DNS y la red también deben ser redundantes.
- Documentar el runbook: qué hacer si el sistema automático no responde.
- Postmortems sin culpas tras cada incidente: aprender sin buscar responsables.
- No confundir HA con backup. Si los datos se corrompen, el sistema redundante replica la corrupción. Necesitas backup también.
¿Te ayudamos a evaluar tu caso?
En Elimática diseñamos infraestructuras de alta disponibilidad para entornos B2B: definimos RTO/RPO, dimensionamos la arquitectura, automatizamos failover y probamos los procedimientos.
Servidores gestionados | Diagnóstico gratuito.
¿Prefieres una introducción más sencilla antes de entrar en el detalle técnico? Lee Alta disponibilidad: balanceo de carga y failover explicados.