Disponibilidad y Recuperación: Cuando tu App se Cae, Qué Salva tu Negocio

Qué significan los "nueves", cómo medir RPO y RTO, y las preguntas que todo dueño de negocio debe poder responder antes de la próxima caída.

Publicado: 28 de mayo de 2026 • 9 min de lectura • Artículo

Centro de datos con servidores redundantes y luces parpadeantes — disponibilidad y recuperación de aplicaciones

Respuesta Rápida:

Disponibilidad es el porcentaje de tiempo que tu aplicación está funcionando; recuperación es la velocidad con la que regresa cuando algo falla. Según el libro Site Reliability Engineering de Google, 99.9% de disponibilidad permite 8.76 horas de caída al año, mientras que 99.99% reduce ese presupuesto a apenas 52.6 minutos anuales. La diferencia cuesta dinero real.

Puntos Clave:

  • El presupuesto de los "nueves": Google SRE documenta que 99% permite 3.65 días de caída anual; 99.9% permite 8.76 horas; 99.99% permite 52.6 minutos; 99.999% permite 5.26 minutos.
  • RPO ≠ RTO: RPO mide cuántos datos puedes perder; RTO mide cuánto tiempo puedes estar fuera. AWS describe escenarios de recuperación con RPO de segundos y RTO de minutos como el extremo más exigente.
  • La definición técnica de HA: Wikipedia define alta disponibilidad como "asegurar un nivel acordado de desempeño operacional, usualmente tiempo de actividad, por un período superior al normal".
  • Redundancia activa vs pasiva: Wikipedia distingue redundancia activa (múltiples componentes con failover automático) de redundancia pasiva (capacidad excedente que absorbe la falla, como un barco con dos motores).
  • Pruebas no disruptivas: AWS recomienda "ejercicios de recuperación y failback no disruptivos" — el plan que nunca se ejercita no es un plan, es un deseo.

Casi todos los dueños de negocio que conocemos —en Houston, Cypress, Monterrey o Bogotá— responden lo mismo cuando preguntamos por su plan de recuperación ante desastres: "el desarrollador lo tiene". Es una respuesta peligrosa, porque cuando la tienda en línea está caída a las 8 de la mañana del Buen Fin o del Black Friday, no es el desarrollador quien pierde ventas. Eres tú.

Este artículo traduce los términos que usan los equipos de infraestructura —disponibilidad, RPO, RTO, redundancia, failover— a decisiones de negocio que tú puedes tomar sin ser ingeniero. No para que aprendas a configurar nada, sino para que sepas qué exigirle a quien sí lo configura.

Qué es realmente "disponibilidad"

La disponibilidad se expresa como un porcentaje del tiempo total que un sistema responde correctamente. Suena simple, pero la diferencia entre 99% y 99.99% no es un detalle estético: es la diferencia entre días y minutos de tiempo fuera de servicio al año.

Según el libro Site Reliability Engineering publicado por Google, los niveles canónicos son:

Tabla de los "nueves" (datos publicados por Google SRE):

  • 99% (dos nueves): 3.65 días de caída al año, 7.2 horas al mes.
  • 99.9% (tres nueves): 8.76 horas al año, 43.2 minutos al mes.
  • 99.99% (cuatro nueves): 52.6 minutos al año, 4.32 minutos al mes.
  • 99.999% (cinco nueves): 5.26 minutos al año, 25.9 segundos al mes.

Wikipedia, en su artículo de "High availability", presenta los mismos órdenes de magnitud con redondeo ligeramente distinto: 99.9% equivale a aproximadamente "9 horas" de caída anual y 99.99% a "53 minutos". Las dos fuentes coinciden en lo importante: cada nueve adicional reduce el presupuesto de caída por un factor de diez.

Lo que esto significa para el dueño de negocio: cuando un proveedor te promete "99.9% de uptime", está prometiendo que tu sitio puede estar caído casi 9 horas al año y seguir cumpliendo el contrato. Si esas 9 horas caen en tu temporada alta, el contrato se cumplió y tú perdiste ventas. Por eso la pregunta correcta no es "¿cuántos nueves prometes?", sino "¿cuándo programan las ventanas de mantenimiento?" y "¿cómo se mide el cumplimiento?".

