Cuando lo planificado se vuelve no planificado

Las ventanas de mantenimiento de infraestructura eléctrica que OVHcloud tiene programadas hasta finales de julio de 2026 incluyen una advertencia explícita en sus propias comunicaciones de estado: los clientes “podrían experimentar un reinicio o apagado temporal en el peor de los casos”. Por otro lado, una campaña de parcheo obligatorio para CVE-2026-53359, una vulnerabilidad del hipervisor KVM conocida como Januscape, requirió reinicios escalonados en decenas de miles de máquinas; la propia guía de OVHcloud indicaba a los clientes que, si las instancias no volvían al finalizar la ventana, intentaran un reinicio manual. Y en un caso documentado de su plataforma Web Cloud, un mantenimiento planificado provocó directamente una interrupción de cinco días que afectó al servicio Softcall. La entrada sobre la causa raíz dice simplemente: “Este incidente fue causado por este mantenimiento”.

Estos no son casos excepcionales. Son la mecánica habitual de operar infraestructura a gran escala, y exponen una brecha que la mayoría de los contratos cloud explotan en silencio.

El impacto de los mantenimientos planificados en el SLA es casi universalmente nulo, porque el mantenimiento programado queda casi universalmente excluido del cálculo del tiempo de inactividad. AWS, Azure, GCP y la mayoría de los proveedores excluyen las ventanas de mantenimiento de sus contadores de SLA siempre que den aviso previo, normalmente entre 24 y 72 horas. Algunos proveedores restringen el mantenimiento a franjas horarias específicas; otros excluyen el tiempo de inactividad planificado por completo. En cualquier caso, el mecanismo es el mismo: un proveedor puede ejecutar una ventana de mantenimiento que cause interrupciones reales para el cliente y seguir cumpliendo íntegramente con el contrato.

Cuando se produce un incumplimiento, la compensación consiste en créditos de servicio, habitualmente del 10 % al 30 % de los cargos del período afectado, sujetos a un plazo de reclamación. No es una compensación proporcional al impacto en el negocio. Una ventana de mantenimiento de cuatro horas que deja tu procesador de pagos fuera de línea un viernes por la noche no te genera ningún crédito si el proveedor avisó con 48 horas de antelación.

La matemática se complica rápidamente en cuanto superas un único servicio. Cinco dependencias con un SLA del 99,9 % cada una producen una disponibilidad compuesta de aproximadamente el 99,5 %, lo que equivale a más de tres horas de tiempo de inactividad acumulado al mes, en lugar de los 43 minutos que implica un SLA del 99,9 % para un único servicio. Si tu objetivo de tiempo de recuperación es de 15 minutos, un SLA del 99,9 % es estructuralmente incompatible con ese objetivo antes incluso de aplicar cualquier exclusión por mantenimiento.

Un proveedor puede ejecutar una ventana de mantenimiento que cause tiempo de inactividad visible para el cliente y seguir cumpliendo plenamente su SLA. El contrato no protege contra el impacto del mantenimiento planificado; la arquitectura sí.

El riesgo de las ventanas de mantenimiento cloud es un problema de arquitectura

El instinto habitual es negociar mejores términos de SLA. Ese es el lever equivocado. El lenguaje del SLA describe cómo un proveedor mide y acredita el tiempo de inactividad; no cambia la realidad física de que el reinicio de un rack, un parche de hipervisor o una actualización de firmware de una tarjeta de red afectarán ocasionalmente a tu carga de trabajo. La única respuesta fiable es que ningún evento de mantenimiento de un único proveedor pueda alcanzar tu tráfico de producción.

Eso requiere tres elementos trabajando en conjunto: distribución de cargas de trabajo entre dominios de fallo independientes, rutas de red que no compartan un upstream común y un mecanismo de failover que no dependa de la expiración del TTL de DNS ni de intervención manual.

Lo que realmente requiere una arquitectura de mantenimiento sin tiempo de inactividad

Dominios de fallo independientes

Las zonas de disponibilidad dentro de la región de un único proveedor no son dominios de fallo independientes a efectos de mantenimiento. Una campaña de parcheo KVM a nivel de proveedor, un mantenimiento de infraestructura eléctrica que afecte a múltiples racks o una actualización del plano de control toca todas las zonas simultáneamente. La independencia real implica proveedores separados, instalaciones físicas distintas o ambas cosas. Para cargas de trabajo europeas, esto significa distribuir entre sitios geográficamente separados sin ningún plano de gestión compartido.

