Google Cloud dévoile les détails de l’incident GCVE

 (cloud.google.com)
1 points par GN⁺ 2024-05-26 | 1 commentaires | Partager sur WhatsApp
  • L’incident survenu en mai 2024 chez Google Cloud a entraîné la suppression d’une partie de l’environnement GCVE du client australien UniSuper ; après examen interne, les causes et les mesures de restauration ont été rendues publiques
  • L’impact a été limité à un client, une région, un service, et à l’un des plusieurs GCVE Private Cloud du client ; les autres clients et les autres services Google Cloud n’ont pas été affectés
  • Lors du déploiement initial, une valeur d’entrée d’un outil interne était vide, et le système l’a interprétée comme une durée fixe d’un an ; à l’expiration de cette période, le Private Cloud a été supprimé automatiquement
  • Le client et les équipes Google ont mené une restauration 24x7 pendant plusieurs jours, en s’appuyant sur les sauvegardes présentes dans GCS et sur un logiciel de sauvegarde tiers
  • Google Cloud a pris des mesures pour éviter qu’un incident du même type ne se reproduise : retrait de l’outil interne concerné, vérification manuelle complète de tous les GCVE Private Cloud, et modification du comportement de suppression

Portée de l’incident

  • Cet incident a affecté le client Google Cloud UniSuper, et Google Cloud a finalisé son examen interne après la restauration des systèmes du client
  • L’impact a été limité, du point de vue des services gérés par Google, à :
    • un client
    • une région cloud
    • l’utilisation par le client de Google Cloud VMware Engine (GCVE)
    • un Private Cloud réparti sur deux zones parmi les plusieurs GCVE Private Cloud du client
  • Les éléments non affectés sont également précisés :
    • les autres services Google Cloud
    • les autres clients utilisant GCVE ou d’autres services Google Cloud
    • les autres GCVE Private Cloud du client, ainsi que ses Google Account, Orgs, Folders et Projects
    • les sauvegardes de données dans Google Cloud Storage (GCS) situées dans la même région

Cause : un paramètre vide dans un outil interne

  • Début 2023, un opérateur Google a déployé l’un des GCVE Private Cloud du client à l’aide d’un outil interne afin de répondre à une contrainte spécifique de placement de capacité
  • Cet outil était utilisé dans un processus d’exception pour la gestion de capacité ; il a été retiré et entièrement automatisé au 4e trimestre 2023, ne nécessitant plus d’intervention humaine
  • L’opérateur a suivi les procédures de contrôle interne, mais un paramètre d’entrée est resté vide lors du provisionnement du Private Cloud
  • En raison de ce paramètre vide, le système a attribué à ce champ une valeur par défaut alors inconnue : une durée fixe d’un an
  • À l’expiration de cette période d’un an attribuée par le système, le GCVE Private Cloud du client a été supprimé

Pourquoi le client n’a pas été notifié

  • La suppression ne résultait pas d’une demande du client, mais d’un paramètre vide laissé par un opérateur Google lors de l’utilisation d’un outil interne
  • Si le client avait demandé lui-même la suppression, une notification préalable aurait été envoyée ; dans ce cas, aucune notification client n’a été émise
  • Google Cloud explique avoir corrigé la condition déclenchante de l’incident ainsi que le comportement des sous-systèmes concernés afin d’éviter qu’une telle situation ne se reproduise

Processus de restauration

  • Le client et les équipes Google ont collaboré 24x7 pendant plusieurs jours pour mener la restauration :
    • restauration du GCVE Private Cloud du client
    • restauration des configurations réseau et sécurité
    • restauration des applications
    • récupération des données pour le rétablissement complet des opérations
  • L’approche du client en matière d’architecture robuste et résiliente a contribué à la restauration
  • Les sauvegardes de données stockées dans Google Cloud Storage dans la même région n’ont pas été affectées par la suppression
  • Ces sauvegardes, ainsi qu’un logiciel de sauvegarde tiers, ont joué un rôle clé dans la rapidité de la restauration

