Google Cloud Storage sufrió 12,5 horas de errores de escritura en us-central1

Google Cloud Storage experimentó el 8 de octubre una degradación prolongada de las operaciones de escritura en la región us-central1. Según la página de estado, el incidente comenzó alrededor de las 04:00 US/Pacific y se dio por cerrado a las 16:30 del mismo día, con una duración aproximada de 12 horas y 30 minutos. Los clientes observaron latencias elevadas y errores HTTP 503 UNAVAILABLE principalmente en WriteObject, junto con timeouts del lado del cliente. Una fracción menor de lecturas también se vio afectada.

La causa preliminar publicada por Google apunta a un shortfall de capacidad localizado en nodos de almacenamiento backend de la región. Un cambio de optimización de enrutamiento de tráfico, pensado para aliviar restricciones de capacidad, provocó agotamiento de recursos en determinados nodos. Eso llevó a timeouts en los servicios de ingestión de objetos y, en cascada, a problemas en el servicio de metadatos. Una vez estabilizado el tráfico, los nodos drenados se reincorporaron y el servicio se normalizó.

-InfraCrew dice: La optimización que iba a aliviar la capacidad acabó agotándola. El diagrama de “mejora continua” también necesita un plan de rollback.-

Alcance y servicios afectados

El impacto se concentró en la región us-central1 (Iowa). Cualquier carga de trabajo que escribiera en buckets de esa región —backups, pipelines de datos, subidas de usuarios o sincronizaciones de objetos— pudo experimentar fallos o reintentos durante la ventana. Google no ofreció un workaround de cliente mientras el incidente estuvo abierto. El informe preliminar de incidente se publicó el 9 de octubre y anuncia un informe final con acciones preventivas una vez concluida la investigación.

No se reportó pérdida de datos. El servicio de lectura se vio menos afectado que el de escritura, lo que limitó el impacto en aplicaciones que solo consultaban objetos ya almacenados. Aun así, cualquier proceso que dependiera de escrituras consistentes en us-central1 tuvo que absorber reintentos o fallos temporales.

Qué implica para operaciones

Para equipos que usan GCS como destino de backup o como capa de staging de pipelines, el incidente recuerda que una región puede degradarse durante horas sin que el resto de la plataforma se vea afectada. Las estrategias habituales —reintentos con backoff, escritura en múltiples regiones cuando el RPO lo permite, o monitoreo activo de la página de estado— vuelven a ser relevantes. Google ha indicado que tomará medidas para evitar que un shortfall localizado vuelva a propagarse de la misma forma.

-InfraCrew dice: Doce horas y media de 503 en escrituras. El RPO de “unas pocas horas” se acaba de volver más concreto.-

Estado actual

El incidente está resuelto. La página de estado muestra la ventana cerrada y no hay degradación activa relacionada. Los clientes que observaron errores durante esas horas pueden consultar el informe preliminar para correlacionar sus propios logs. No se espera un postmortem público inmediato más allá del informe final que Google ha prometido.

Diccionario de la Crew

RPO — Recovery Point Objective: cantidad máxima de datos que una organización acepta perder, expresada normalmente como intervalo de tiempo.
GCS — Google Cloud Storage: servicio de almacenamiento de objetos de Google Cloud.

Fuentes

Google Cloud Status | https://status.cloud.google.com/incidents/mSFVt6PiP557bjRyYsut