Índice de contenidos
Claves de la noticia
- Google ha cerrado la incidencia de Londres tras 7 horas y 52 minutos, aunque su último aviso conserva afectados residuales.
- El fallo eléctrico se localiza en europe-west2-b; no acredita una caída de todas las regiones europeas.
- La distribución de servidores y la de sus discos deben revisarse por separado al evaluar la tolerancia a fallos.
La incidencia de Google Cloud del 20 de octubre deja una distinción importante para quienes alojan servicios en Londres: cerrar el incidente general no equivale a certificar la recuperación de cada cliente. El registro oficial permite reconstruir los tiempos; la documentación técnica ayuda a entender qué protecciones dependen de la configuración contratada.
Un cierre con trabajo pendiente
Google atribuye el problema a un evento eléctrico y promete publicar su investigación. A las 16:03 de Madrid comunicó una mitigación para la mayoría y pidió a los clientes todavía afectados que abrieran un caso con soporte. El anuncio de recuperación de la mayoría se refería a las 14:10. Todas estas horas corresponden al 20 de octubre y se han convertido desde el horario PDT del registro del incidente.
| Hito | Hora Madrid |
|---|---|
| Inicio registrado | 08:08 |
| Recuperación de la mayoría | 14:10 |
| Fin registrado | 16:00 |
La resta entre los dos últimos hitos arroja 110 minutos entre la recuperación mayoritaria y el cierre registrado. Es una medida del intervalo entre estados comunicados, no del tiempo de indisponibilidad de una aplicación individual. El balance final debe conservar esa diferencia.
Una zona no equivale a toda Europa
En la geografía de Compute Engine, una región agrupa varias zonas. La región de Londres se identifica como europe-west2; el sufijo «-b» designa una de sus zonas. Madrid figura como europe-southwest1. Compartir proveedor no convierte ambos emplazamientos en una misma infraestructura regional.
Por eso, para una empresa española, la pregunta útil es dónde están sus recursos y sus dependencias. Una tienda dirigida a clientes de España puede alojarse en Londres; otra puede usar Madrid y depender de una aplicación externa situada allí. La ubicación del usuario no permite deducir por sí sola la ubicación del fallo.
Tampoco basta leer una lista de productos para conocer la experiencia de todos sus clientes. Un servicio con recursos repartidos puede comportarse de manera diferente a otro concentrado. Sin registros de cada despliegue, atribuir una interrupción concreta exige más que la coincidencia temporal con un aviso del proveedor.
GKE puede repartir el control y concentrar los datos
La documentación de los clústeres regionales de GKE muestra una diferencia que puede pasar inadvertida en una revisión rápida: el plano de control y los nodos se distribuyen entre zonas de una región, pero los discos persistentes zonales siguen siendo recursos de una zona. El almacenamiento merece su propia comprobación.
Un ejemplo ayuda a concretarlo. Si una aplicación tiene capacidad de ejecución en varias zonas, pero necesita un volumen que solo está disponible en una de ellas, disponer de otros servidores no resuelve automáticamente el acceso a ese volumen. Es una consecuencia de combinar ambos alcances documentados, no un diagnóstico sobre los clientes afectados hoy.
La etiqueta «regional» del clúster no demuestra que todos sus datos sean regionales. La conclusión surge al contrastar la distribución de cómputo con el apartado de almacenamiento de la misma documentación. Una revisión de continuidad debe inventariar ambos, además de comprobar dónde puede arrancar realmente cada carga.
Cloud Run añade otra frontera
El caso de Cloud Run ilustra una decisión distinta. Su guía para servir tráfico desde varias regiones exige desplegar el servicio en ellas y configurar el balanceo global. La posibilidad existe, pero disponer de un servicio en una región no acredita que se haya preparado ese despliegue adicional.
Para comparar diseños conviene separar dos preguntas: si la aplicación puede sobrevivir a la pérdida de una zona y si puede operar cuando falta una región. Son objetivos diferentes. La respuesta de GKE sobre sus nodos y discos no se puede trasladar sin más al despliegue de Cloud Run ni a la base de datos que use la aplicación.
Duplicar el componente que recibe las peticiones tampoco basta si ambos destinos dependen del mismo almacenamiento indisponible. Antes de presentar un segundo despliegue como respaldo, hay que demostrar que puede completar la operación del usuario: consultar datos, escribir el resultado y devolver una respuesta coherente. Esta es una comprobación del diseño completo, no del nombre comercial de cada pieza.
Medir la recuperación de la aplicación
La guía de recuperación ante desastres de Google distingue el objetivo de tiempo de recuperación, RTO, del punto de recuperación de los datos, RPO. Recuperar disponibilidad y conservar las últimas escrituras son compromisos distintos. Una prueba útil debe registrar cuánto tarda el servicio en volver y hasta qué operación confirmada conserva.
Esta revisión complementa otros controles operativos. En la gestión de claves externas de Microsoft, por ejemplo, la disponibilidad de las claves introduce otra dependencia para recuperar los datos. No es la causa de este incidente, pero muestra por qué el inventario de recuperación debe abarcar más que las máquinas.
El resultado que una organización necesita conservar tras una prueba es concreto: qué dependencia detuvo su aplicación, qué alternativa funcionó y qué operaciones requieren reconciliación. Un panel público describe el estado general del proveedor. La continuidad efectiva se demuestra con una operación completa de la aplicación y sus datos.
Imagen: ilustración conceptual generada con IA para Tecnología Today; no representa instalaciones reales de Google ni el lugar del incidente.
