🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónAlta disponibilidad no es recuperación
5 tareas · 38 min · Principiante
Un servicio repartido en tres zonas se siente seguro, y lo está frente a un servidor que se apaga. Pero la alta disponibilidad y la recuperación ante desastres responden a preguntas distintas, y una tercera pregunta, la de los datos que quedan mal escritos, solo la contesta una copia. En esta sala lees la arquitectura de Cabuya Seguros, sus modos de falla y el procedimiento de conmutación de su servicio más crítico, y compruebas si lo que el diseño llama «recuperación» es de verdad una capacidad.
Objetivo de la sala
Un servicio repartido en tres zonas se siente seguro, y lo está frente a un servidor que se apaga. Pero la alta disponibilidad y la recuperación ante desastres responden a preguntas distintas, y una tercera pregunta, la de los datos que quedan mal escritos, solo la contesta una copia. En esta sala lees la arquitectura de Cabuya Seguros, sus modos de falla y el procedimiento de conmutación de su servicio más crítico, y compruebas si lo que el diseño llama «recuperación» es de verdad una capacidad.La alta disponibilidad mantiene el servicio funcionando cuando falla una pieza: varios nodos, varias zonas, y un balanceador que reparte el trabajo. Casi no se nota la falla. La recuperación ante desastres vuelve a poner el servicio en pie en otro lugar cuando se pierde el sitio entero, y suele aceptar una interrupción. Una copia permite volver a un momento anterior en el tiempo.
La diferencia clave está en lo que replican las dos primeras: copian también los errores. Si un proceso escribe datos equivocados, la replicación los reparte con fidelidad a todos los nodos. Solo una copia, que guarda estados pasados, permite deshacerlo.
Responde para continuar
Un proceso escribe datos equivocados en la base de un servicio con réplica síncrona entre zonas. ¿Qué pasa con la réplica?
Ver pista de ayuda
Una réplica reproduce lo que recibe; no juzga si es correcto.
Declarar recuperación ante desastres es fácil: basta una línea en el plan. Que sea cierta depende de una condición física: que los datos existan en un segundo sitio. Un servicio con todas sus zonas dentro de la misma región sobrevive a la caída de una zona, pero no a la pérdida de la región, por muchas zonas que tenga.
Lee la arquitectura de Cabuya y cruza dos columnas: la que dice si el servicio declara recuperación ante desastres y la que cuenta en cuántas regiones hay datos.
Responde para continuar
¿Qué servicio declara recuperación ante desastres pero tiene sus datos en una sola región? Escribe su id.
Ver pista de ayuda
Descarta el servicio sin estado y el que no declara recuperación. Queda uno con «sí» en la última columna y un 1 en regiones con datos.
El RTO de un servicio con recuperación ante desastres no lo fija la tecnología, lo fija el procedimiento. Detectar, decidir, promover el sitio secundario y esperar a que los clientes lleguen allí: cada tramo suma. El tiempo humano de decidir suele ser el que más pesa, y el que nadie mide al diseñar.
El procedimiento de conmutación de S-01 anota el tiempo de cada tramo. Uno de ellos no está en minutos: es un valor técnico del DNS, y hay que convertirlo antes de sumar.
Responde para continuar
¿Cuántos minutos dura la conmutación de S-01 sumando todos los tramos? Escribe el número.
Ver pista de ayuda
El último tramo es esperar un TTL completo, que está expresado en segundos. Pásalo a minutos y suma los cuatro.
Una tabla de modos de falla es la herramienta con que un arquitecto comprueba que no hay una pregunta sin responder. Cada fila es algo que puede salir mal y cada columna un mecanismo; si en una fila las dos primeras columnas dicen «no», solo una copia puede responder, y si no hay copia verificada, no hay respuesta.
Responde para continuar
¿Qué modo de falla de la tabla no cubren ni la alta disponibilidad ni la réplica a otra región? Escribe su nombre.
Ver pista de ayuda
Busca la fila en la que las dos primeras columnas dicen «no» y solo la última dice «sí».
Un servicio de nivel B no necesita la recuperación de un servicio de nivel A. Pedir réplica síncrona entre regiones para algo que tolera una hora de datos perdidos es pagar una capacidad que el negocio no ha pedido, con un costo de latencia añadido. Lo que sí necesita Reclamaciones (S-02) es poder reconstruirse si se pierde la región, con sus objetivos de nivel B.
Lee en el archivo de arquitectura el nivel de S-02, sus zonas y su réplica, y elige el cambio que cubre la pérdida de región al menor costo.
Responde para continuar
¿Qué cambio da a S-02 recuperación ante la pérdida de su región al costo más bajo?
Ver pista de ayuda
El nivel B tolera una hora de datos y ocho de espera. Una zona más no sirve si lo que se pierde es la región entera.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.