Résumé

  • Google Cloud attribue l’incident de service d’us-west1 du 20 août à une maintenance optique planifiée qui a créé une congestion inattendue à The Dalles, en Oregon. La fiche officielle répertorie 27 produits concernés.
  • Le fournisseur a conseillé un basculement vers d’autres régions lorsque cela était possible. Cette consigne supposait que données, routage, identités et pouvoir de décision soient déjà opérationnels ailleurs.

Le risque d’une maintenance ne se résume pas à savoir si les travaux sont annoncés. Il tient à la marge de capacité qui reste exploitable pendant l’intervention. Dans us-west1, Google affirme que cette marge est devenue insuffisante lorsqu’une maintenance optique a entraîné une congestion imprévue.

La fiche fait commencer l’incident à 15 h 40 UTC le 20 août. Le premier message public est horodaté 16 h 44 min 37 s, soit plus d’une heure après ce début, et signale délais d’attente, dégradations, erreurs et latence accrue sur plusieurs produits. À 17 h 13 min 59 s puis 17 h 32 min 15 s, Google recommande aux clients de basculer vers d’autres régions si leur architecture le permet.

Le dernier message indique que le problème sous-jacent avait été atténué à 17 h 22 UTC après rétablissement de capacité. Cette explication n’a été publiée qu’à 19 h 37 min 40 s. Entre-temps, Google avait déclaré les mesures d’atténuation terminées alors que certains produits poursuivaient leur reprise. La fiche d’incident se clôt à 19 h 20.

Ces repères ne sont pas interchangeables. 15 h 40 est le début enregistré, 17 h 22 l’heure rétrospective d’atténuation donnée par Google, 19 h 20 la clôture de la fiche et 19 h 37 min 40 s le moment de l’explication finale. Aucun ne suffit à dater le retour à la normale d’une application particulière.

L’incident est de sévérité élevée, avec l’impact SERVICE_OUTAGE, et mentionne 27 produits. La liste traverse calcul, stockage, bases de données, traitement de données, construction logicielle, supervision, identité et messagerie. Compute Engine, GKE, Cloud Run, Cloud Storage, Cloud SQL, BigQuery, Pub/Sub, Cloud Monitoring, IAM et Persistent Disk y figurent notamment.

Cette étendue révèle une dépendance régionale partagée, pas 27 interruptions totales identiques. Google ne fournit ni taux d’impact par produit, ni nombre de requêtes en échec, ni dénominateur de clients ou de projets, ni ventilation par zone ou distribution de latence.

Les premiers messages associaient aussi le marqueur de localisation Global à l’Oregon. Le récit situe pourtant les symptômes clients dans us-west1. Ce marqueur peut relever de la portée d’un produit ou du classement de la page d’état et ne prouve pas une panne mondiale de Google Cloud.

La documentation d’architecture de Google explique que les services cloud partagent des fonctions telles que réseau, accès aux centres de données et autorisation d’identité. La réplication interrégionale et le basculement dépendent eux aussi du réseau physique. Restaurer la capacité optique peut donc lever une contrainte commune sans remettre instantanément chaque service géré en état.

« Basculer si possible » décrit une capacité à préparer, non un bouton universel. Une région secondaire doit déjà exister, disposer de données assez récentes pour l’objectif de point de reprise et accepter le trafic. Les identifiants, files d’attente, politiques DNS ou d’équilibrage, dépendances externes et droits de décision doivent fonctionner sous pression.

Les recommandations de fiabilité de Google demandent de tester basculement régional, retour arrière et restauration de données, puis de vérifier le transfert de trafic et les répliques. Un schéma d’architecture ou un environnement de secours inutilisé ne démontre pas le respect de l’objectif de temps de reprise.

Le dossier public ne nomme ni circuit optique, ni opérateur, ni topologie, ni capacité retirée, ni seuil de congestion, ni geste exact de maintenance. Il n’établit pas de perte de données, de rupture de fibre, d’événement de sécurité ou d’échec du secours d’un client nommé. Google annonce une analyse ultérieure, absente de la fiche capturée.

La conclusion défendable est précise : selon Google, la maintenance a réduit la capacité réseau utilisable jusqu’à provoquer une congestion régionale, puis la reprise s’est propagée à travers un large ensemble de services. Capacité du fournisseur, santé de chaque produit et état de l’application cliente restent trois mesures distinctes.

Sources