Cuando falla la nube, también falla la vida cotidiana

La infraestructura que solo vemos cuando falla

Una aplicación puede estar en tu teléfono y depender de una instalación que nunca has visto.

La computación en la nube permite contratar capacidad informática, almacenamiento y servicios gestionados. Esa comodidad deja en segundo plano una pregunta importante: qué sigue funcionando cuando falla una de sus dependencias.

El incidente de Londres ofrece un caso para examinarla. Conviene empezar por separar lo documentado de las consecuencias que todavía no podemos atribuir con suficiente respaldo.

Qué confirma el registro de Google

Google registró el incidente entre las 06:08 y las 14:00 UTC del 20 de octubre de 2026, una duración de 7 horas y 52 minutos. Son las 08:08 y las 16:00 en Madrid. El proveedor describió una incidencia eléctrica, indisponibilidad en la zona europe-west2-b y errores en algunos servicios de la región londinense europe-west2 [1].

La última actualización visible, a las 14:03 UTC, hablaba de mitigación para la mayoría y de un número muy reducido de clientes todavía afectados. El cierre del registro no acredita que todos los clientes hubieran recuperado cada operación. Google anunció un análisis posterior a su investigación interna, que no aparece en la página consultada [1].

No describimos una caída total de toda la región. Tampoco enumeramos bancos o servicios públicos afectados, porque sus consecuencias concretas no han quedado corroboradas en las fuentes recuperables de este cierre.

Servicios distintos pueden compartir una misma dependencia

Imaginemos una tienda, una empresa de transporte y una aplicación de pagos. Son ejemplos hipotéticos. Sus clientes podrían considerarlas alternativas independientes y, sin embargo, las tres podrían depender de un mismo componente informático.

Ahí aparece el riesgo de concentración. Diversificar actividades comerciales no asegura diversificar la infraestructura que las sostiene. La pregunta es dónde coinciden las dependencias y qué ocurre si una deja de responder.

Esto no permite concluir que toda concentración sea perjudicial. Compartir una plataforma también puede reducir costes y facilitar capacidades que una organización pequeña no podría mantener por sí sola. El análisis exige comparar esas ventajas con las consecuencias de una interrupción.

Tener varias máquinas no resuelve por sí solo la continuidad

La guía de Google distingue fallos de recursos, zonas y regiones. Recomienda evitar dependencias sin alternativa y distribuir componentes según el nivel de protección buscado. Un punto único de fallo puede interrumpir una función esencial. Una aplicación puede seguir siendo vulnerable si conserva una dependencia esencial en un único lugar [2].

La resiliencia operativa es la capacidad de mantener o recuperar funciones esenciales ante una interrupción. La redundancia consiste en disponer de recursos alternativos. Para valorar su utilidad hay que preguntar cómo se activan, qué datos necesitan y cuánto tarda la recuperación. La guía explica opciones de diseño, no demuestra qué arquitectura tenía cada cliente del incidente.

Como criterio de análisis, proponemos medir la continuidad desde la operación que necesita completar una persona. En un ejemplo hipotético, poder abrir una aplicación pero no terminar un pago dejaría sin resolver su función esencial. Contar servidores encendidos no respondería por completo a esa pregunta.

Por qué también interesa a los reguladores

La FCA anunció el 10 de julio que, desde el día 13, supervisaría junto al Banco de Inglaterra y la PRA a los primeros cuatro proveedores críticos designados por el Tesoro: AWS, Google Cloud, Microsoft y Oracle. El comunicado explica el riesgo de que una interrupción compartida alcance a varias entidades o mercados. El régimen complementa las responsabilidades de las entidades financieras sobre sus propios proveedores [3].

Esa supervisión aporta contexto. No demuestra que este incidente constituya un incumplimiento ni permite repartir responsabilidades sin conocer la investigación y las configuraciones implicadas.

Cuatro preguntas antes de dar por resuelto el riesgo

¿Qué operación debe mantenerse? Una empresa necesita definir qué resulta esencial para sus usuarios y qué interrupción puede soportar. La respuesta no tiene por qué ser igual para todos sus servicios.

¿Se ha probado la alternativa? Tener un plan escrito y conseguir que funcione durante un fallo son resultados distintos. Nuestra propuesta es pedir evidencias de recuperación y conocer sus límites.

¿Qué dependencia sigue siendo común? Dos entornos pueden compartir componentes. Conviene examinar cuáles son, en lugar de deducir independencia únicamente del número de servidores o contratos.

¿Es proporcionado el coste? La continuidad exige recursos y trabajo. La decisión económica consiste en compararlos con el daño que provocaría una interrupción, sin suponer que toda redundancia adicional aporta el mismo valor.

Una necesidad tecnológica no garantiza una inversión rentable

Una línea de análisis posible son las soluciones de recuperación, seguimiento del funcionamiento y gestión de incidentes. Su interés requiere investigación, sin suponer que este episodio haya generado contratos o beneficios nuevos.

Una necesidad puede ser real y resultar difícil de monetizar. Para valorar a una empresa harían falta datos sobre demanda, costes, competencia y caja. La existencia de un problema importante no garantiza que cualquier proveedor que prometa resolverlo vaya a crear valor.

Qué podría cambiar nuestra lectura

El informe técnico podría modificar la interpretación del desencadenante y de la recuperación. Las arquitecturas de los clientes permitirían distinguir mejor las dependencias compartidas de las decisiones individuales de diseño.

Si aparecieran evidencias de que las alternativas funcionaron y limitaron el daño, también habría que incorporarlas. Un incidente aislado no demuestra que los fallos de la nube sean cada vez más frecuentes. Esa afirmación necesitaría una comparación histórica homogénea.