Mesures de prévention de récidive

  • Google Cloud a mis en œuvre plusieurs mesures pour empêcher la répétition de l’incident :
    • retrait de l’outil interne à l’origine de la chaîne d’événements
    • même lorsque des besoins spécifiques de gestion de capacité existent, le contrôle passe désormais par l’interface utilisateur côté client, et les éléments concernés sont entièrement automatisés
    • nettoyage de la base de données système et revue manuelle de tous les GCVE Private Cloud afin de vérifier qu’aucun autre déploiement GCVE n’était exposé à un risque similaire
    • modification du comportement système qui, dans ce workflow de déploiement, pouvait définir un GCVE Private Cloud comme cible de suppression
  • Google Cloud estime qu’aucun incident de cette nature ne s’était produit auparavant et qu’il ne s’agit pas d’un problème systémique
  • Google Cloud indique que ses services disposent, selon les besoins, de protections combinant soft delete, notification préalable et human-in-the-loop, et confirme que ces mécanismes restent en place
  • Une collaboration étroite avec le client a été essentielle à la rapidité de la restauration, et une gestion résiliente des risques ainsi que des mécanismes fail-safe sont indispensables pour se remettre rapidement d’incidents imprévus
  • Google Cloud affirme que, malgré cet incident ponctuel, son uptime et sa résilience figurent parmi les meilleurs du secteur cloud selon une validation indépendante

À lire aussi

