Alta disponibilidad y recuperación ante desastres: cálculos, RTO, RPO y patrones de DR

Es habitual hablar de dos disciplinas como si fueran una. La alta disponibilidad consiste en sobrevivir a los fallos que ya esperas —una máquina que muere, un disco que se llena, un centro de datos que se queda sin corriente— sin que intervenga ninguna persona y sin que los usuarios lo noten demasiado. La recuperación ante desastres trata de los eventos que no puedes absorber sobre la marcha: una caída de toda una región, una base de datos corrupta replicada en todas partes, una cuenta comprometida con sus recursos borrados. Usan mecanismos distintos, cuestan cantidades distintas y fallan de formas distintas, y un sistema puede ser excelente en una e inútil en la otra.

Esta guía empieza por los números, porque los objetivos de disponibilidad elegidos sin ellos no son más que deseos. Después recorre los dominios de fallo, los patrones de redundancia que elevan la disponibilidad, los objetivos de recuperación que definen la recuperación ante desastres, las cuatro estrategias de DR habituales y su economía y, por último, las pruebas sin las cuales nada de lo anterior puede afirmarse.

Los números de la disponibilidad

La disponibilidad es el tiempo en funcionamiento dividido entre el tiempo total, y por convención se expresa en nueves. Lo que importa es el margen de caída que implica.

Cuatro nueves permiten menos de cinco minutos de caída al mes, menos de lo que se tarda en despertar a alguien y conseguir que abra el portátil. Todo lo que esté en ese nivel o por encima debe recuperarse sin intervención humana, y eso es una afirmación sobre la arquitectura, no sobre la operación.

Los componentes en serie —todos necesarios para que una petición tenga éxito— se multiplican. Un balanceador de carga, una capa de aplicación, una caché y una base de datos, cada uno al 99,99 % de forma independiente, dan 0,9999⁴ ≈ 99,96 %, más o menos tres horas y media al año, antes de contar tus propios bugs y despliegues. Cada dependencia que añades baja el techo.

Los componentes redundantes en paralelo, en cambio, multiplican sus probabilidades de fallo. Dos instancias con un 99 % de disponibilidad cada una solo fallan a la vez el 1 % × 1 % del tiempo, lo que da un 99,99 %, siempre que los fallos sean independientes. Todo el argumento descansa en esa condición, y normalmente no se cumple.

Dominios de fallo y fallos correlacionados

Un dominio de fallo es un conjunto de recursos que pueden fallar juntos. Saber identificarlos es la habilidad clave, porque la redundancia solo ayuda cuando las copias están en dominios distintos.

La jerarquía física va del proceso al host, al rack, al centro de datos, a la zona de disponibilidad y a la región. Los proveedores exponen la zona como la unidad sobre la que colocas recursos, y repartir instancias entre zonas es la defensa estándar frente a un incidente en un centro de datos.

Sin embargo, los dominios que de verdad provocan incidentes rara vez son físicos:

• Dependencias compartidas. Tres instancias en tres zonas detrás de un único balanceador, todas leyendo de una única base de datos en una sola zona. El dominio es la base de datos.
• El control plane. Las API de aprovisionamiento, el autoescalado y IAM son servicios regionales. Durante un gran incidente regional, las mismas API que necesitas para lanzar capacidad de reemplazo son las que están degradadas. Los caminos de recuperación que requieren crear recursos nuevos son más débiles que los que solo requieren desviar tráfico a recursos que ya existen; a esto se le llama ser estáticamente estable (statically stable).
• Configuración y despliegue. La causa más habitual de fallo correlacionado es un cambio aplicado en todas partes a la vez: un push de configuración erróneo, una migración de esquema, un certificado caducado desplegado por la misma automatización en todas las réplicas. Aquí la redundancia no protege; el despliegue escalonado, sí.
• Capacidad y cuotas. Un failover que duplica la carga en la zona superviviente solo funciona si esa zona tenía capacidad libre. Escalar a dos zonas y dimensionar cada una para exactamente la mitad del tráfico garantiza una degradación cuando una de ellas cae.
• Destino compartido en el software. Todas las instancias que ejecutan el mismo código se topan con la misma fuga de memoria al mismo tiempo de actividad, y el mismo mensaje envenenado tumba a todos los consumidores.

Dos patrones limitan el daño correlacionado. La arquitectura basada en celdas (cell-based architecture) reparte a los usuarios en celdas independientes, cada una con una pila completa, de modo que una celda defectuosa afecta a una fracción conocida de los clientes. El shuffle sharding asigna a cada cliente un subconjunto aleatorio de workers, de forma que un tenant abusivo rara vez tumba a otro.

RTO y RPO

La recuperación ante desastres se define con dos números, y ambos son decisiones de negocio que ingeniería implementa.

El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable entre el desastre y el restablecimiento del servicio. El objetivo de punto de recuperación (RPO) es la pérdida de datos máxima aceptable, expresada en tiempo: un RPO de quince minutos significa que perder los últimos quince minutos de escrituras es tolerable.

