¿Por qué la nube no garantiza 24/7? Entendiendo los límites de la alta disponibilidad

En el día a día de TI, “moverlo a la nube” se ha convertido casi en un conjuro mágico: lo migras, le pones un logo de un proveedor famoso y, de repente, todo el mundo asume que ya es 24/7 y “problema resuelto”. En mi experiencia, eso es una receta perfecta para decepciones, incidentes y postmortems con cara larga.

La realidad es bastante menos romántica: la nube no es una varita mágica de disponibilidad, es un conjunto de herramientas y un modelo de responsabilidades compartidas. El proveedor pone redundancia, automatización y escala… y tú pones arquitectura, operación y decisiones de riesgo. Entre ambos se construye —o se destruye— ese 24/7 que luego alguien promete alegremente en una presentación comercial.

En este artículo te voy a contar, sin marketing ni humo, por qué la nube no garantiza 24/7, qué significan de verdad esos famosos “nueves” del SLA, qué limita la alta disponibilidad en la práctica y qué arquitecturas y procesos necesitas para acercarte a ese ideal… sin autoengañarte.

El mito de “moverlo a la nube” y ya es 24/7

La nube como caja de herramientas, no como varita mágica

Cuando alguien dice “ya está en la nube”, muchas veces lo que tiene es una aplicación levantada en una sola máquina virtual, en una sola zona de disponibilidad, con una sola base de datos y cambios hechos a mano desde consola. Eso no es 24/7; es el mismo esquema on-prem, solo que con otra factura.

Yo suelo explicarlo así: la nube te da bloques con muy buena disponibilidad, pero lo que construyes encima puede tirar todo por la borda. Puedes montar una arquitectura robusta, multi-AZ, con replicación de datos y automatización… o puedes poner el core de tu negocio en una única instancia “porque funciona” y “ya veremos luego”.

Además, la alta disponibilidad no “viene de fábrica”. No hay un botón mágico de “Habilitar 24/7” que actives en el panel. Lo que sí hay son servicios y patrones: balanceadores de carga, grupos de autoescalado, zonas de disponibilidad, colas, almacenamiento distribuido, replicación, etc. Tu trabajo es combinarlos de forma sensata según lo que tu negocio realmente necesita.

Responsabilidades compartidas: qué pone el proveedor y qué pones tú

El modelo de responsabilidades compartidas suele explicarse desde la seguridad, pero aplica igual a la disponibilidad:

• El proveedor de nube se encarga de:

  • Redundancia de infraestructura física (servidores, energía, enfriamiento).

  • Capacidad de escalar y reemplazar nodos enfermos automáticamente.

  • Alta disponibilidad de ciertos servicios gestionados (bases de datos, colas, almacenamiento).

  • Mantenimiento del plano de control y de la red interna.

• Tú, como cliente, te encargas de:

  • Diseñar la arquitectura sin puntos únicos de fallo.

  • Definir cómo se replica y se protege tu estado (datos, sesiones, config).

  • Establecer procesos de despliegue, cambios y rollbacks razonables.

  • Monitorear, reaccionar a incidentes y entrenar a tu equipo para operarlo.
    

He visto equipos con el mismo proveedor y los mismos servicios, donde uno pasa años sin incidentes serios y otro tiene caídas cada mes. La diferencia no es “la nube”, sino las decisiones que se toman sobre cómo usarla.

Qué dice realmente el SLA de tu proveedor cloud

Los “nueves” de disponibilidad explicados en cristiano

Ningún proveedor serio promete 100 % de disponibilidad. Lo que ves en los contratos son números tipo 99.5 %, 99.9 %, 99.95 % o 99.99 %. Suena a “casi siempre”, pero conviene traducirlo a tiempo de caída permitido:

• 99.0 % de disponibilidad:

  • Hasta ~3.65 días de caída al año.

• 99.5 %:

  • Hasta ~1.8 días al año.

• 99.9 %:

  • Hasta unas 8–9 horas al año.

• 99.99 %:

  • Hasta unas decenas de minutos al año.

• 99.999 %:

  • Minutos al año, pero ya hablamos de arquitecturas muy específicas y muy caras.
    