RPO y RTO: las dos preguntas que importan

Cuando algo falla —y va a fallar— hay dos números que definen el daño: cuánta información pierdes y cuánto tardas en regresar. La industria los llama RPO y RTO.

RPO (Recovery Point Objective) es la cantidad máxima de datos que tu negocio puede perder, medida en tiempo. Si haces respaldos cada 24 horas, tu RPO es 24 horas: en el peor escenario, pierdes un día completo de pedidos, facturas y registros de clientes. Si replicas en tiempo real, tu RPO se mide en segundos.

RTO (Recovery Time Objective) es el tiempo máximo aceptable entre la falla y el momento en que el servicio vuelve a estar operativo. Un RTO de 4 horas significa que tu equipo —o tu proveedor— se compromete a tenerte arriba en 4 horas o menos.

Según la página oficial de AWS Disaster Recovery, los servicios de replicación administrada de Amazon "habilitan RPO de segundos y RTO de minutos" para escenarios de recuperación de instalaciones locales a la nube. Eso no significa que tú necesites ese nivel —significa que existe y se puede comprar si tu modelo de negocio lo justifica.

Ejemplo numérico:

Tienda en línea que factura $20,000 USD al día. Una caída de 4 horas en un día promedio cuesta aproximadamente $3,300 en ventas perdidas; en un viernes de quincena puede triplicarse. Si tu RTO actual es "lo que tarde Carlos en contestar el WhatsApp", tu RTO real probablemente esté más cerca de 8-12 horas que de las 4 que asumes.

Cómo se construye la disponibilidad: redundancia

Disponibilidad alta no se compra con un solo servidor más grande; se construye con redundancia. Wikipedia distingue dos modelos:

Redundancia activa: "usa múltiples componentes con detección automática de fallas y reconfiguración, permitiendo alta disponibilidad sin degradación de desempeño en sistemas complejos". Pensálo como dos servidores corriendo en paralelo: si uno falla, el otro ya está procesando tráfico y el cliente nunca lo nota.

Redundancia pasiva: "acomoda degradación mediante exceso de capacidad — como un barco con dos motores que continúa operando a pesar de la falla de uno solo". El segundo motor existe pero no se usa hasta que el primero falla; hay un momento de transición donde el desempeño baja.

La diferencia importa al cotizar. Redundancia activa cuesta el doble en infraestructura pero entrega failover invisible. Redundancia pasiva cuesta menos pero introduce una ventana de degradación de minutos a horas. La decisión depende de cuánto pierdes por cada minuto fuera —no del orgullo técnico del equipo.

Replicación, failback y pruebas no disruptivas

AWS describe en su página de Disaster Recovery un patrón que se ha vuelto estándar: los datos se replican a "una subred de área de preparación en tu cuenta de AWS" usando "almacenamiento de bajo costo y recursos de cómputo mínimos". En la práctica, esto significa que tu sitio sigue corriendo en su infraestructura principal mientras una copia espera lista, barata, en otra región. Cuando algo falla, esa copia se activa.

Dos detalles de la documentación de AWS importan al dueño de negocio:

  1. Failback: AWS describe la capacidad de "iniciar replicación de datos de regreso a tu sitio primario cuando el problema se resuelve" y "regresar a tu sitio primario cuando estés listo". Recuperación no es solo levantar el respaldo; es regresar al estado original sin perder lo que se procesó durante la falla.
  2. Pruebas no disruptivas: AWS recomienda "realizar pruebas no disruptivas para confirmar que la implementación está completa" y "ejercicios de recuperación y failback no disruptivos". Un plan de recuperación que nunca se ejercita en producción es un documento, no un plan.

Las cinco preguntas que todo dueño debe poder responder

Si tu negocio depende de una aplicación, un sitio o un sistema operando, deberías poder responder estas cinco preguntas sin llamar a nadie:

  • ¿Cuál es nuestro RPO? ¿Cuántos datos podemos perder en el peor escenario? Si la respuesta es "no sé", asume 24 horas.
  • ¿Cuál es nuestro RTO? ¿En cuánto tiempo regresamos? Cuenta desde la falla, no desde que alguien la detecta.
  • ¿Cuándo fue la última prueba de restauración? Un respaldo que nunca se ha restaurado no es un respaldo, es un archivo.
  • ¿Qué pasa si nuestro proveedor principal cae? AWS, GoDaddy y Shopify han tenido caídas regionales. ¿Tienes una respuesta o tienes esperanza?
  • ¿Cuánto cuesta una hora de caída en ventas reales? Este número define cuánto vale la pena invertir en disponibilidad.

