La verdadera pregunta no es qué proveedor tuvo una interrupción. La pregunta es si su empresa podría seguir operando cuando ocurra una contingencia.
Durante la jornada del 25 de julio de 2026, Huawei Cloud publicó un aviso oficial informando una anomalía en una cuenta internacional de su plataforma, situación que podía ralentizar el acceso a servicios de la región mientras sus equipos trabajaban en su resolución. El comunicado constituye una referencia concreta de una realidad que afecta a toda la industria tecnológica: ningún proveedor, por grande o reconocido que sea, está completamente libre de incidentes.
Más que utilizar este episodio para cuestionar a una marca, conviene transformarlo en una oportunidad de análisis. La continuidad operacional no depende únicamente del nombre del proveedor cloud; depende, principalmente, de la arquitectura que la empresa cliente haya diseñado antes de que ocurra una falla.
La nube no elimina el riesgo
Migrar sistemas a una plataforma cloud puede mejorar la flexibilidad, la escalabilidad y la administración de la infraestructura. Sin embargo, trasladar una aplicación a la nube no significa que la organización obtenga automáticamente alta disponibilidad. Ese es el peor error que cometen los que contratan estos servicios.
Todavía pueden producirse fallas de comunicaciones, errores humanos, problemas de autenticación, configuraciones incorrectas, indisponibilidad regional, ataques informáticos o interrupciones de servicios compartidos. Por esa razón, una arquitectura seria no se diseña suponiendo que todo funcionará siempre, sino anticipando qué ocurrirá cuando algún componente deje de responder.
Alta disponibilidad no significa solamente tener dos servidores
Uno de los errores más frecuentes consiste en asociar alta disponibilidad con la simple existencia de una segunda máquina virtual. La redundancia de servidores es importante, pero no resuelve por sí sola la continuidad del servicio. Lo que puede ayudarte, son los siguientes tips:
- Múltiples centros de datos o zonas de disponibilidad realmente independientes.
- Replicación de información con parámetros de consistencia definidos.
- Almacenamiento redundante y respaldos fuera de la plataforma principal.
- Balanceo de carga y mecanismos de conmutación por error.
- Monitoreo permanente, alertas y escalamiento técnico.
- Procedimientos documentados de recuperación.
- Pruebas semanales o mensuales de Disaster Recovery.
- Personal especializado disponible para responder durante una contingencia.
La alta disponibilidad no es una etiqueta comercial ni una característica automática del proveedor. Es una arquitectura que debe diseñarse, implementarse, supervisarse y probarse.
Te podría interesar:
Incluso otro centro de datos puede no ser suficiente
Una empresa puede distribuir servidores en dos centros de datos y, aun así, mantener puntos únicos de falla. Esto ocurre cuando ambos sitios dependen del mismo sistema de autenticación, del mismo proveedor de comunicaciones, de una única consola de administración, de la misma cuenta cloud o de un mecanismo de respaldo que nunca ha sido probado.
Por eso, la resiliencia no se obtiene únicamente separando físicamente los equipos. También exige independencia lógica, operacional y administrativa. La estrategia debe considerar qué componentes comparten ambos sitios y qué sucedería si uno de esos componentes comunes dejara de estar disponible.
El error más costoso: confiar sin probar
Muchas organizaciones poseen respaldos manuales y contratos con niveles de servicio. El problema aparece cuando descubren, durante una emergencia, que el respaldo estaba incompleto, que la restauración demora más de lo esperado o que las personas responsables no conocen el procedimiento.
Un plan de continuidad no puede considerarse efectivo hasta que haya sido probado. Las pruebas de recuperación permiten medir tiempos reales, identificar dependencias ocultas y corregir fallas antes de que afecten a la operación.
Diez preguntas que toda empresa debería responder
- ¿Cuál es el tiempo máximo que el negocio puede permanecer detenido?
- ¿Cuánta información puede perderse sin producir un daño operacional relevante?
- ¿Los respaldos están almacenados fuera del proveedor o sitio principal?
- ¿Cuándo fue la última restauración completa realizada con éxito?
- ¿Las aplicaciones críticas pueden operar desde otro centro de datos?
- ¿Existen puntos únicos de falla en comunicaciones, autenticación o almacenamiento?
- ¿El plan de continuidad está documentado y asigna responsables?
- ¿La infraestructura es monitoreada las 24 horas?
- ¿Quién responde durante una contingencia fuera del horario laboral?
- ¿La empresa ha ejecutado una prueba formal de recuperación ante desastres?
RTO y RPO: dos conceptos que no deberían quedar implícitos
El objetivo de tiempo de recuperación (RTO) define cuánto puede tardar la organización en restablecer un servicio. El objetivo de punto de recuperación (RPO) establece cuánta información puede perderse, medida en tiempo, después de una interrupción.
Estos valores deben ser acordados con las áreas responsables del negocio. Una aplicación que factura, controla inventario o sostiene la atención de clientes no necesariamente puede compartir los mismos objetivos que un sistema secundario. Sin esta definición, la empresa puede terminar contratando una solución insuficiente o sobredimensionada.
La diferencia se demuestra durante la contingencia
El valor de un proveedor tecnológico no se mide solamente cuando todo funciona correctamente. Se mide cuando ocurre una incidencia y deben activarse los procedimientos, la arquitectura, los respaldos y el equipo humano.
Después de más de 17 años administrando infraestructura tecnológica para empresas chilenas, en Tecnoinver hemos comprobado que la continuidad operacional exige planificación, pruebas y una visión integral de la plataforma. No basta con disponer de capacidad de cómputo; es necesario comprender cómo funciona el negocio del cliente, cuáles son sus dependencias críticas y qué nivel de interrupción puede tolerar.
| “Las interrupciones pueden ocurrir. La improvisación, en cambio, es completamente evitable.” |
Conclusión
La reciente incidencia informada por Huawei Cloud no debería conducir a una discusión simplista sobre qué proveedor es mejor. Debería impulsar a las organizaciones a revisar si su infraestructura puede continuar operando cuando una plataforma, una región, una cuenta o un componente crítico deja de estar disponible.
Una estrategia de continuidad bien diseñada puede incluir alta disponibilidad entre centros de datos, respaldos externos, replicación, monitoreo permanente, procedimientos de recuperación y pruebas periódicas. La combinación dependerá de la criticidad de cada sistema y de las necesidades reales del negocio.
La pregunta definitiva no es si algún proveedor fallará. La pregunta es si su empresa estará preparada cuando eso ocurra.
Evaluación de Continuidad Operacional
| Tecnoinver pone a disposición una evaluación inicial de continuidad operacional para identificar riesgos, puntos únicos de falla y oportunidades de mejora, independientemente del proveedor cloud utilizado actualmente. · Revisión de la arquitectura actual y sus dependencias críticas. · Identificación de puntos únicos de falla. · Revisión de respaldos y capacidad de restauración. · Análisis de alternativas de alta disponibilidad y Disaster Recovery. · Recomendaciones priorizadas para reducir el riesgo de indisponibilidad.
|
Fuente del incidente
Huawei Cloud, “Notice on Abnormal Huawei Cloud Account on July 26, 2026 (Beijing Time)”. Consultar comunicado oficial
Nota editorial: el comunicado oficial informa una anomalía que podía ralentizar el acceso. No se atribuye en este borrador una duración total ni un alcance superior al expresamente confirmado por Huawei Cloud.