1 commentaires

 
GN⁺ 2024-05-26
Avis Hacker News

  • Vu l’ampleur de l’impact de cet incident, je suis surpris que les mesures correctives n’aillent pas plus loin. Elles semblent se limiter à empêcher que le même problème se reproduise de la même manière ; si une défaillance équivalente apparaît ailleurs plus tard, le résultat pourrait être similaire, voire pire.
    Par exemple, lors de l’arrêt d’un service, il aurait fallu ne pas supprimer immédiatement les données, mais les conserver quelques jours dans un état récupérable en un clic ; ou auditer les flux de suppression de tous les services afin de prévenir le client avant toute résiliation, quelle qu’en soit la raison ; ou encore ajouter une revue manuelle pour l’arrêt de services actifs au-delà d’une certaine échelle.
    Sans mesures aussi larges, ce post-mortem n’est pas du tout rassurant. Face à un incident aussi absurde, tout fournisseur ayant un minimum de fierté dans son service ou souhaitant préserver sa réputation aurait dû montrer, quitte à en faire trop, que cela ne se reproduira plus jamais. Google Cloud semble n’avoir fait que le minimum.

    • Ne pas supprimer immédiatement les données lors de l’arrêt d’un service relève tellement des bases du logiciel d’entreprise que le fait que Google n’ait pas eu cela en place en 2024 en dit long.
      Même quand j’étais débutant, l’idée de supprimer immédiatement des données dont on n’a plus besoin n’avait aucun sens. Dans les bases de données, on utilisait une suppression logique avec une colonne servant de marqueur de suppression ; pour les données sur disque, on les déplaçait ou on les renommait jusqu’à être vraiment certain qu’elles pouvaient être effacées, tout en conservant malgré tout des sauvegardes. C’était la base.
    • Tout à fait d’accord. On dirait que les responsables GCP tenaient surtout à souligner qu’il n’y avait pas de problème systémique dans la manière dont ils gèrent la plateforme, et c’est précisément ce qui donne fortement l’impression, de façon inquiétante, qu’il y en a un. L’absence de mesures de bon sens dans le post-mortem donne l’impression qu’ils n’ont pas l’intention de corriger le problème.
    • Remplacer les suppressions réelles par un drapeau de suppression pourrait créer un autre bug amusant du genre « Google Cloud n’a pas réussi à supprimer les données client et a violé la réglementation de l’UE ». Google choisira probablement le risque de suppression accidentelle plutôt que celui de non-suppression accidentelle, et c’est plausible au moins dans l’UE.
    • Le fait qu’ils ne fassent pas ça ressemble à une blague. Qu’un grand fournisseur cloud ne prévoie pas de garde-fous autour de la suppression de données n’a aucun sens. En réalité, ils y ont probablement réfléchi plusieurs fois, mais ne l’ont pas implémenté parce que cela coûtait de l’argent.
    • Je ne comprends vraiment pas le « post-mortem » de Google. Toute personne ayant déjà exploité des services en ligne voit non seulement qu’il est manifestement insuffisant, mais aussi que ses conclusions sont empreintes d’arrogance. Le ton est du genre : « c’était un incident isolé, cela ne se reproduira pas, nous sommes vraiment désolés, mais nous sommes excellents et nous continuerons de l’être ». Cela ne rattrape absolument pas le moment où Google Cloud a donné envie de se prendre la tête dans les mains.

  • Si vous êtes client GCP et que vous avez un TAM, vous pouvez le mettre mal à l’aise en lui posant cette question : quelles protections empêchent GCP de supprimer par erreur une grande quantité de ressources de mon compte en cas d’erreur d’administration de leur part ?
    On vous répondra sans doute que ce problème précis a été atténué par l’abandon de l’outil concerné et davantage d’automatisation ; vous pouvez alors enchaîner : « Je sais que ça a été corrigé. Mais y a-t-il une revue humaine avant une suppression à grande échelle ? »
    Pour avoir travaillé chez GCP par le passé et utilisé AWS activement pendant encore plus longtemps, j’ai l’impression que les protections fondées sur l’intervention humaine chez GCP sont quasi inexistantes, et bien moins nombreuses que chez AWS. Dans tous les cas, cela vaut vraiment la peine d’interroger votre TAM sur ce risque réel.

    • Il faut vraiment pousser le sujet. Cela obligera les TAM à apprendre à mieux naviguer dans les systèmes internes. Ils ne pourront pas changer les choses seuls, mais on peut parfois obtenir la promesse d’une voie d’escalade ou un accord informel.
      Si suffisamment de TAM font du bruit, quelqu’un plus haut finira peut-être par bouger.
    • Présenter cela en interne comme une occasion pour un employé de Google de contacter le client et de tenter de faire de la rétention client lorsque des actifs client sont sur le point d’être supprimés passerait sans doute mieux. Effet secondaire : tout le monde saurait clairement que quelque chose va bientôt disparaître.

  • « L’équipe Google a travaillé 24x7 pendant plusieurs jours » : on dirait qu’ils ne savent pas ce que signifie le 7.

    • Ça voulait peut-être dire que 24 ingénieurs ont travaillé 7 heures par jour. Massage et nourriture gratuite préparée par un chef à la cantine inclus.
    • Pris de façon totalement littérale, oui, ça n’a pas beaucoup de sens. Mais x7 signifie évidemment travailler 7 jours sur 7, donc on peut très bien travailler en 24x7 du jeudi après-midi au mardi matin. Cela veut dire qu’ils n’ont pas pris le week-end.
    • Ils ont dû travailler tellement qu’ils ont eu l’impression que quelques jours duraient plusieurs semaines.
    • Si les mesures d’atténuation ont couvert un week-end, cela peut quand même se tenir.
    • Cela peut aussi vouloir dire que les membres de l’équipe se sont relayés pour continuer à travailler sans interruption la nuit ni le week-end. Personnellement, pour ce genre de gros projet, je pense que cela devrait toujours être la norme.

  • Waouh, je m’étais trompé. Je pensais que, dans Terraform ou un outil du genre, la valeur par défaut était une suppression immédiate sans période de récupération, et que quelqu’un chez UniSuper avait mal défini la portée d’une suppression pendant des tests. Cela aurait quand même été un problème de valeur par défaut, mais je pensais que l’erreur venait d’un outil tiers et d’UniSuper.
    Le fait que ce soit en réalité un problème côté Google est dingue. UniSuper a dû se dire : « mais qu’est-ce que c’est que ça ? »

    • L’article explique ce qui s’est passé, et cela n’a rien à voir avec UniSuper. Google a déployé un cloud privé avec un outil interne, et cet outil interne de Google a été configuré pour le supprimer automatiquement un an plus tard.
    • Je suppose que Google leur a accordé un énorme crédit sur leur facture GCP, voire leur a versé une indemnisation séparée.

  • Articles liés : UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, il y a 16 jours, 42 commentaires), Google Cloud accidentally deletes customer's account [1](128 points, il y a 15 jours, 32 commentaires)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • Le fait qu’ils ne se soient pas arrêtés à l’examen d’un outil ou d’une procédure en particulier, mais qu’ils aient aussi vérifié que le reste ne présentait pas de problème de suppression automatique et contrôlé le comportement de suppression réversible, donne l’impression d’un audit assez approfondi.
    Ils auraient pu aller encore plus loin et passer en revue tous les cas de valeurs par défaut pour voir s’il existait des comportements par défaut surprenants. Cela dit, déterminer ce qui est « surprenant » peut être difficile, car ce sont souvent les personnes qui connaissent le moins bien l’outil ou l’API qui conservent les valeurs par défaut.

    • Où est-il dit exactement qu’ils ont « aussi contrôlé le comportement de suppression réversible » ? Il est seulement dit qu’ils ont garanti que ce scénario précis de suppression automatique ne se reproduirait plus, et la raison principale semble être que « le déploiement est désormais automatisé ».
      C’était déjà automatisé avant, et maintenant ça l’est encore davantage ; cela ne rassure en rien sur le fait que le mécanisme de suppression soit systématiquement sûr. Cela signifie seulement qu’il n’y a plus d’opérateur au volant.
    • Ce genre d’incident est une excellente raison de se dire qu’il vaut mieux utiliser AWS ; en interne, ils ont dû avoir une belle frayeur.
      « Le GCVE Private Cloud du client a été supprimé après la fin de la période d’un an attribuée par le système. La suppression a été déclenchée parce qu’un opérateur Google utilisant un outil interne a laissé un paramètre vide ; comme il ne s’agissait pas d’une demande de suppression du client, aucune notification client n’a été envoyée. S’il s’était agi d’une suppression initiée directement par le client, une notification préalable aurait été envoyée. »
      Tada ! Nous sommes assez incompétents pour laisser se produire une suppression massive sans revue humaine. Heureusement, ce client ne nous faisait pas confiance et disposait de sauvegardes hors GCP, donc il n’a pas été totalement fichu.
      « Google Cloud n’avait jamais connu auparavant d’incident de cette nature. Il ne s’agit pas d’un problème systémique. »
      Traduction : « Mon Dieu, les commerciaux d’AWS et d’Azure ont cité notre énorme échec et envoyé trois e-mails à chacun de nos prospects. »

  • Il est difficile de croire que la première cible d’un tel incident ait été un fonds commun de placement de plusieurs milliards de dollars. Je suis content que le problème d’UniSuper ait été résolu, mais il y a probablement eu d’autres cas trop petits pour qu’on y prête attention.
    J’espère simplement que cela donnera à GCP le coup de fouet nécessaire.

    • GCVE, c’est-à-dire du VMware managé, est un service assez obscur. C’est le genre de service qu’utilisent surtout des entreprises pesant plusieurs milliards de dollars qui veulent soulever-déplacer tel quel un ensemble VMware existant vers le cloud.
    • Le point central de cet incident, c’est qu’il existait une configuration personnalisée spéciale que la plupart des clients n’ont pas ou n’utilisent pas, et qu’elle a contourné certains contrôles de sécurité. Elle ne pouvait donc pas affecter de « petits » clients ordinaires.
    • Même un petit client serait allé voir la presse, et la presse en aurait forcément parlé ; il est donc difficile de voir les choses ainsi.
      « Google a supprimé notre service cloud » est une grosse information pour une entreprise de n’importe quelle taille.

  • Il est écrit que « le DSI et l’équipe technique du client méritent des éloges pour avoir travaillé en étroite collaboration avec l’équipe Google Cloud et mené une récupération 24x7 rapide et précise » ; je me demande s’ils n’ont reçu que des compliments dans le billet de blog, ou s’ils ont aussi obtenu une montagne de crédits Google Cloud.

    • Si le client est compétent, il n’y a aucune réalité dans laquelle Google ne paie pas ces coûts. Je ne serais pas surpris qu’ils n’aient tout simplement pas de facture cette année.
    • Il aurait aussi dû y avoir des dommages-intérêts punitifs.

  • Je suis client d’UniSuper en Australie. À l’époque, je ne savais pas ce qui se passait, mais je recevais des e-mails tous les jours pendant qu’ils essayaient de résoudre le problème. J’ai appris par la presse ce qui s’était réellement passé. J’ai eu l’impression qu’ils avaient réduit toute l’affaire à un simple temps d’arrêt système.
    Quand on imagine ce qui aurait pu réellement arriver à l’argent des gens et aux milliards de dollars réunis dans les fonds de retraite, ça donne le vertige.

    • As-tu reçu les mêmes e-mails que les autres ? Il y en avait presque tous les jours, avec plusieurs occurrences de mots comme « disruption », « apologies » et « frustration ».
      Quelques jours plus tard, il y a aussi eu un e-mail intitulé « A letter from the CEO ».
      « Nous souhaitons vous faire le point sur l’interruption de service. »
      « Tout d’abord, je tiens à vous présenter mes excuses personnelles pour cette panne, et à vous remercier de votre patience pendant que nos équipes travaillent jour et nuit pour remettre progressivement nos systèmes en ligne. »
      Dans le contexte, je vois mal comment on pourrait exiger une communication plus claire ou une explication plus précise de ce qui s’était passé en interne chez Google Cloud.

  • La première annonce sur cet incident prêtait pas mal à confusion. On aurait dit que Google avait supprimé par erreur l’intégralité du compte GCP. En lisant ce billet, je suis un peu rassuré. Il semble que ce qui a été perdu se limite à des machines virtuelles à l’échelle d’une région, et ce genre de chose peut effectivement arriver ; je pense que mon système pourrait l’absorber sans gros problème.
    Le texte initial donnait l’impression que tous les buckets GCS, bases de données SQL, etc., de toutes les régions avaient disparu, ce qui serait un problème totalement différent, et j’espère qu’on peut faire confiance à Google pour ne pas faire ce genre de chose.

    • Quand UniSuper a dit que ce n’était pas un compte mais un abonnement qui avait été supprimé, c’était un signal d’alerte. Beaucoup de gens en ont tiré des conclusions hâtives.