El error más caro: optimizar por nueves en vez de por dinero

Equipos técnicos sin contexto de negocio tienden a perseguir nueves como si fueran trofeos. Pero los cinco nueves —que Google SRE documenta en apenas 5.26 minutos de caída al año— cuestan órdenes de magnitud más que los tres nueves. Para la mayoría de negocios medianos, la inversión en pasar de 99.9% a 99.99% no se recupera en ventas adicionales: la gente no abandona una marca porque el sitio estuvo caído 8 horas al año si esas horas fueron de madrugada.

La pregunta de negocio correcta no es "¿cómo llego a 99.999%?". Es "¿cuál es el costo de cada hora de caída y en qué horarios ocurre?". Esa pregunta convierte una conversación técnica abstracta en una decisión financiera concreta.

"Nadie quiebra por no tener cinco nueves. Quiebran por tener cero respaldos probados el día que pasa lo que nunca pasa."
- Diego Medina F, Founder of MerchandisePROS

Qué significa esto para tu negocio

El servicio de Website Consulting de MerchandisePROS combina una auditoría UI/UX con un análisis de velocidad y Core Web Vitals — el primer paso real para entender no solo qué tan rápido es tu sitio, sino qué tan resiliente es cuando falla algo. Documentamos tu RPO y RTO actuales (no los que crees que tienes), revisamos si tu hosting está realmente respaldado, y te entregamos una lista priorizada de los riesgos que pueden tumbar tu operación.

Si nunca has hecho este ejercicio, empieza por la Auditoría Gratis de 60 segundos: te muestra dónde está parado tu sitio hoy frente a competencia y frente a buenas prácticas, incluyendo velocidad de carga (la primera señal pública de problemas de infraestructura). No es un reporte de marketing; es un diagnóstico inicial que puedes llevarle a tu desarrollador o a tu próxima junta de operaciones.

Preguntas Frecuentes

¿Qué significa realmente 99.9% de disponibilidad?

Según el libro Site Reliability Engineering de Google, 99.9% de disponibilidad permite 8.76 horas de caída al año, o aproximadamente 43.2 minutos al mes. No es "casi siempre arriba": es un presupuesto explícito de tiempo fuera de servicio.

¿Cuál es la diferencia entre RPO y RTO?

RPO (Recovery Point Objective) es cuánta información puedes perder, medida en tiempo. RTO (Recovery Time Objective) es cuánto puedes estar fuera de línea. AWS describe escenarios con RPO de segundos y RTO de minutos como el extremo más exigente del espectro.

¿Qué es alta disponibilidad?

Wikipedia define alta disponibilidad como "una característica de un sistema que busca asegurar un nivel acordado de desempeño operacional, usualmente tiempo de actividad, por un período superior al normal". En la práctica, significa diseñar con redundancia para que la falla de un componente no derribe todo el servicio.

¿Cuál es la diferencia entre redundancia activa y pasiva?

Según Wikipedia, la redundancia activa usa múltiples componentes con detección automática de fallas y reconfiguración, manteniendo el desempeño sin degradación. La redundancia pasiva acomoda degradación mediante exceso de capacidad, como un barco con dos motores que sigue operando si uno falla.

¿Necesita mi negocio cinco nueves de disponibilidad?

Casi nunca. Cinco nueves (99.999%) permite solo 5.26 minutos de caída al año según Google SRE y cuesta órdenes de magnitud más que tres nueves. La pregunta correcta no es "cuántos nueves quiero", sino "cuánto me cuesta cada hora de caída en ventas reales".

¿Sabes cuánto te cuesta una hora de caída?

Empieza con una auditoría gratis y descubre dónde está parado tu sitio frente a riesgos de infraestructura, velocidad y experiencia.

Auditoría Gratis Consulta Gratis