Y ojo: esos números suelen ser por servicio o por instancia dentro de una región. Tu sistema final está compuesto por muchos eslabones (cómputo, base de datos, colas, cachés, DNS, identidad, terceros…), y la disponibilidad global tiende a ser peor que la de cada pieza aislada, sobre todo si no hay redundancia.

Cuando le explico esto a negocio, suelo decir: “Con 99.9 % el proveedor básicamente te está diciendo: ‘Se vale que algo no funcione alrededor de un turno de trabajo completo al año’”. No suena tan mágico, ¿verdad?

Lo que el SLA sí cubre, lo que no… y qué pasa cuando se incumple

Un SLA en la nube es, sobre todo, un compromiso comercial. Suele incluir cosas como:

• Cómo se mide la disponibilidad (por mes, por región, por proyecto).

• Qué condiciones deben cumplirse para que un fallo cuente como indisponibilidad.

• Durante cuánto tiempo debe durar el problema para que se contabilice.

• Qué servicio se considera “degradado” y qué se considera “caído”.
  

También viene con una lista generosa de exclusiones: tareas de mantenimiento programado, desastres externos, ataques DDoS masivos, mala configuración del cliente, incidentes de seguridad que no son culpa del proveedor, etc. Todo eso no suele contar para el cálculo de SLA.

¿Qué pasa cuando el proveedor incumple el SLA? Normalmente:

1. Tú abres un caso y aportas evidencias del impacto.

2. El proveedor revisa logs, métricas y ventanas de tiempo.

3. Si acepta el incumplimiento, aplica un crédito en tu factura del mes.
   

Listo. No hay más. Nadie te va a pagar las ventas que perdiste, las penalizaciones con tus propios clientes ni las horas extras del equipo apagando incendios.

Créditos en la factura vs impacto real en el negocio

Aquí es donde muchas organizaciones se dan de bruces con la realidad. El SLA sirve para:

• Cuantificar el riesgo que asumes con ese proveedor.

• Comparar alternativas a un nivel objetivo.

• Tener algo de palanca comercial si las cosas van mal.
  

Lo que no hace es proteger tu negocio del impacto real de una caída. En una ocasión, acompañé a un equipo después de un incidente serio: el proveedor les dio un crédito generoso en la factura… y aun así el coste en reputación, ventas perdidas y estrés del equipo fue brutal.

Depender del SLA como si fuera un seguro de disponibilidad es, en el mejor de los casos, ingenuo. El SLA es un dato de entrada; la resiliencia se construye con diseño y operación.

Lo que de verdad limita la alta disponibilidad en la nube

Puntos únicos de fallo típicos (VM, base de datos, AZ, DNS, terceros)

Cuando revisas incidentes reales en cloud, la historia se repite:

• Una sola VM atendiendo todo el tráfico.

• Una sola base de datos primaria, sin réplicas.

• Recursos concentrados en una sola zona de disponibilidad.

• Un único proveedor de DNS para dominios críticos.

• Un servicio externo (pasarela de pago, identidad, correo transaccional) sin alternativa.
  

En esos casos, el proveedor de nube puede estar cumpliendo impecablemente su SLA… y aun así tu servicio se cae. ¿Por qué? Porque tu arquitectura tiene una cadena donde basta que se rompa un eslabón para tirar todo el sistema.

En mi experiencia, los diseños con un solo punto de fallo son la causa más aburrida y repetida de no tener 24/7, y el problema no es la nube, sino nuestras decisiones.

Complejidad, estado y dependencias externas

Luego está el tema de la complejidad mal manejada:

• Microservicios por todas partes, cada uno con sus propias versiones, colas y dependencias.

• Sesiones pegadas a un servidor concreto porque “era más fácil así”.

• Bases de datos que no reproducen bien réplicas distribuidas.

• Bloqueos fuertes que no toleran latencia entre zonas o regiones.
  

Añádele a eso dependencias externas críticas (proveedores de identidad, terceros de pago, APIs externas “imprescindibles”) y tienes una receta perfecta para que la disponibilidad se caiga por algo que no está ni siquiera en tu nube.

La nube expone herramientas para desacoplar, escalar y aislar fallos, pero no te obliga a usarlas. Puedes seguir montando un castillo de naipes distribuido; solo que ahora, cuando cae, está más lejos de tu datacenter.

