Resiliencia en la nube más allá de la alta disponibilidad

Cuando una organización migra a la nube, una de las primeras decisiones de arquitectura es desplegar en varias zonas de disponibilidad. Es una buena decisión: una zona es uno o más centros de datos con energía, refrigeración y red independientes, y repartir la carga entre zonas protege contra la caída de cualquiera de ellos. El problema aparece cuando esa decisión se presenta ante el comité de riesgo como "el plan de continuidad".

La alta disponibilidad multizona responde a una pregunta concreta: ¿qué pasa si falla un sitio? La resiliencia responde a una más amplia: ¿qué pasa si falla cualquier cosa de la que depende el servicio, incluida la región completa, un servicio gestionado, el proveedor de identidad o un dato corrupto que se replicó en todas partes? Este artículo recorre esa diferencia y propone cómo cerrarla.

Alta disponibilidad no es resiliencia

Los marcos de referencia de los proveedores de nube separan con claridad ambos conceptos. El pilar de confiabilidad del AWS Well-Architected Framework distingue entre la disponibilidad de una carga de trabajo y su recuperación ante desastres, y señala que una estrategia pensada para la pérdida de un centro de datos no alcanza si la definición de desastre incluye la pérdida de una región. El Azure Well-Architected Framework, en su pilar de confiabilidad, plantea el mismo principio: diseñar para la resiliencia y, por separado, diseñar para la recuperación.

En la práctica, la multizona deja tres huecos frecuentes:

• Fallas regionales. Son poco frecuentes, pero existen: un problema en un servicio regional, en el plano de control o en la red troncal afecta a todas las zonas a la vez.
• Corrupción y borrado de datos. La replicación sincrónica entre zonas copia el error con la misma eficiencia que copia el dato bueno. Un borrado accidental o un cifrado malicioso llega a todas las réplicas en segundos.
• Errores de cambio. Una configuración defectuosa que se despliega en todas las zonas al mismo tiempo convierte la redundancia en un multiplicador del impacto.

Ninguno de estos escenarios se resuelve agregando una cuarta zona. Se resuelven con aislamiento, con copias que la falla no pueda alcanzar y con procedimientos de recuperación probados.

Las dependencias que nadie dibujó

El diagrama de arquitectura de un servicio suele mostrar balanceadores, cómputo y bases de datos. Rara vez muestra lo que hace falta para que todo eso funcione. Esas dependencias ocultas son, con frecuencia, el verdadero punto único de falla:

• DNS. Si la conmutación entre regiones depende de cambiar registros DNS, importan la disponibilidad del servicio de DNS, los tiempos de vida (TTL) configurados y el comportamiento de las cachés de los clientes.
• Identidad. Un proveedor de identidad regional o un directorio que solo existe en un sitio puede impedir que los usuarios, e incluso los operadores, inicien sesión durante la contingencia.
• Colas y mensajería. Los mensajes en tránsito en una cola regional pueden quedar inaccesibles. Hay que decidir de antemano si se pierden, se reprocesan o se reconcilian.
• Servicios gestionados. Bases de datos, almacenamiento de secretos o funciones administradas tienen su propio alcance (zonal, regional o global) y sus propias garantías. Ese alcance se lee en la documentación, no se supone.
• Terceros. Pasarelas de pago, servicios de verificación, proveedores de SMS. Su plan de continuidad forma parte del tuyo, lo sepas o no.
• Plano de control. La documentación de AWS sobre recuperación ante desastres recomienda apoyarse en operaciones del plano de datos durante la conmutación, porque el plano de control (crear o escalar recursos) suele tener objetivos de disponibilidad menores y puede ser justo lo que falla.

Un ejercicio útil es tomar un servicio crítico y preguntar, para cada dependencia: ¿dónde vive?, ¿qué pasa si no responde?, ¿cómo nos enteramos? Las respuestas suelen revelar más riesgos que cualquier revisión de la topología. La misma disciplina que se usa para encontrar la causa raíz en sistemas distribuidos sirve aquí, pero aplicada antes del incidente.

RTO y RPO por servicio, no por plataforma

El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable para restablecer el servicio. El objetivo de punto de recuperación (RPO) es la cantidad máxima de datos, medida en tiempo, que el negocio acepta perder. Un error común es fijar un único RTO y un único RPO para "la nube" o para todo el centro de datos.

Recomendamos definirlos por servicio de negocio y, cuando el servicio tiene flujos de distinta criticidad, por flujo. La consulta de saldo y la transferencia entre cuentas pueden convivir en la misma aplicación y tener tolerancias muy distintas. El Azure Well-Architected Framework propone clasificar las cargas por niveles de criticidad y derivar de ellos los objetivos de recuperación; es un buen punto de partida.

Tres reglas prácticas:

