Andy Garcia · dev freelance
FRENES
Volver al blog
Nube y Fiabilidad

Google Cloud Storage tuvo 18 horas de errores de escritura en Iowa. La primera actualización pública llegó 7 horas después

19 de octubre de 2026 7 min de lectura

El jueves 8 de octubre de 2026, a las 04:00 hora del Pacífico, Google Cloud Storage empezó a devolver errores en las escrituras en us-central1, su región de Iowa. Durante 12 horas y 30 minutos, los clientes vieron errores HTTP 503 UNAVAILABLE en las llamadas WriteObject, timeouts del lado del cliente y una latencia mucho más alta en las escrituras que sí pasaban. El viernes 9 de octubre volvió durante 5 horas y 41 minutos en una sola zona, us-central1-b. El informe final de incidente de Google, publicado el 14 de octubre, llega a un total de 18 horas y 11 minutos. Según el informe, las demás regiones y los demás servicios de Google Cloud no se vieron afectados.

La causa es la parte que todo el mundo va a citar: un cambio pensado para aliviar un problema de capacidad creó la caída, y un rollback incompleto creó la repetición. Leí el informe, el historial de incidentes que hay detrás y las páginas que no enlaza: el SLA, la documentación de reintentos, la guía de ubicaciones.

Mi motivo es simple. BidForge, la herramienta que construí para leer los expedientes de licitaciones públicas francesas para pequeñas empresas, empieza por un archivo. Así que leí todo esto desde el lado de la escritura.

Qué se rompió, según Google

Algunos nodos de almacenamiento de us-central1 andaban cortos de capacidad por un aumento del tráfico. Para resolverlo, Google desplegó "a traffic sorting optimization configuration update" en la capa de balanceo de carga de Cloud Storage. La actualización "inadvertently" se saltó la lógica de enrutamiento que tiene en cuenta la capacidad. Una pequeña fracción de nodos, los que tenían poco margen, recibió "an overwhelming proportion of incoming write traffic". Se quedaron sin recursos y los servicios de ingesta que había detrás agotaron el tiempo de espera. Por separado, un problema en el servicio de base de datos subyacente añadió errores de metadatos durante parte de la ventana.

Dos líneas de la sección de remediación destacan. Los ingenieros intentaron primero añadir capacidad de emergencia a la región, y eso "was blocked by systemic regional capacity limits". Ni siquiera Google podía añadir capacidad en Iowa bajo demanda. Y la repetición del 9 de octubre "was caused by an incomplete rollback of an upload planner feature, which broke the load balancing mechanism" otra vez. Lo que por fin aguantó fue revertir por completo el cambio de balanceo de carga.

La lista de prevención de Google es la lección resumida: validar los cambios de balanceo de carga en regiones pequeñas antes que en las grandes, y hacer imposible que el enrutamiento se salte las salvaguardas de capacidad.

La página de estado fue horas por detrás

El informe final dice que los ingenieros de Google detectaron el problema a las 04:50. La primera actualización pública del historial de incidentes lleva la marca de las 11:24 PDT, 7 horas y 24 minutos después del inicio. Decía que el problema había empezado a las 05:19, una hora que el informe preliminar de Google del 9 de octubre movió a las 04:00. Todas las actualizaciones en vivo daban como solución alternativa "None at this time".

Las páginas de estado de algunos clientes fueron más rápidas. A las 09:32 PDT, Mixpanel informó de un retraso en la ingesta de datos para proyectos de EE. UU., y dos horas después señaló a Google Cloud como causa aguas arriba. A las 09:42 PDT, Elastic avisó de que algunos proyectos de Elastic Cloud Serverless en GCP us-central1 podían ver operaciones retrasadas o no disponibles, y a las 10:21 nombró un problema de almacenamiento en la nube, una hora antes de la primera publicación de Google. A las 14:53 PDT, Temporal conmutó por precaución sus namespaces multirregión de us-central1 a sus regiones réplica, y no informó de impacto en la ejecución de workflows. IncidentHub, que sigue las páginas de estado, contó cuatro servicios aguas abajo que citaban la caída como causa: Elastic, Temporal, Mixpanel y Torq.

El segundo día es todavía más escaso. El historial público no muestra ninguna actualización entre las 13:48 PDT del 8 de octubre y el informe preliminar de las 09:44 PDT del 9 de octubre, que cubría solo el 8 de octubre. El artículo de IncidentHub del 12 de octubre aún cerraba el incidente el 8 de octubre. Las 5 horas y 41 minutos de us-central1-b aparecen por primera vez en el informe final.

No lo leo como Google escondiendo algo. La página de estado de un proveedor informa de lo que el proveedor ha confirmado, a la velocidad de su proceso. La alerta sobre tu propia tasa de errores es la única página de estado que habla por tus usuarios.

Los reintentos por defecto son cortos, cuando los hay

La documentación de reintentos de Google clasifica el 503 como reintentable. Que tu cliente reintente de verdad una subida depende del lenguaje.