Operación manual, error humano y cultura de cambios

Incluso con una arquitectura decente, la disponibilidad tropieza con un enemigo clásico: la operación diaria.

Cambios directamente en consola, sin automatización, sin pruebas, sin revisiones. Scripts peligrosos ejecutados en producción “solo esta vez”. Credenciales mal gestionadas. Alertas que se ignoran porque “siempre suenan”.

Diversos análisis coinciden en que el error humano sigue siendo una de las principales causas de indisponibilidad, muy por encima de los fallos de hardware. Y la nube no arregla eso; si acaso, lo amplifica, porque ahora puedes romper cosas a escala con un solo clic.

Por eso, cuando hablamos de 24/7 realista, no basta con arquitectura. Hay que hablar de procesos de cambio, de cómo revisas código y configs, de cómo haces despliegues y de qué cultura tienes para aprender de los incidentes sin cazar brujas.

Alta disponibilidad vs recuperación ante desastres (y por qué necesitas ambas)

Fallos “normales” vs desastres: ejemplos concretos

Se mezclan todo el tiempo, pero no son lo mismo:

• Alta disponibilidad (HA) lidia con fallos “normales”:

  • Se cae una instancia de aplicación.

  • Falla una AZ concreta.

  • Una actualización sale mal en un servicio.

• Recuperación ante desastres (DR) mira escenarios catastróficos:

  • Pierdes toda una región de nube.

  • Corrupción masiva de datos.

  • Ataque de ransomware serio.

  • Borrado accidental de entornos enteros.
    

En HA quieres que el usuario casi ni se entere de que algo ha fallado: el sistema reacciona, hace failover, escala, redirige tráfico. En DR aceptas que habrá impacto, pero defines cuánto tiempo te puedes permitir estar abajo (RTO) y cuántos datos estás dispuesto a perder (RPO).

RTO, RPO y cómo aterrizarlos con negocio

Estos dos parámetros son la base de una conversación honesta sobre disponibilidad:

• RTO (Recovery Time Objective): cuánto tiempo estás dispuesto a que el servicio esté caído.

• RPO (Recovery Point Objective): cuántos datos puedes darte el lujo de perder (en minutos u horas de transacciones).
  

La clave es que RTO y RPO no se definen en una sala de arquitectos, sino con negocio, riesgos y finanzas. Si para una línea de negocio una hora de caída significa un desastre, el diseño y el presupuesto tendrán que reflejarlo. Si, en cambio, puedes permitirte cuatro horas, tal vez no necesitas multi-región activo–activo y toda la complejidad que conlleva.

Yo suelo plantearlo así en reuniones: “No hablamos de si queremos o no 24/7. Hablamos de cuánto cuesta una hora caída y cuánto estamos dispuestos a invertir para que eso pase lo menos posible”.

Por qué una app puede ser altamente disponible… y aun así quedarse sin servicio

Una aplicación puede estar muy bien diseñada dentro de una región, con multi-AZ, réplicas de base de datos y failover automático… y aun así quedarse sin servicio si esa región entera tiene un problema y no hay un plan de DR.

Lo mismo pasa cuando la arquitectura interna está cuidada, pero:

• No hay backups probados ni procedimientos claros de restauración.

• No existe un plan para mover tráfico a otra región o proveedor.

• Hay dependencias externas sin plan B (DNS, identidad, pagos).
  

En resumen: la alta disponibilidad te protege de baches en el camino. La recuperación ante desastres te protege cuando el camino desaparece. Para acercarte a un 24/7 razonable, necesitas ambas cosas, no solo un SLA bonito.

Patrones de arquitectura para tolerar fallos en cloud

Multi-AZ como punto de partida

En entornos cloud, el mínimo razonable para cargas críticas suele ser multi-AZ dentro de una región:

• Varias instancias de aplicación distribuidas en dos o más zonas.

• Un balanceador de carga repartiendo tráfico entre ellas.

• Bases de datos con réplicas en múltiples zonas y conmutación automática de primario.

• Colas y servicios gestionados configurados para sobrevivir al fallo de una zona.
  