• El negocio fija el objetivo; Tecnología dice cuánto cuesta cumplirlo. Un RPO cercano a cero tiene un precio en arquitectura, licencias y operación. La conversación debe ser explícita.
• El RTO de un servicio no puede ser menor que el de sus dependencias. Si el proveedor de identidad tarda más en recuperarse que la aplicación, el RTO real es el del proveedor de identidad.
• Los objetivos se registran junto a los niveles de servicio. Si ya tienes SLA que miden lo que le importa al negocio y SLO con presupuestos de error, el RTO y el RPO deben vivir en el mismo catálogo, con el mismo dueño.

Patrones de recuperación: elegir según el objetivo

Los proveedores de nube describen un abanico de patrones que va del más simple y económico al más complejo. La tabla resume los más usados. Los valores son cualitativos y relativos entre sí: el RTO y el RPO reales dependen de la implementación, del volumen de datos y, sobre todo, de lo que demuestren las pruebas.

Patrón	Cómo funciona	RTO típico	RPO típico	Costo y complejidad
Respaldo y restauración	Copias de datos, configuración e infraestructura como código en otra región o cuenta; todo se reconstruye al activar	El más alto	Depende de la frecuencia del respaldo	Bajos
Activo-pasivo en frío (luz piloto)	Datos replicados de forma continua; el cómputo existe solo como definición y se enciende al activar	Medio	Bajo	Moderados
Activo-pasivo en caliente (espera en caliente)	Copia completa y funcional a capacidad reducida; al activar solo se escala	Bajo	Bajo	Moderados a altos
Activo-activo multirregión	Varias regiones atienden tráfico a la vez; la pérdida de una redistribuye la carga	Cercano a cero ante falla regional	Cercano a cero con replicación, pero no ante corrupción de datos	Los más altos

Dos advertencias que la documentación de los proveedores repite y que conviene subrayar. Primero, ningún patrón de replicación reemplaza a los respaldos con recuperación a un punto en el tiempo: si el dato se corrompe, la réplica también. Segundo, el activo-activo no es "el mejor patrón", sino el más caro. Tiene sentido para los pocos servicios cuyo RTO lo exige; para el resto, una espera en caliente o un buen respaldo probado suele ser la decisión correcta.

En servicios financieros, la elección del patrón y de la región secundaria también tiene implicaciones regulatorias (residencia de datos, concentración en un proveedor, notificación a supervisores). Lo tratamos en gobierno de la nube en servicios financieros.

Probar de verdad: game days, caos y restauración

Un plan de recuperación que no se ha probado es una hipótesis. Hay tres tipos de prueba que se complementan.

Game days

Un game day es un ejercicio planificado en el que un equipo simula una falla concreta (pérdida de una región, caída del proveedor de identidad, expiración de un certificado) y ejecuta el procedimiento de recuperación con cronómetro en mano. El Azure Well-Architected Framework recomienda combinar ejercicios de escritorio, ensayos en entornos no productivos y simulacros en producción, porque solo estos últimos verifican si se cumplen el RTO y el RPO en condiciones reales.

Ingeniería del caos

Los principios de la ingeniería del caos, publicados en principlesofchaos.org, proponen un método experimental: definir el estado estable del sistema con métricas de salida (rendimiento, tasa de errores, latencia), formular la hipótesis de que ese estado se mantendrá, introducir fallas que imiten eventos reales y buscar diferencias. Insisten en minimizar el radio de impacto y en automatizar los experimentos para correrlos de forma continua. En organizaciones reguladas recomendamos empezar fuera de producción, con alcance acotado y con la aprobación que exija el proceso de habilitación de cambios.

Restauración real

El capítulo sobre integridad de datos del libro de SRE de Google lo resume en una idea: nadie quiere respaldos, lo que se quiere son restauraciones. Verificar que el trabajo de respaldo terminó "en verde" no demuestra nada. Lo que demuestra algo es restaurar periódicamente en un entorno aislado, validar la integridad de los datos restaurados y medir cuánto tardó. Ese tiempo medido, no el estimado, es el que se compara con el RTO.

Por dónde empezar

Una secuencia razonable para una organización que ya opera en multizona:

1. Elige los servicios críticos. Empieza por tres a cinco servicios de negocio, no por toda la plataforma.
2. Acuerda RTO y RPO con el dueño de negocio de cada servicio, y registra el costo estimado de cumplirlos.
3. Mapea las dependencias ocultas de cada servicio: DNS, identidad, colas, servicios gestionados, terceros y plano de control.
4. Elige el patrón que cumple el objetivo al menor costo y complejidad, sin olvidar los respaldos con recuperación a un punto en el tiempo.
5. Prueba y mide. Restauración real primero, game day después, experimentos de caos cuando el proceso esté maduro.
6. Corrige y repite. Cada prueba deja hallazgos; trátalos como problemas con dueño y fecha, y vuelve a probar.

Los planes de continuidad con impacto regulatorio conviene validarlos con Riesgo y Cumplimiento antes de presentarlos al supervisor.