Derívalos del impacto, no de las aspiraciones. Pregunta cuánto pierde la organización por cada hora de caída —ingresos, sanciones regulatorias, créditos contractuales, coste reputacional— y cuánto cuesta volver a introducir las transacciones perdidas. Representa el coste de la caída frente al coste de la protección; el objetivo sensato está cerca de su intersección, no en cero. Si le preguntas a un responsable de negocio «¿cuánta caída es aceptable?», siempre responderá «ninguna», así que pregúntale mejor «¿qué harías durante cuatro horas sin esto?».

Clasifica tus sistemas por niveles. Una ruta de autorización de pagos puede necesitar un RTO de minutos y un RPO cercano a cero; una herramienta interna de informes puede aceptar un día en ambos. Aplicar el nivel más estricto en todas partes es la forma más segura de que la recuperación ante desastres resulte inasumible y, por tanto, nunca se construya.

Patrones de redundancia para la alta disponibilidad

Dentro de una región, las piezas básicas son bien conocidas.

Capas stateless repartidas entre zonas. Coloca instancias en al menos tres zonas detrás de un balanceador, en un grupo de autoescalado cuyo mínimo sobreviva a la pérdida de una zona. Dimensiona cada zona para que las supervivientes absorban la parte de la zona caída: con tres zonas eso supone un margen de alrededor del 50 %, frente al 100 % que exigen dos zonas.

Health checks con sentido. Un check que devuelve 200 siempre que el proceso esté vivo sigue enviando tráfico a una instancia que no puede llegar a su base de datos; un check que falla en cuanto cualquier dependencia es inalcanzable puede retirar toda la flota durante un fallo pasajero. Usa un check superficial para el balanceador y otro más profundo para las alertas y los controles de despliegue.

Timeouts, reintentos con jitter y circuit breakers. Los reintentos sin backoff exponencial ni jitter aleatorio convierten una breve ralentización de una dependencia en una denegación de servicio autoinfligida. Un circuit breaker que se abre tras un umbral de fallos y deja pasar un goteo de sondas le da a la dependencia margen para recuperarse. Los bulkheads —pools de conexiones separados por dependencia— evitan que un servicio lento aguas abajo agote los recursos que necesitan todas las demás peticiones.

Degradación elegante. Decide de antemano qué hace el sistema sin cada una de sus dependencias. Servir precios cacheados aunque estén desactualizados, encolar escrituras para procesarlas más tarde o desactivar las recomendaciones manteniendo vivo el checkout son mejores resultados que una página de error, y hay que diseñarlos, no improvisarlos.

Servicios de datos gestionados multizona. El almacenamiento de objetos y las colas gestionadas ya son redundantes entre zonas. Las bases de datos relacionales suelen ofrecer un standby síncrono en una segunda zona con failover automático, además de réplicas de lectura asíncronas. Ten claro cuáles de tus almacenes replican de forma síncrona: es la diferencia entre una pérdida de datos nula y una que no lo es.

Las cuatro estrategias de recuperación ante desastres

Entre regiones, cuatro patrones cubren casi cualquier requisito. El coste sube con cada paso y el tiempo de recuperación baja.

Backup and restore. Los backups y snapshots se copian a una segunda región; allí no se ejecuta nada hasta que hace falta. La infraestructura se recrea a partir de plantillas y los datos se restauran desde la última copia. El RPO equivale al intervalo entre backups, el RTO va de horas a un día y el coste permanente es solo el almacenamiento. Es lo correcto para la mayoría de los sistemas internos, y la única estrategia que además protege frente a la corrupción lógica; por eso todas las demás también la incluyen.

Pilot light. La capa de datos se replica de forma continua a la segunda región y se mantiene activa, mientras que la capa de cómputo existe como plantillas e imágenes pero funciona a capacidad cero o casi cero. Recuperar significa escalar el cómputo y promover la réplica. El RPO es de segundos a minutos, el RTO de decenas de minutos, y el coste permanente son los datos replicados más una pequeña huella siempre encendida.

Warm standby. Una copia completa pero reducida del entorno funciona de forma continua en la segunda región, sin servir tráfico o con una parte simbólica. El failover consiste en desviar tráfico y escalar. El RPO es de segundos, el RTO de minutos y el coste es sensiblemente mayor: suele estar entre una cuarta parte y la mitad del de producción, según cuánto se reduzca. La ventaja decisiva es que el standby está en marcha, así que sus despliegues, certificados y permisos se ejercitan continuamente en lugar de descubrirse a las tres de la madrugada.

Multi-site active-active. Ambas regiones sirven tráfico de producción detrás de una capa de enrutamiento global. El RTO se acerca a cero, el RPO depende del modelo de replicación y el coste es, como mínimo, el doble. Es la única opción que además aporta ventajas de latencia regional, y te obliga a resolver la gestión de conflictos, la identidad global y la compatibilidad simultánea de esquemas. El verdadero precio es la complejidad; la factura de infraestructura es la parte menor.

El failover de la base de datos manda en los tiempos

En casi cualquier recuperación, la capa stateless es trivial y la base de datos marca el reloj.