La idea básica es asumir que un datacenter puede tener un problema local (energía, red, enfriamiento) y que tu servicio debe seguir vivo. No es ciencia ficción; es el tipo de fallo que los proveedores planifican por defecto.

Cuando reviso arquitecturas, si algo crítico está solo en una AZ, lo marco mentalmente como “pendiente de madurar”.

Multi-región: activo–pasivo vs activo–activo

Subir un nivel más implica ir a multi-región. Aquí hay dos patrones típicos:

• Activo–pasivo:

  • Una región principal atiende todo el tráfico.

  • Una o más regiones secundarias se mantienen sincronizadas (en mayor o menor medida).

  • El failover puede ser manual (botón rojo en un incidente) o automático (DNS, routing global).
    

• Activo–activo:

  • Varias regiones atienden tráfico en paralelo.

  • Cada una puede soportar el 100 % de la carga si la otra cae.

  • Necesitas 2N de capacidad, sincronización de datos muy cuidada y diseño que tolere latencias mayores y escrituras concurrentes.
    

El beneficio es claro: si una región entera sufre un problema gordo, tienes otra lista para seguir sirviendo. El coste también: más infraestructura, más complejidad, más cosas que entender y operar. Por eso, activo–activo global tiene sentido para ciertos perfiles (financiero, e-commerce masivo, SaaS crítico), pero no para todo el mundo.

Multicloud: cuándo aporta resiliencia y cuándo solo añade complejidad

Ir todavía más allá es plantearse multicloud para disponibilidad: operar en dos o más proveedores con idea de no depender totalmente de uno solo.

Los patrones son parecidos:

• Activo–pasivo entre nubes, usando otra nube como plan de DR.

• Activo–activo multicloud, repartiendo carga entre proveedores.

Sobre el papel suena súper resiliente; en la práctica implica:

• Diferencias de servicios y APIs entre nubes.

• Modelos de seguridad y redes distintos.

• Observabilidad más compleja.

• Necesidad de talento con experiencia en varios proveedores.
  

En mi experiencia, multicloud puede mejorar tu disponibilidad y tu posición de negociación, pero no “regala” 24/7. Si no tienes una operación ya madura en una sola nube, añadir más proveedores suele multiplicar problemas, no nines.

Zonas de disponibilidad, mantenimiento y otros matices incómodos

Qué problemas resuelven (y cuáles no) las zonas de disponibilidad

Las zonas de disponibilidad (AZ) dividen una región en dominios de fallo independientes: datacenters separados físicamente, con energía y enfriamiento propios, conectados con redes de baja latencia.

Desplegar en varias AZ te ayuda a:

• Aislar fallos físicos o de infraestructura local.

• Permitir mantenimiento por zona sin tirar todo el servicio.

• Preparar el terreno para escalado y migraciones internas.

Pero no resuelve todo. Hay servicios que, por diseño, no son multi-AZ. Hay dependencias comunes a nivel de región. Y si tú concentras tu base de datos, tus colas y tu almacenamiento crítico en una sola AZ, darle multi-AZ solo a las instancias web es puro autoengaño.

Mantenimiento del proveedor: reinicios, parches y ventanas programadas

La infraestructura cloud vive en actualización constante: parches de hipervisores, cambios en el plano de control, actualizaciones de almacenamiento, redes, firmware…

Parte de ese mantenimiento es transparente. Otra parte implica:

• Reinicios de instancias.

• Migraciones en vivo.

• Indisponibilidad temporal de algunas APIs.
  

Muchos SLAs excluyen explícitamente las ventanas de mantenimiento programado del cómputo de indisponibilidad, siempre que el proveedor te notifique con cierta anticipación. Eso significa que puedes tener impactos reales en tus aplicaciones sin que “cuenten” contra el SLA.

Cuando diseño para alta disponibilidad, siempre asumo que habrá reinicios y microcortes por mantenimiento, y que mi arquitectura tiene que aguantarlo sin que nadie entre corriendo al chat de emergencia.

Tu propio mantenimiento: despliegues, cambios de esquema y actualizaciones

Luego está tu mantenimiento, que es todavía más peligroso:

• Despliegues de nuevas versiones de la aplicación.

• Cambios de esquema en base de datos.

