Andy Garcia · dev freelance
FRENES
Retour au blog
Cloud & Fiabilité

Google Cloud Storage a eu 18 heures d'erreurs d'écriture en Iowa. La première mise à jour publique est arrivée 7 heures après

19 octobre 2026 7 min de lecture

Le jeudi 8 octobre 2026, à 04:00 heure du Pacifique, Google Cloud Storage a commencé à renvoyer des erreurs en écriture dans us-central1, sa région de l'Iowa. Pendant 12 heures et 30 minutes, les clients ont vu des erreurs HTTP 503 UNAVAILABLE sur les appels WriteObject, des timeouts côté client, et une latence bien plus élevée sur les écritures qui passaient. Le vendredi 9 octobre, le problème est revenu pendant 5 heures et 41 minutes dans une seule zone, us-central1-b. Le rapport d'incident final de Google, publié le 14 octobre, arrive à 18 heures et 11 minutes au total. Selon le rapport, les autres régions et les autres services Google Cloud n'ont pas été touchés.

La cause, c'est la partie que tout le monde va citer : un changement censé soulager un problème de capacité a créé la panne, et un rollback incomplet a créé la rediffusion. J'ai lu le rapport, l'historique d'incident qui est derrière, et les pages qu'il ne cite pas : le SLA, la documentation des retries, le guide des emplacements.

Ma raison est simple. BidForge, l'outil que j'ai construit pour lire les dossiers d'appels d'offres publics français pour les petites entreprises, part d'un fichier. J'ai donc lu tout ça côté écriture.

Ce qui a cassé, selon Google

Certains nœuds de stockage de us-central1 manquaient de capacité à cause d'un trafic en hausse. Pour y remédier, Google a poussé « a traffic sorting optimization configuration update » sur la couche d'équilibrage de charge de Cloud Storage. Cette mise à jour a « inadvertently » contourné la logique de routage qui tient compte de la capacité. Une petite fraction des nœuds, ceux qui avaient peu de marge, a reçu « an overwhelming proportion of incoming write traffic ». Ils ont manqué de ressources et les services d'ingestion derrière eux ont expiré. Séparément, un problème dans le service de base de données sous-jacent a ajouté des erreurs de métadonnées sur une partie de la fenêtre.

Deux lignes de la section sur les mesures correctives sortent du lot. Les ingénieurs ont d'abord essayé d'ajouter de la capacité d'urgence dans la région, et cela « was blocked by systemic regional capacity limits ». Même Google ne pouvait pas ajouter de la capacité en Iowa à la demande. Et la récurrence du 9 octobre « was caused by an incomplete rollback of an upload planner feature, which broke the load balancing mechanism » une nouvelle fois. Ce qui a fini par tenir, c'est l'annulation complète du changement d'équilibrage de charge.

La liste de prévention de Google résume la leçon : valider les changements d'équilibrage de charge dans de petites régions avant les grandes, et rendre impossible pour le routage de contourner les garde-fous de capacité.

La page de statut avait des heures de retard

Le rapport final dit que les ingénieurs de Google ont détecté le problème à 04:50. La première mise à jour publique de l'historique d'incident est datée de 11:24 PDT, 7 heures et 24 minutes après le début. Elle disait que le problème avait commencé à 05:19, une heure que le rapport préliminaire de Google du 9 octobre a ensuite ramenée à 04:00. Toutes les mises à jour en direct donnaient comme contournement « None at this time ».

Les pages de statut de certains clients ont été plus rapides. À 09:32 PDT, Mixpanel a signalé un retard d'ingestion de données pour les projets US, et deux heures plus tard a désigné Google Cloud comme cause en amont. À 09:42 PDT, Elastic a prévenu que certains projets Elastic Cloud Serverless dans GCP us-central1 pouvaient voir des opérations retardées ou indisponibles, et à 10:21 elle a nommé un problème de stockage cloud, une heure avant le premier message de Google. À 14:53 PDT, Temporal a basculé ses namespaces multi-régions de us-central1 vers leurs régions réplicas par précaution, et n'a signalé aucun impact sur l'exécution des workflows. IncidentHub, qui suit les pages de statut, a compté quatre services en aval qui citaient la panne comme cause : Elastic, Temporal, Mixpanel et Torq.

Le deuxième jour est encore plus maigre. L'historique public ne montre aucune mise à jour entre 13:48 PDT le 8 octobre et le rapport préliminaire de 09:44 PDT le 9 octobre, qui ne couvrait que le 8 octobre. Le billet d'IncidentHub du 12 octobre terminait encore l'incident au 8 octobre. Les 5 heures et 41 minutes de us-central1-b apparaissent pour la première fois dans le rapport final.

Je ne lis pas ça comme Google qui cacherait quelque chose. La page de statut d'un fournisseur rapporte ce que le fournisseur a confirmé, à la vitesse de son processus. L'alerte sur ton propre taux d'erreur est la seule page de statut qui parle au nom de tes utilisateurs.

Les retries par défaut sont courts, quand ils ont lieu

La documentation des retries de Google classe le 503 parmi les erreurs à réessayer. Que ton client réessaie vraiment un upload dépend du langage.

