Pregunta y alcance
Diseñe la recuperación para un SaaS de una sola región tras una interrupción en toda la región. El negocio requiere un máximo de una hora de pérdida de datos (RPO) y la restauración del servicio dentro de las cuatro horas (RTO). Asuma que 1,000 solicitudes por segundo en el pico es un supuesto de entrevista, no un hecho medido de producción; la aplicación es stateless, la base de datos principal es relacional y el almacenamiento de objetos contiene las cargas de los usuarios.
El diseño debe restaurar datos, código de la aplicación, configuración, secretos, enrutamiento y acceso de los operadores. También debe evitar que un entorno principal corrupto se copie a ciegas en la región de recuperación. «Tenemos copias de seguridad» no es una respuesta completa: la frecuencia de las copias de seguridad, el tiempo de restauración, la autoridad de conmutación por error y la evidencia de los simulacros deben coincidir con los objetivos.
Qué está evaluando el entrevistador
El manual de entrevistas de diseño de sistemas enmarca la recuperación ante desastres como un problema de RPO/RTO estilo entrevista y espera dominios de falla explícitos, elecciones de recuperación y pruebas operativas. AWS define RPO y RTO como objetivos de recuperación establecidos por las necesidades del negocio, y luego recomienda estrategias definidas, pruebas, gestión del desvío de configuración (drift) y automatización.
Una respuesta sólida:
- traduce el RPO en frecuencia de replicación o de copia de seguridad y mide el retraso (lag);
- traduce el RTO en presupuestos de restauración, promoción, despliegue, enrutamiento y verificación;
- separa la recuperación del plano de datos de las acciones del plano de control que podrían no estar disponibles;
- elige pilot light, warm standby o activo/activo según el costo y el objetivo, en lugar de nombrar multirregión por defecto;
- ensaya la restauración y la conmutación por error, incluyendo datos corruptos y configuraciones obsoletas.
Preguntas de clarificación antes de responder
- ¿El RPO aplica por igual a pagos, perfiles y cargas de archivos? La categorización por niveles (tiering) puede dar a los registros críticos un objetivo más estricto que a la analítica.
- ¿El desastre es una pérdida regional, un mal despliegue o una corrupción lógica? La replicación ayuda en el primer caso pero puede copiar el segundo; se requieren copias de seguridad a un punto en el tiempo para la reversión.
- ¿Deben continuar las escrituras durante la conmutación por error? En caso afirmativo, elija una autoridad de escritura y una política de conflictos; si no, una ventana de recuperación de solo lectura simplifica la consistencia.
- ¿El RTO de cuatro horas se mide hasta el éxito del health-check, el tráfico de clientes o la paridad total de funcionalidades? El runbook debe nombrar el hito.
- ¿La cuenta y el plano de control de recuperación pueden operarse de manera independiente? Las cuotas preaprovisionadas, las credenciales, las imágenes y el acceso DNS pueden determinar si el objetivo es alcanzable.
Marco de respuesta de 30 segundos
«Categorizaría la carga de trabajo por niveles, haría medibles los RPO/RTO del negocio y utilizaría replicación asíncrona de bases de datos y objetos entre regiones, además de copias de seguridad a un punto en el tiempo. Una región de tipo pilot light con infraestructura como código se ajusta a un RTO de cuatro horas si la restauración y la promoción se mantienen dentro del presupuesto. El runbook promueve un punto de datos en buen estado conocido, despliega la aplicación, cambia el enrutamiento, ejecuta comprobaciones de integridad y smoke tests, y comunica el estado. Los simulacros trimestrales miden cada paso, verifican la restauración de copias de seguridad, detectan el desvío de configuración y actualizan el objetivo si la recuperación medida ya no se ajusta».
Respuesta detallada paso a paso
1. Convertir los objetivos en un presupuesto de recuperación
Para un RPO ≤ 1 hora, el retraso máximo aceptado de replicación o el intervalo de copias de seguridad es de una hora. Configure una alerta por debajo de ese límite, por ejemplo cuando el retraso se acerque a los 45 minutos, y mantenga instantáneas a un punto en el tiempo para recuperarse de corrupciones. No afirme una frecuencia de replicación universal; mida la carga de trabajo de origen y elija un margen.
Para un RTO ≤ 4 horas, asigne un presupuesto concreto: detección y declaración, promoción de datos, despliegue de la aplicación, enrutamiento, smoke tests y una reserva. Si el runbook necesita 20 minutos para restaurar una base de datos, 30 minutos para desplegar imágenes y 10 minutos para cambiar el tráfico, esos son supuestos que se deben verificar en simulacros, no garantías.
2. Elegir la topología de recuperación
Copia de seguridad y restauración es lo más económico, pero requiere reconstruir la infraestructura y suele tener el RTO más alto. Pilot light mantiene los datos replicados y los recursos centrales de recuperación listos mientras la capacidad de la aplicación está apagada; es un punto de partida razonable para un objetivo de cuatro horas. Warm standby mantiene un stack funcional a escala reducida en ejecución y acorta la recuperación a un costo mayor. Activo/activo minimiza el tiempo de conmutación por error, pero agrega conflictos de escritura entre regiones, complejidad en la dirección del tráfico y la mayor superficie operativa.
La elección sigue al objetivo: no pague el costo de activo/activo para un objetivo de cuatro horas a menos que el impacto comercial lo justifique. Mantenga la infraestructura como código, las imágenes de contenedores, los esquemas y la configuración versionados en una cuenta de recuperación para que el despliegue sea reproducible.
3. Proteger y recuperar datos
Replique los cambios relacionales de forma asíncrona a una región separada y supervise el retraso. Promueva únicamente una réplica cuya posición de log y comprobaciones de integridad satisfagan el RPO. Almacene copias de seguridad inmutables a un punto en el tiempo en una cuenta o región separada para hacer frente a eliminaciones accidentales, ransomware y escrituras corruptas. Replique datos de objetos con control de versiones y verifique el recuento de objetos y las sumas de verificación.
El runbook registra la marca de tiempo de recuperación seleccionada, congela o drena las escrituras cuando sea necesario, promueve el almacén de datos y concilia cualquier pérdida de escritura aceptada. Si los registros de pago requieren cero pérdida de datos, necesitan un nivel diferente y posiblemente replicación síncrona; no afirme que el objetivo de una hora cubre todos los dominios.
4. Recuperar la ruta de servicio
Despliegue la aplicación a partir de imágenes inmutables y código de infraestructura. Cree previamente en la región de recuperación las comprobaciones de estado de DNS o enrutamiento global, el acceso a secretos, las cuotas de servicio y la observabilidad. Enrute tráfico solo después de que la conectividad con la base de datos, las migraciones, la autenticación y una prueba de humo representativa de lectura/escritura hayan pasado con éxito.
Mantenga mínimas las rutas de control de conmutación por error. AWS señala que las operaciones del plano de datos suelen estar más disponibles que las del plano de control durante un desastre; un diseño que depende de crear cada recurso mediante un plano de control después de la interrupción puede incumplir su RTO.
5. Hacer que el runbook sea seguro de ejecutar
Defina quién puede declarar el desastre, quién promueve los datos y quién aprueba el tráfico. Utilice un registro de pasos monotónico con un comando idempotente para cada acción, una condición de parada y un plan de reversión o failback. Publique una actualización del estado del cliente antes y después de los cambios de enrutamiento. Durante la recuperación, deshabilite las funciones no críticas si la capacidad es reducida y preserve un registro de auditoría del punto de recuperación elegido.
6. Validar con simulacros y métricas
Ejecute pruebas periódicas de restauración, regional game days y comprobaciones de desvío de configuración. Mida por separado las duraciones de detección, decisión, restauración, promoción, despliegue, enrutamiento, smoke tests y estabilización. Verifique los recuentos de filas restauradas, las sumas de verificación, los permisos, las colas y los trabajos en segundo plano. Inyecte una copia de seguridad fallida, un secreto desactualizado, una cuota insuficiente y un retraso parcial de la réplica; cada uno debería producir una alerta procesable o una detención documentada.
La prueba de aceptación es la evidencia: el RPO y RTO medidos en el último simulacro, las brechas no resueltas y los responsables. Un documento sin una restauración es solo una hipótesis.
Respuesta de muestra de alta calidad
«Para un RPO de una hora y un RTO de cuatro horas, utilizaría replicación asíncrona de base de datos y objetos entre regiones, copias de seguridad inmutables a un punto en el tiempo y una región de tipo pilot light gestionada mediante infraestructura como código. Reservaría tiempo para la detección, la promoción de datos, el despliegue de la aplicación, el DNS o enrutamiento global y los smoke tests, y luego demostraría esos tiempos en simulacros trimestrales. El runbook de conmutación por error selecciona un punto de recuperación en buen estado conocido, promueve solo después de las comprobaciones de integridad, despliega imágenes inmutables, valida la autenticación y las escrituras representativas, y luego desvía el tráfico. Si el principal tiene corrupción lógica, la replicación sola no es segura, por lo que el runbook restaura un punto anterior en el tiempo. Los datos críticos de pago serían un nivel separado con objetivos más estrictos. Informaría el retraso medido, las duraciones de recuperación, los hallazgos de drift y el próximo responsable de las medidas correctivas».
Errores comunes
- Decir «multirregión» sin objetivos → el costo y la complejidad son ilimitados → derive la topología a partir del RPO/RTO y del nivel de servicio.
- Tratar la replicación como copia de seguridad → la corrupción o eliminación puede replicarse al instante → mantenga copias inmutables a un punto en el tiempo y pruebe la restauración.
- Ignorar el código y la configuración → los datos recuperados no tienen un stack para dar servicio → versione imágenes, esquemas, acceso a secretos, cuotas e IaC en la cuenta de recuperación.
- Contar el cambio de DNS como recuperación → el tráfico llega a un sistema no saludable o no verificado → incluya promoción, smoke tests y estabilización en el RTO.
- Depender de un plano de control no disponible → la automatización no puede crear el objetivo durante la interrupción → preaprovisione los recursos críticos de recuperación y ejercite la ruta.
- Nunca ejecutar un simulacro → las copias de seguridad, cuotas y runbooks pueden quedar obsoletos → mida la restauración y la conmutación por error con regularidad mediante fallas inyectadas.
Preguntas de seguimiento y respuestas
¿Qué cambia para un RPO de cero?
La replicación asíncrona ya no satisface el objetivo. Defina una autoridad de escritura síncrona o acepte una detención de escritura a nivel de producto; luego vuelva a evaluar la latencia, el quórum y el comportamiento de partición regional.
¿Cómo se recupera de una corrupción lógica?
Detenga la promoción de la réplica corrupta, identifique una copia de seguridad limpia a un punto en el tiempo, restaure en un entorno aislado, valide las invariantes y vuelva a aplicar solo los cambios aprobados. Una región en buen estado no demuestra que los datos estén en buen estado.
¿Por qué elegir pilot light en lugar de warm standby?
Pilot light reduce los costos en estado estable y se ajusta a un objetivo de cuatro horas cuando el despliegue y el escalado están medidos. Warm standby se justifica cuando el presupuesto de RTO no puede absorber el aprovisionamiento o cuando el tráfico con capacidad reducida debe comenzar de inmediato.
¿Cómo se previene el desvío de configuración (drift)?
Genere la región de recuperación a partir de IaC versionada, compare los recursos deseados y los observados, genere alertas sobre diferencias en imágenes, esquemas, secretos, cuotas y enrutamiento, e incluya comprobaciones de desvío en cada simulacro.