• Actualizaciones de librerías y runtimes.
  

Si no se plantean como rolling, blue/green o con algún patrón que permita rollback rápido, terminarán generando downtime voluntario. Es decir: indisponibilidad completamente causada por tu propia operativa.

La ironía es que muchas de las caídas que la gente atribuye “a la nube” en realidad vienen de un deploy mal hecho un viernes por la tarde.

El costo real de perseguir el 24/7

Cómo traducir “nueves” en horas de caída y dinero

Cada “nueve” extra de disponibilidad suele costar de forma no lineal:

• Pasar de 99 % a 99.9 % puede significar duplicar componentes y automatizar procesos de failover.

• Subir a 99.99 % y más allá implica multi-AZ, pruebas constantes, equipos operativos maduros e incluso multi-región.
  

La pregunta clave no es “¿Cuántos nueves quiero?”, sino:

• ¿Cuánto daño hace al negocio una hora de caída?

• ¿Cuánto estamos dispuestos a invertir para reducir ese daño?

Si una hora caída te cuesta, por ejemplo, 10 000 €, puedes hacer números claros: qué arquitectura necesitas para reducir la probabilidad de que eso ocurra y cuánto costará en infraestructura y equipo.

En mi experiencia, muchas discusiones técnicas sobre 24/7 se desbloquean cuando finanzas ve, en números, que perseguir un nueve extra puede salir más caro que asumir cierto riesgo controlado.

Cuándo tiene sentido pagar por activo–activo

La redundancia activo–activo es muy atractiva sobre el papel: varias zonas o regiones atendiendo tráfico al mismo tiempo, cero downtime en teoría, mayor aprovechamiento de recursos.

Pero solo tiene sentido cuando:

• El impacto de una caída es realmente crítico.

• Tu aplicación puede tolerar latencia y escrituras concurrentes.

• Tu equipo puede operar un sistema distribuido complejo sin vivir en modo incendio.
  

En otros casos, un buen esquema activo–pasivo, bien probado y con simulacros periódicos, suele ser más sensato y mucho más barato.

Negociando con finanzas y riesgos un nivel de servicio realista

Una de las partes menos glamourosas de la disponibilidad es sentarse con finanzas y riesgos a aterrizarla. Mi enfoque habitual es:

• Definir, con negocio, qué procesos de verdad necesitan alta disponibilidad.

• Calcular el coste de una hora de caída para esos procesos (ingresos, penalizaciones, reputación).

• Proponer niveles de disponibilidad con su coste asociado (infraestructura + equipo).

• Acordar un nivel de riesgo aceptable y documentarlo.
  

El objetivo no es prometer 24/7 a todo lo que se mueva, sino tener un catálogo claro: qué es crítico, qué es importante y qué podría incluso pararse sin drama durante unas horas. Eso hace maravillas por la honestidad y la transparencia en TI.

Monitoreo, operación y cultura de resiliencia

Por qué sin observabilidad no existen el 24/7 ni los SLO serios

Hablar de 24/7 sin monitoreo serio es un autoengaño. No puedes asegurar la disponibilidad de algo que no sabes cómo se comporta.

Las prácticas actuales se apoyan en:

• Métricas técnicas: latencia, tasa de errores, saturación de recursos.

• Métricas de negocio: transacciones por minuto, conversiones, usuarios activos.

• Logs centralizados: para entender qué pasó cuando algo falla.

• Trazas distribuidas: para seguir una petición a través de múltiples servicios.

• Monitoreo sintético: robots que simulan usuarios reales desde varias regiones.
  

Con todo eso defines SLIs (indicadores de nivel de servicio) y SLOs (objetivos internos), que son mucho más útiles que un SLA genérico del proveedor. Si tus alertas solo miran “CPU alta” o “disco lleno”, tu visión de disponibilidad es demasiado pobre para aspirar a 24/7.

Automatización, simulacros y postmortems sin caza de brujas

La resiliencia no se prueba con presentaciones, se prueba rompiendo cosas de forma controlada:

• Automatización: que los cambios, despliegues y rollbacks no dependan de clicks manuales.

• Simulacros: ensayar fallos de AZ, de base de datos, de región; probar DR de verdad.