Les insertions d'objets sont « conditionally idempotent » : on peut les réessayer sans risque seulement avec une précondition ifGenerationMatch. Selon cette page, les bibliothèques Node.js, Java et Go ne réessaient ces opérations que si la précondition est posée. La bibliothèque Python réessaie les insertions d'objets par défaut. Et quand elles réessaient, c'est surtout bref. Node.js fait 3 retries par défaut, en commençant à 1 seconde et en doublant : environ 7 secondes d'attente. Java s'arrête à un timeout total de 50 secondes, Python à une échéance de 120 secondes. Go fait exception : pas de limite totale par défaut, sauf 32 secondes par morceau d'un upload resumable à plusieurs requêtes. Le premier épisode a duré 12 heures et demie.

Le correctif pas cher tient en un paramètre. Une précondition generation-match à 0 veut dire que la requête n'avance que si aucun objet vivant ne porte ce nom. Si un upload réessayé a déjà réussi, le retry reçoit un 412 Precondition Failed au lieu d'écrire deux fois. Avec des noms d'objets uniques par upload, tu peux réessayer librement et traiter ce 412 comme « déjà fait ».

Le vrai correctif, c'est d'arrêter de faire attendre l'utilisateur sur le bucket. Accepte le fichier, garde-le quelque part que tu contrôles, réponds « reçu », et laisse une file le pousser vers le stockage avec un backoff aussi longtemps qu'il faut. Un 503 devient alors un retard dans ton pipeline au lieu d'une erreur sur l'écran de quelqu'un.

Le SLA est un crédit, mesuré sur tout ton trafic

Le SLA de Cloud Storage promet 99,9 % de disponibilité mensuelle pour le stockage Standard dans une région, et 99,95 % dans une dual-region ou une multi-region. La disponibilité, c'est 100 % moins le taux d'erreur moyen sur chaque période de cinq minutes du mois, par projet et par région. Le taux d'erreur, c'est les réponses 5xx divisées par toutes les requêtes valides, lectures comprises. Un timeout côté client, l'un des symptômes du rapport, ne renvoie aucune réponse 5xx, donc, d'après ma lecture de la définition, il ne compte pas.

Octobre compte 8 928 périodes de cinq minutes. Les deux fenêtres en couvrent environ 218. Pour passer sous 99,9 %, en supposant un reste du mois propre, ton taux d'erreur pendant ces périodes devait dépasser en moyenne 4,1 %. Pour passer sous 99 %, environ 41 %. Si les écritures représentent 10 % de tes requêtes et qu'un tiers d'entre elles ont échoué pendant les fenêtres, ton taux était d'environ 3,3 % : aucun crédit, parce que les lectures qui ont fonctionné le diluent.

Si tu es éligible, le crédit est de 10 % de la facture du mois pour cette classe de stockage, 25 % de 95 à 99 %, appliqué aux factures futures. Les retries ne comptent que s'ils suivent la règle de back-off du SLA : au moins 1 seconde, croissant de façon exponentielle jusqu'à 32 secondes. Et tu dois prévenir le support Google dans les 30 jours après être devenu éligible, sinon tu perds le crédit.

Une deuxième région est une assurance, avec un trou dans les petites lignes

Le guide des emplacements de Google dit que pour un bucket dual-region comme NAM4, qui associe us-central1 et us-east1, « in the event of a regional outage, requests are automatically failed over to the other region ».

Ça coûte plus cher. La page de tarifs affiche le stockage Standard régional en Iowa à 0,000027397 $ par GiB et par heure, soit environ 0,020 $ par GiB et par mois. Une dual-region est facturée dans les deux régions, 0,022 $ chacune dans l'exemple de la page elle-même (NAM4 est listée à 0,044 $), plus 0,02 $ par GiB répliqué à l'écriture en Amérique du Nord. Pour 500 GiB stockés et 100 GiB de nouvelles données par mois, cela fait environ 10 $ contre environ 24 $.

Ce que le rapport ne dit pas, c'est si les buckets dual-region qui incluent us-central1 ont vu des erreurs. C'était une dégradation, pas une région qui s'éteint, et le guide ne dit pas quand le basculement se déclenche dans ce cas. Avant de payer la deuxième région, je poserais cette question au support et je voudrais la réponse par écrit.

Ce que je vérifierais avant la prochaine

  • Chaque chemin d'écriture et l'emplacement de son bucket : uploads, exports, logs, sauvegardes.
  • Pour chacun, la bibliothèque cliente et sa politique de retry par défaut. ifGenerationMatch=0 sur les uploads en création seule.
  • Une file entre l'utilisateur et le bucket pour tout ce que l'utilisateur ne peut pas renvoyer facilement.
  • Une alerte sur ton propre taux de 5xx, avec les écritures comptées à part des lectures.
  • Si tu étais dans us-central1 les 8 et 9 octobre : ton taux d'erreur sur le mois, et une décision sur la demande de crédit SLA avant la fin des 30 jours.
  • Tes propres rollbacks. Un rollback est un déploiement : écris-le, lance-le d'abord quelque part de petit, et vérifie qu'il est complet. J'orchestre la plupart de mon travail avec Claude Code, et c'est l'étape que je ne laisserais jamais un agent déclarer terminée tout seul. Le deuxième jour de Google est venu d'un rollback qui n'était pas complet.

La ligne la moins chère du rapport est la première action préventive de Google : essayer le changement quelque part de petit avant l'endroit qui compte. Elle vaut pour toutes les équipes, sur n'importe quel cloud, à partir du prochain changement de configuration.

Sources

Un projet du même genre ?

Je conçois et déploie des produits comme celui-ci. Parlons-en.

Discutons