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.
Esta guía explica cómo se construye HA en la práctica, qué componentes implica y cuándo el coste extra está justificado.
Tabla de contenidos
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.
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.
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.
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.
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 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.
- 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.
Preguntas frecuentes
¿Cuántos nueves de disponibilidad necesito de verdad?
Depende del coste de una hora de caída. Si son cientos de euros, 99,9% (unas 8,7 horas de downtime al año) suele sobrar. Si son miles, hay que ir a 99,99% (52 minutos al año) como mínimo. Subir de 99,99% a 99,999% multiplica el coste y solo se justifica en banca, telco o servicios regulados.
¿La alta disponibilidad me protege de perder datos?
No, y confundirlo es un error caro. Si los datos se corrompen o alguien los borra, el sistema redundante replica esa corrupción al instante. HA protege frente a caídas de hardware o de zona; para corrupción y errores humanos necesitas backups probados. Son dos cosas distintas y complementarias.
¿Qué diferencia hay entre RTO y RPO y por qué importan?
El RTO es cuánto tardas en recuperarte tras un incidente; el RPO es cuántos datos (en tiempo) puedes permitirte perder. Definirlos antes de diseñar la arquitectura es lo que evita tanto la sobre-ingeniería (pagar 99,999% para un blog) como los huecos críticos (descubrir que pierdes una hora de pedidos en el failover).
¿Puedo conseguir alta disponibilidad sin multi-región?
Para la mayoría de proyectos, sí: dos instancias en dos zonas de disponibilidad distintas más una base de datos gestionada en Multi-AZ ya dan 99,99% sin la complejidad ni el coste de multi-región. La replicación geográfica solo es necesaria si tienes usuarios en varios continentes o un requisito regulatorio de continuidad ante caída de toda una regió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.