• Chaos testing (aunque sea básico): apagar instancias y ver qué pasa.

• Postmortems sin caza de brujas: analizar incidentes para mejorar procesos y diseño, no para buscar culpables.
  

En mi experiencia, el cambio cultural de dejar de esconder incidentes y empezar a verlos como inversión de aprendizaje hace más por el 24/7 que cualquier feature nueva del proveedor.

Checklist rápido para evaluar tu madurez de alta disponibilidad

Si quieres una autoevaluación honesta, pregúntate:

• ¿Tus cargas críticas corren, como mínimo, en varias AZ?

• ¿Tienes identificado qué es crítico, qué es importante y qué es secundario?

• ¿Existe un plan de DR documentado y probado al menos una vez al año?

• ¿Sabes tu RTO y RPO para cada servicio importante?

• ¿Puedes restaurar backups… y lo has hecho recientemente?

• ¿Tienes monitoreo sintético y SLOs definidos para tus servicios clave?

• ¿La mayoría de los cambios pasan por un pipeline automatizado?
  

Si varias respuestas son “no” o “no sé”, tu problema no es el proveedor de nube; es tu madurez operativa.

Conclusión: aceptar que el 100 % no existe y diseñar en consecuencia

4 pasos prácticos para acercarte al 24/7 sin autoengañarte

La mejor estrategia para lograr disponibilidad 24/7 es aceptar, paradójicamente, que el 100 % no existe. A partir de ahí, puedes diseñar de forma consciente hasta qué punto quieres —y puedes pagar— acercarte a él.

Un camino razonable suele ser:

1. Definir qué significa 24/7 para tu negocio

   Qué procesos, qué usuarios, qué ventanas de mantenimiento son aceptables, qué RTO/RPO son razonables.
   

2. Diseñar la arquitectura en función de esos objetivos

   Multi-AZ como base, multi-región donde haga falta, multicloud solo si de verdad lo justifica el riesgo.
   

3. Invertir en operación y cultura, no solo en infraestructura

   Observabilidad, automatización, simulacros, postmortems, gestión de cambios, formación del equipo.
   

4. Revisar periódicamente el equilibrio entre coste y riesgo

   Cada “nueve” extra debe tener una justificación clara en términos de pérdidas evitadas.

La nube te da los ladrillos para construir sistemas extremadamente resilientes, pero no regala la arquitectura ni la disciplina para operarlos. Ese trabajo sigue siendo tuyo.

Preguntas frecuentes sobre 24/7 y alta disponibilidad en la nube

¿Por qué mi proveedor de nube no me garantiza 100 % de disponibilidad? Porque técnicamente es imposible asegurar que nunca habrá caídas, y legalmente sería un suicidio. En lugar de 100 %, te ofrecen SLAs con “nueves” y créditos en la factura si se incumplen.

¿Un SLA del 99.99 % significa que nunca se va a caer? No. Significa que, en promedio, el servicio debería estar disponible casi todo el tiempo, con unas decenas de minutos de caída al año. Además, suele aplicarse a un componente concreto, no a todo tu sistema.

¿Alta disponibilidad es lo mismo que recuperación ante desastres? No. La HA lidia con fallos “normales” y busca que el servicio casi no se interrumpa. La DR asume desastres mayores y define cuánto tardas en volver a estar arriba (RTO) y cuántos datos puedes perder (RPO).

¿Realmente necesito multiregión o multicloud para tener 24/7?

Depende del impacto de una caída. Para muchos casos, multi-AZ dentro de una región bien diseñada y operada es suficiente. Multi-región y multicloud tienen sentido cuando el coste de una caída es realmente alto.

¿Qué hago si el proveedor cloud incumple el SLA? Abrir el caso, documentar el incidente y solicitar los créditos correspondientes. Pero no esperes que eso compense las pérdidas de negocio: tu estrategia de disponibilidad no puede descansar en el SLA.

¿Por qué, si todo está en la nube, mi sistema igual se cae? Porque la nube no elimina puntos únicos de fallo, ni errores de diseño, ni problemas de operación. Solo te da mejores herramientas para gestionarlos. El resultado final depende de cómo las uses.

La nube no garantiza un 24/7