BGP multihoming como base de red

El BGP multihoming conecta tu infraestructura a múltiples proveedores upstream y anuncia tu propio prefijo IP, normalmente un bloque IPv4 /24 o IPv6 /48 independiente del proveedor, a través de tu propio Número de Sistema Autónomo. Cuando una ruta se degrada o un evento de mantenimiento del proveedor retira una ruta, BGP elimina el camino afectado y el tráfico se desplaza automáticamente al upstream superviviente. Sin cambios manuales, sin esperar a que expire el TTL de DNS.

Combinar BGP con Bidirectional Forwarding Detection (BFD) refina aún más este mecanismo. BFD ejecuta heartbeats a nivel de milisegundos en el plano de reenvío y señala a BGP que cierre sesiones inmediatamente ante un fallo, logrando una reconvergencia en menos de un segundo en redes bien ajustadas. La diferencia entre un temporizador de holddown de BGP de 30 segundos y un failover activado por BFD en menos de un segundo es la diferencia entre una interrupción perceptible y una transparente.

Operamos BGP multihoming en 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en cada sitio. Esa densidad de peering significa que el tráfico destinado a una carga de trabajo en un hyperscaler durante un evento de failover no recorre rutas de tránsito público impredecibles; sale por una interconexión conocida y de baja latencia independientemente del sitio que esté absorbiendo la carga.

Validación mediante prueba de concepto antes de necesitarla

Una arquitectura de mantenimiento sin tiempo de inactividad vale tanto como la última vez que alguien la probó. El marco de prueba de concepto para validar la resiliencia cloud durante actualizaciones es sencillo en principio y sistemáticamente omitido en la práctica.

  1. Simula el evento de mantenimiento: desconecta deliberadamente un sitio o una ruta upstream durante una ventana de prueba planificada y confirma que el tráfico se desplaza limpiamente y que tu monitorización detecta la transición.
  2. Mide la recuperación real, no el RTO teórico: registra el tiempo desde la retirada de la ruta hasta la restauración completa del tráfico. Compáralo con tu RTO declarado. Si no coinciden, la arquitectura necesita ajustes, no el documento de RTO.
  3. Valida en la capa de aplicación: la medición del SLA ocurre normalmente en la capa de infraestructura. Tus clientes experimentan la capa de aplicación. Confirma que un failover de BGP no se manifiesta como una caída de sesión, una transacción fallida o un cache miss que se convierte en una sobrecarga de base de datos.
  4. Prueba el desfase en la notificación de mantenimiento: los proveedores avisan con entre 24 y 72 horas de antelación. Realiza un simulacro en el que tu equipo reciba un aviso de mantenimiento simulado y ejecute el procedimiento de failover dentro de esa ventana. El procedimiento debe estar documentado, ensayado y no depender de personas concretas.

Lo que la situación de OVH realmente te dice

La secuencia de mantenimientos de OVHcloud de julio de 2026 no es evidencia de que OVHcloud sea inusualmente poco fiable. StatusGator ha registrado más de 2.685 interrupciones que afectan a usuarios de OVHcloud a lo largo de más de cinco años de monitorización, lo cual es coherente con operar infraestructura a escala. El detalle más instructivo es la campaña de parcheo de Januscape: una vulnerabilidad de seguridad que requería remediación urgente en decenas de miles de máquinas, con una ventana de mantenimiento que no podía aplazarse y que conllevaba un riesgo explícito de reinicios. Ese escenario, un mantenimiento forzado por seguridad con amplio impacto, puede ocurrirle a cualquier proveedor. La pregunta es si tu arquitectura lo absorbe o lo hereda.

El tiempo de inactividad por mantenimiento del proveedor cloud no es un problema de calidad del proveedor que puedas resolver mediante el contrato. Es un problema de sistemas distribuidos que se resuelve con rutas redundantes, dominios de fallo independientes y un mecanismo de failover que hayas probado de verdad. El SLA te dice qué crédito recibes a posteriori. La arquitectura determina si hay algo que acreditar.