Las inserciones de objetos son "conditionally idempotent": solo es seguro reintentarlas con una precondición ifGenerationMatch. Según esa página, las bibliotecas de Node.js, Java y Go reintentan estas operaciones solo si la precondición está puesta. La biblioteca de Python reintenta las inserciones de objetos por defecto. Y cuando reintentan, es sobre todo brevemente. Node.js hace 3 reintentos por defecto, empezando en 1 segundo y duplicando: unos 7 segundos de espera. Java se detiene en un timeout total de 50 segundos, Python en un plazo de 120 segundos. Go es la excepción: sin límite total por defecto, salvo 32 segundos por fragmento de una subida reanudable de varias peticiones. El primer episodio duró 12 horas y media.

La solución barata es un parámetro. Una precondición generation-match de 0 significa que la petición avanza solo si ningún objeto vivo tiene ese nombre. Si una subida reintentada ya tuvo éxito, el reintento recibe un 412 Precondition Failed en lugar de escribir dos veces. Con nombres de objeto únicos por subida, puedes reintentar con libertad y tratar ese 412 como "ya hecho".

La solución de verdad es dejar de hacer esperar al usuario por el bucket. Acepta el archivo, guárdalo en un sitio que controles, responde "recibido" y deja que una cola lo empuje al almacenamiento con backoff durante el tiempo que haga falta. Un 503 pasa a ser un retraso en tu pipeline en lugar de un error en la pantalla de alguien.

El SLA es un crédito, medido sobre todo tu tráfico

El SLA de Cloud Storage promete 99,9 % de disponibilidad mensual para el almacenamiento Standard en una región, y 99,95 % en una dual-region o multi-region. La disponibilidad es el 100 % menos la tasa de errores media en cada periodo de cinco minutos del mes, por proyecto y por región. La tasa de errores son las respuestas 5xx divididas entre todas las peticiones válidas, lecturas incluidas. Un timeout del lado del cliente, uno de los síntomas del informe, no devuelve ninguna respuesta 5xx, así que, según mi lectura de la definición, no cuenta.

Octubre tiene 8.928 periodos de cinco minutos. Las dos ventanas cubren unos 218. Para caer por debajo del 99,9 %, suponiendo que el resto del mes esté limpio, tu tasa de errores durante esos periodos tenía que superar de media el 4,1 %. Para caer por debajo del 99 %, un 41 % aproximadamente. Si las escrituras son el 10 % de tus peticiones y una tercera parte falló durante las ventanas, tu tasa fue de un 3,3 % aproximadamente: ningún crédito, porque las lecturas que funcionaron la diluyen.

Si cumples los requisitos, el crédito es del 10 % de la factura del mes para esa clase de almacenamiento, del 25 % entre el 95 y el 99 %, aplicado a facturas futuras. Los reintentos solo cuentan si siguen la regla de back-off del SLA: al menos 1 segundo, creciendo de forma exponencial hasta 32 segundos. Y debes avisar al soporte de Google en los 30 días siguientes a ser elegible, o pierdes el crédito.

Una segunda región es un seguro, con un hueco en la letra pequeña

La guía de ubicaciones de Google dice que para un bucket dual-region como NAM4, que combina us-central1 con us-east1, "in the event of a regional outage, requests are automatically failed over to the other region".

Cuesta más. La página de precios lista el almacenamiento Standard regional en Iowa a 0,000027397 $ por GiB y hora, unos 0,020 $ por GiB y mes. Una dual-region se factura en las dos regiones, 0,022 $ cada una en el ejemplo de la propia página (NAM4 aparece listada a 0,044 $), más 0,02 $ por GiB replicado en la escritura en Norteamérica. Para 500 GiB almacenados y 100 GiB de datos nuevos al mes, son unos 10 $ frente a unos 24 $.

Lo que el informe no dice es si los buckets dual-region que incluyen us-central1 vieron errores. Fue una degradación, no una región que se apaga, y la guía no dice cuándo se activa la conmutación en ese caso. Antes de pagar la segunda región, le haría esa pregunta al soporte y querría la respuesta por escrito.

Lo que comprobaría antes de la próxima

  • Cada ruta de escritura y la ubicación de su bucket: subidas, exportaciones, logs, copias de seguridad.
  • Para cada una, la biblioteca cliente y su política de reintentos por defecto. ifGenerationMatch=0 en las subidas que solo crean.
  • Una cola entre el usuario y el bucket para todo lo que el usuario no pueda reenviar fácilmente.
  • Una alerta sobre tu propia tasa de 5xx, con las escrituras contadas aparte de las lecturas.
  • Si estabas en us-central1 el 8 y el 9 de octubre: tu tasa de errores del mes y una decisión sobre la reclamación del SLA antes de que pasen los 30 días.
  • Tus propios rollbacks. Un rollback es un despliegue: escríbelo, ejecútalo primero en algún sitio pequeño y comprueba que está completo. Orquesto la mayor parte de mi trabajo con Claude Code, y es el paso que nunca dejaría que un agente dé por terminado por su cuenta. El segundo día de Google vino de un rollback que no estaba completo.

La línea más barata del informe es la primera acción preventiva de Google: probar el cambio en algún sitio pequeño antes que en el lugar que importa. Vale para todos los equipos, en cualquier nube, empezando por el próximo cambio de configuración.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos