Arquitectura y despliegue
Alta disponibilidad y continuidad: diseñar para el día en que algo falla
01 · Objetivos
- Impacto de una parada
- RTO y RPO acordados
02 · Diseño
- Redundancia proporcional
- Copias separadas e inmutables
03 · Vigilancia
- Comprobaciones externas
- Alertas con responsable
04 · Recuperación
- Procedimiento escrito
- Restauración o conmutación
05 · Ensayo
- Pruebas periódicas
- Tiempos medidos y mejoras
El problema
Por qué hay que decidirlo bien
Muchas empresas descubren su verdadero plan de recuperación el día que lo necesitan: las copias existían pero nadie había intentado restaurarlas, la persona que sabía hacerlo estaba de vacaciones o la restauración tardó dos días cuando el negocio esperaba dos horas. En el extremo opuesto, otras pagan infraestructura duplicada para sistemas que podrían esperar sin daño. El problema de fondo es que nadie fijó qué nivel de continuidad necesita cada sistema ni lo comprobó. Sin objetivos pactados y pruebas periódicas, la disponibilidad es una suposición.
Escenarios
Situaciones en las que se plantea
Ejemplos de lo que se podría diseñar. No describen proyectos realizados.
01
Sistema de pedidos que no puede pararse en horario comercial
Una parada de varias horas supone pedidos perdidos y clientes desatendidos. Se estudian componentes redundantes en varias zonas, base de datos con réplica y un procedimiento de conmutación ensayado, valorando su coste frente al impacto estimado.
02
Herramienta interna que tolera una parada
Una aplicación de informes puede estar fuera de servicio medio día sin consecuencias graves. Basta con copias diarias verificadas y un procedimiento de reconstrucción documentado, sin pagar infraestructura duplicada que nunca se usará.
03
Borrado accidental de datos
Un error en una operación masiva elimina registros válidos. La réplica en tiempo real copia también el borrado, así que la recuperación depende de copias puntuales o de restauración a un momento anterior, que deben existir y estar probadas.
04
Caída de una región o de un centro de datos
Un fallo amplio deja sin servicio toda una ubicación. Se decide si basta con reconstruir en otra ubicación a partir de copias o si se justifica mantener un entorno de reserva preparado, con el coste que implica.
Decisiones técnicas
Qué hay que decidir y con qué criterio
01
RTO y RPO pactados por sistema
Se acuerdan con el negocio para cada sistema, o incluso para cada función, a partir del impacto de una parada y de una pérdida de datos. Son objetivos de diseño que se verifican en pruebas, no garantías contractuales automáticas.
02
Redundancia proporcional
Instancias duplicadas, balanceo, réplicas de base de datos o despliegue en varias zonas solo donde el objetivo lo exige. Cada capa de redundancia añade coste, complejidad y nuevos modos de fallo que también hay que vigilar.
03
Copias de seguridad y restauración
Frecuencia coherente con el RPO, copias inmutables o separadas de la cuenta principal, cifrado, retención definida y restauraciones de prueba periódicas con el tiempo medido y comparado con el RTO acordado.
04
Monitorización y alertas
Comprobaciones externas de disponibilidad, métricas de salud de cada componente, alertas con umbrales razonables y un responsable de guardia conocido. Una alerta que nadie recibe equivale a no tener monitorización.
05
Procedimientos y ensayos
Pasos escritos para conmutar, restaurar o reconstruir, ejecutables por alguien distinto de quien los redactó. Se ensayan con una frecuencia acordada y cada ensayo deja registro de lo que falló y se corrigió.
Riesgos y límites
Lo que conviene tener presente
- Un RTO o RPO muy exigente puede multiplicar el coste de infraestructura y de operación; conviene conocer esa relación antes de fijarlo.
- La replicación protege frente a fallos de hardware, pero no frente a errores lógicos o borrados, que se propagan a la réplica.
- Las dependencias externas (proveedores de identidad, pasarelas de pago, APIs de terceros) limitan la disponibilidad alcanzable aunque el sistema propio sea redundante.
- Un plan no ensayado suele fallar en detalles: credenciales caducadas, documentación desactualizada o pasos que dependen de una persona concreta.
Preguntas frecuentes
¿Podéis garantizar que el sistema nunca se caiga?
No, y desconfía de quien lo prometa. Se puede reducir la probabilidad y la duración de las paradas, y pactar objetivos de recuperación medibles. Los compromisos concretos de servicio, si los hay, se definen por contrato en cada proyecto.
¿Qué diferencia hay entre copia de seguridad y réplica?
La réplica mantiene otra base de datos sincronizada para sustituir a la principal si falla, pero copia también los errores. La copia de seguridad guarda el estado en momentos concretos y permite volver atrás. Normalmente se necesitan ambas.
¿Cada cuánto hay que probar la restauración?
Se acuerda según la criticidad del sistema; lo importante es que sea periódico y que se mida el tiempo real. También conviene probar después de cambios relevantes de infraestructura o de volumen de datos.
Sectores, capacidades y lecturas relacionadas
Sectores donde se plantea
Capacidades relacionadas
- Seguridad de aplicacionesControles de seguridad pensados desde el diseño de cada aplicación: amenazas identificadas, secretos protegidos, dependencias vigiladas y pruebas en el ciclo de desarrollo.
- Analítica operativaIndicadores, alertas e históricos construidos sobre datos depurados y con definiciones acordadas, para que todos discutan la misma cifra.
Más en arquitectura y despliegue
Cuéntanos qué pasaría hoy si tu sistema se parase un día entero
Ninguna modalidad está disponible por defecto en todos los proyectos: se elige tras evaluar requisitos, sistemas existentes y riesgos.
Sin compromiso de aceptación: estudiamos cada caso antes de proponer nada. Cómo tratamos la información que compartes.