La replicación síncrona solo confirma en el primario cuando un standby ha reconocido la escritura: cero pérdida de datos, a cambio de una latencia proporcional a la distancia. Es viable entre zonas y, en general, inviable entre regiones lejanas. La replicación asíncrona confirma localmente y envía los cambios después, así que el RPO entre regiones equivale al retraso de replicación, que debe tener una alarma, porque crece en silencio con las ráfagas de escritura y las transacciones largas.

La promoción es el momento peligroso. La promoción automática entre regiones corre el riesgo de split brain: una partición convence a la secundaria de que la primaria ha muerto mientras esta sigue aceptando escrituras, y quedan dos historiales divergentes. Dentro de una región, el failover automático basado en quórum es seguro y estándar; entre regiones, la mayoría de las organizaciones exigen una decisión humana, porque la señal de fallo es ambigua.

Son los detalles prácticos los que deciden si la promoción funciona: las aplicaciones deben reconectarse en lugar de cachear para siempre una dirección resuelta; las cadenas de conexión deben apuntar a un alias DNS o a un endpoint de proxy que puedas redirigir; el failback debe planificarse, porque invertir la replicación suele ser más difícil que el propio failover; y la secundaria debe tener las mismas claves de cifrado, credenciales y versión de esquema. Las implicaciones de consistencia de aceptar escrituras en dos sitios se tratan en transacciones distribuidas y consistencia.

Backups: lo que todos dicen tener y pocos verifican

Sigue una disciplina 3-2-1 adaptada a la nube: al menos tres copias, en dos tipos de almacenamiento, con una aislada —otra cuenta o suscripción, otras credenciales, object lock o inmutabilidad activados y, preferiblemente, otra región—. El aislamiento no tiene que ver con fallos de hardware, sino con un atacante o una automatización equivocada que tenga permisos de borrado.

Después, prueba las restauraciones de forma periódica y mide cuánto tardan, porque una restauración de varios terabytes desde almacenamiento en frío puede superar el RTO en un orden de magnitud, y solo intentándolo lo descubres. Automatiza una restauración periódica en un entorno desechable, ejecuta sobre ella un checksum y una consulta de negocio, y registra el tiempo transcurrido como métrica con una alarma ante regresiones.

Demostrarlo con game days

Un plan de recuperación sin probar es un documento, no una capacidad. Un game day es un ejercicio programado en el que el equipo ejecuta un escenario de fallo contra un entorno real.

Empieza en un entorno de preproducción que refleje de verdad producción, anuncia el ejercicio y plantea antes una hipótesis: «si terminamos la instancia primaria de la base de datos, el tráfico se recupera en noventa segundos sin escrituras fallidas». Después inyecta el fallo y anota lo que ocurrió realmente. El resultado valioso es la lista de sorpresas: un rol IAM que falta, una alerta que va a un equipo disuelto, un paso del runbook que menciona una herramienta ya retirada.

Escenarios que vale la pena ensayar, más o menos por orden de madurez: terminar una instancia; hacer failover de la base de datos; perder una zona de disponibilidad; restaurar la base de datos más grande y cronometrarlo; dejar caducar un certificado; perder el proveedor de identidad; ejecutar un failover regional; y recuperarse de una corrupción lógica descubierta seis horas tarde. Este último rara vez se ensaya y es de los que más probabilidades tienen de ocurrir.

La inyección automatizada de fallos lo convierte en algo continuo en lugar de anual. Las dos grandes nubes ofrecen servicios gestionados de inyección de fallos que detienen instancias, añaden latencia o aplican throttling a las API dentro de un radio de impacto controlado, con una condición de parada vinculada a una alarma. Ejecutar pequeños experimentos de forma continua —primero en preproducción y, con el tiempo, en producción con personas vigilando— convierte la resiliencia declarada en resiliencia medida, y es exactamente la evidencia que pide una revisión Well-Architected.

Puntos clave

• Los objetivos de disponibilidad son aritmética: las dependencias en serie se multiplican, cuatro nueves exigen recuperación automática y el SLA de un proveedor es una tabla de créditos, no una promesa sobre tu sistema.
• La redundancia solo ayuda entre dominios de fallo independientes; los fallos correlacionados por dependencias compartidas, control planes, pushes de configuración y falta de capacidad desbaratan la duplicación ingenua.
• El RTO y el RPO salen del impacto en el negocio y deben escalonarse por workload; aplicar el nivel más estricto en todas partes hace inasumible la recuperación ante desastres.
• Las cuatro estrategias de DR intercambian coste por tiempo de recuperación —backup and restore, pilot light, warm standby, active-active— y todas siguen necesitando backups inmutables y aislados.
• La replicación y la promoción de la base de datos marcan el tiempo de recuperación: síncrona dentro de una región, asíncrona entre regiones y con el failback planificado de antemano.
• Una capacidad de recuperación solo existe cuando se ha ejercitado: programa game days, mide los tiempos de restauración e inyecta fallos de forma continua en lugar de fiarte del runbook.