La perte de disque de Google Cloud en Belgique montre où la localité cesse d'être une résilience

Résumé

• En août 2015, les disques persistants standard de Google Compute Engine dans la zone europe-west1-b ont connu des erreurs de lecture après quatre coups de foudre successifs ayant affecté le réseau électrique local alimentant un centre de données européen. Google a ensuite signalé qu'une très petite fraction de l'espace de disque persistant alloué dans la zone a subi des écritures récentes irrécupérables.
• La question de responsabilité n'est pas de savoir si le pourcentage était élevé. Il s'agit de savoir si les clients comprenaient qu'un disque persistant zonal, même avec une redondance gérée par le fournisseur dans la zone, restait dans un domaine de défaillance physique et ne remplaçait pas les instantanés indépendants, la réplication régionale ou la sauvegarde au niveau applicatif.
• Google contrôlait la résilience du site physique, la sensibilité du matériel de stockage, la gestion des événements électriques, le langage de durabilité des disques persistants, les rapports d'état et la clarté des conseils de sauvegarde. Les clients contrôlaient l'architecture de la charge de travail, les plannings d'instantanés, les objectifs de récupération, les choix de réplication et la confusion possible entre exigences de localité et récupérabilité.
• Le registre pratique des réparations devrait distinguer le service restauré, les données irrécupérables, la solution de contournement par instantané, les modifications matérielles et logicielles, les conseils de sauvegarde et les preuves clients. Dans un incident cloud impliquant une perte de données, une page de statut verte ne peut être la seule preuve de récupération.

Un petit pourcentage peut quand même être une défaillance grave

L'incident Google Cloud Belgique est parfois considéré comme une curiosité car le pourcentage de stockage définitivement perdu était extrêmement faible. C'est la mauvaise perspective. Pour un client dont le disque contenait l'écriture récente irrécupérable, le pourcentage n'avait pas d'importance. La question pertinente était de savoir si le client disposait d'une copie indépendante récupérable, si l'application pouvait tolérer le point de récupération et si le langage de durabilité du fournisseur avait rendu le risque résiduel du site physique suffisamment clair avant l'événement.

L'incident public n°15056 de Google Compute Engine a commencé le 13 août 2015 pour les disques persistants dans europe-west1-b. La page de statut a d'abord signalé des erreurs de lecture pour les clients ayant des machines dans cette zone, puis a expliqué que moins de 1% des disques de la zone étaient susceptibles de subir une dégradation des performances, puis que moins de 0,1% rencontraient des échecs de lecture sur certains blocs.

Le dossier d'incident indiquait également aux clients concernés que la restauration à partir d'instantanés était une solution de contournement, tandis que la création de nouveaux disques persistants et la restauration à partir d'instantanés n'étaient pas affectées.

Les rapports médiatiques qui ont capturé l'explication ultérieure de l'incident, y compris le rapport de centres de données Dynamics sur la foudre et la perte de données et le récit de Silicon UK sur la cause de la panne, ont enregistré la déclaration de Google selon laquelle quatre coups de foudre successifs sur le réseau électrique local ont provoqué une brève perte de puissance des systèmes de stockage hébergeant la capacité disque pour les instances GCE dans europe-west1-b.

Google a déclaré que presque toutes les données étaient engagées dans un stockage stable, mais dans de très rares cas, des écritures récentes étaient irrécupérables, entraînant une perte de données permanente sur le disque persistant. Le chiffre largement répété était inférieur à 0,000001% de l'espace de disque persistant alloué dans la zone concernée.

Ce dossier soutient à la fois la retenue et le sérieux. Il serait erroné de décrire l'événement comme une destruction généralisée des données sur Google Cloud. Le service concerné était le disque persistant standard dans une seule zone; les disques persistants SSD, les instantanés et les SSD locaux ont été signalés par les index post-mortem et la couverture contemporaine comme étant en dehors de la population de perte permanente. Il serait également erroné de rejeter l'incident parce que le dénominateur était énorme. La durabilité des données est un fait binaire pour le dossier qui compte.

Un petit pourcentage irrécupérable reste une perte permanente pour quelqu'un.

La question de responsabilité n'est donc pas « Pourquoi la foudre existait-elle? » La foudre est un danger externe. La question est de savoir qui contrôlait les choix de conception qui ont permis à un événement électrique répété sur le réseau électrique d'atteindre l'état d'écriture récente du disque, qui contrôlait la clarté des directives de durabilité et de sauvegarde, et qui contrôlait l'architecture du client qui avait ou non un point de récupération indépendant. Le déclencheur était physique.

Le problème de responsabilité fondamental était la frontière entre la durabilité locale gérée par le fournisseur et la récupérabilité gérée par le client.

Localité et durabilité ne sont pas la même promesse

La localité cloud résout de vrais problèmes. Un client peut choisir europe-west1 pour la latence vers les utilisateurs belges ou européens, pour des raisons d'approvisionnement, pour des caractéristiques carbone plus faibles ou pour des engagements de localisation des données. La page actuelle des emplacements cloud de Google et la documentation sur les régions et zones de Compute Engine expliquent que les ressources vivent dans des régions et des zones, et que les zones et les régions sont des abstractions logiques des ressources physiques sous-jacentes. Cette abstraction est utile car les clients n'ont pas à gérer les bâtiments.

Elle est dangereuse si les clients en déduisent qu'une ressource zonale a échappé au domaine de défaillance physique.

La souveraineté des données et la localité concernent l'endroit où les données sont stockées ou traitées. La récupérabilité concerne la question de savoir si une autre copie utilisable existe après une défaillance. Un disque peut satisfaire une exigence de localisation et être néanmoins la mauvaise architecture de durabilité pour une base de données si son seul état récupérable se trouve dans la même zone et sur la même classe de stockage. Un instantané peut satisfaire la récupération mais peut avoir ses propres choix de localisation.

Un disque régional peut augmenter la disponibilité entre les zones mais peut ne pas satisfaire chaque objectif de point de récupération. Un deuxième fournisseur peut réduire la dépendance commune mais peut augmenter la complexité opérationnelle et le risque de gouvernance des données. Ce sont des dimensions différentes.

Les conditions de résidence des données actuelles de Google et le matériel sur les engagements européens précisent où les données des clients peuvent résider pour les services pris en charge. Ils ne transforment pas chaque ressource locale en une sauvegarde indépendante. De même, la page produit Persistent Disk décrit un stockage de blocs durable, et la documentation Persistent Disk de Compute Engine indique que Persistent Disk dispose d'une redondance intégrée pour se protéger contre les pannes d'équipement et maintenir la disponibilité des données lors des opérations de maintenance. Ce sont des engagements significatifs du fournisseur.

Ils ne garantissent pas que tout danger possible à l'échelle du site laissera zéro écriture récente irrécupérable dans toutes les configurations.

L'incident de 2015 a exposé l'écart d'interprétation. Un client pourrait lire « persistant » comme signifiant que le disque survit à une machine virtuelle, ce qui est correct. Un autre pourrait lire comme signifiant que le disque est immunisé contre la perte de données, ce qui n'est pas une inférence sûre. Un client pourrait lire « Europe » ou « Belgique » comme la principale décision de conformité et s'arrêter là. L'incident montre que la localisation n'est pas un plan de récupération. Le même placement local qui aide la latence et la politique peut concentrer le risque physique si aucune sauvegarde indépendante n'existe.

Le langage du fournisseur devrait donc être explicite sur les domaines de défaillance. Un disque persistant zonal est durable dans sa conception mais reste lié à une zone. Les instantanés, les disques régionaux, la réplication et la sauvegarde applicative modifient le modèle de défaillance. Les clients ont besoin de cette distinction avant un incident, pas seulement après qu'une page de statut leur a dit de restaurer à partir d'instantanés. La divulgation de la plus grande valeur est une cartographie claire du choix de stockage au domaine de défaillance, au point de récupération, au temps de récupération et au devoir du client.

Le déclencheur physique appartient au dossier de responsabilité cloud. Le cloud peut faire disparaître l'infrastructure physique du travail quotidien du client, mais il ne fait pas disparaître les dangers physiques. Les systèmes d'alimentation, les batteries, les contrôleurs de stockage, le firmware, les racks, la distribution électrique et les événements du réseau électrique restent partie intégrante du service. Le client paie le fournisseur pour gérer ces couches car le fournisseur a une plus grande échelle et expertise.

Cela fait de la résilience physique un devoir du fournisseur, tout en laissant l'architecture de récupération applicative en partie avec le client.

L'explication de l'incident rapportée par plusieurs médias indiquait que les systèmes auxiliaires automatiques ont rapidement rétabli l'alimentation et que les systèmes de stockage étaient conçus avec une batterie de secours, mais certaines données récemment écrites se trouvaient sur des systèmes plus sensibles aux pannes de courant prolongées ou répétées. Cette phrase est importante car elle distingue un seul coup de foudre d'un stress physique répété qui a trouvé un sous-ensemble vulnérable de stockage.

Elle montre également pourquoi le cadrage « vieux disques » utilisé dans certains reportages doit être traité avec prudence: les articles publics décrivaient la sensibilité du matériel, mais le dossier de statut public ne publie pas chaque composant, âge ou décision d'ingénierie interne.

Google aurait déclaré avoir mené une large revue de la distribution électrique, du matériel informatique et du logiciel contrôlant la couche Persistent Disk, et qu'il mettait à niveau le matériel de stockage pour le rendre moins sensible à ce type de panne de courant. Le rapport mis à jour de centres de données Knowledge a enregistré que Google remplaçait les systèmes de stockage par du matériel plus résilient et que la majeure partie du stockage Persistent Disk était déjà sur du matériel plus récent. Ce sont des mesures réactives.

Elles doivent être comprises comme des contrôles côté fournisseur sur la pile physique et de stockage, et non comme des actions d'architecture client.

Le fournisseur contrôlait également le statut de l'incident. La page Cloud Status a fourni des mises à jour répétées, des pourcentages d'impact et des conseils de contournement par instantané. Ce dossier est matériellement meilleur que le silence. Il est cependant passé d'erreurs de lecture et de performances dégradées à la perte permanente au fur et à mesure de l'enquête. Les clients avaient besoin de savoir quels disques avaient des erreurs de lecture, si les instantanés étaient utilisables, si de nouveaux disques pouvaient être créés, quelles écritures étaient irrécupérables et si le stockage était sûr pour de nouvelles charges de travail.

Dans un événement de perte de données, la classification de l'impact ne concerne pas seulement la disponibilité du service; elle concerne l'état récupérable.

La page de statut s'est terminée lorsque Google a marqué l'incident comme résolu. Pour les clients qui ont restauré à partir d'instantanés, la récupération s'est poursuivie par la validation de l'application, la réconciliation des données et une éventuelle perte de transactions récentes. Cette distinction est essentielle. La restauration du service par le fournisseur signifie que le service de stockage fonctionne. La récupération par le client signifie que la charge de travail a un ensemble de données cohérent et que l'entreprise peut rendre compte de l'intervalle manquant. Ces moments peuvent être très différents.

Les conseils sur les instantanés rendent la responsabilité partagée concrète

La mise à jour de statut de Google pendant l'incident a indiqué aux clients concernés qu'ils pouvaient restaurer à partir d'instantanés. Cette recommandation n'est utile que pour les clients qui disposaient d'instantanés utilisables. Un instantané qui n'existe pas, est trop ancien, est au mauvais endroit, manque de cohérence applicative ou n'a jamais été testé n'est pas un chemin de récupération. L'incident a donc transformé une phrase cloud courante, responsabilité partagée, en une question concrète: qui avait réellement créé et vérifié un point de récupération avant l'événement physique?

Le guide actuel de Google sur les options de protection des données pour les disques et instances cadre la récupération autour de l'objectif de temps de récupération, de l'objectif de point de récupération, du cas d'utilisation et du coût. La documentation sur la création d'instantanés explique les instantanés standard et d'archive. La vue d'ensemble des instantanés décrit les instantanés incrémentiels. Le guide des instantanés planifiés recommande les plannings comme pratique de sauvegarde, et la page des meilleures pratiques pour les instantanés ajoute des contraintes pratiques et des conseils de fiabilité.

Cette documentation actuelle est plus claire que de nombreuses hypothèses de la première ère du cloud.

La cohérence applicative reste une préoccupation du client. Un instantané de disque capture l'état des blocs; une base de données peut nécessiter une mise en veille, un vidage ou des opérations de sauvegarde coordonnées pour rendre l'état restauré utilisable. La documentation de Google sur les instantanés Linux cohérents au niveau applicatif explique les plannings d'instantanés avec vidage invité. Le point important n'est pas l'ensemble de fonctionnalités exact en 2015 par rapport à aujourd'hui.

C'est le principe de contrôle durable: la récupérabilité nécessite un processus de sauvegarde aligné sur l'application, pas seulement une promesse de stockage du fournisseur.

Les petites équipes sont particulièrement exposées à cet écart. Une startup ou un projet municipal peut choisir une seule zone cloud pour réduire la latence et les coûts. Elle peut exécuter une base de données sur un disque persistant et se fier au nom du produit et à la réputation du fournisseur comme substitut à la conception de sauvegarde. Elle peut ne pas avoir d'ingénieur de stockage dédié, de processus de restauration testé ou d'analyse d'impact sur l'activité.

L'incident de 2015 montre pourquoi la documentation et les valeurs par défaut des produits sont importantes: les clients avec moins d'expertise interne ont besoin d'options de stockage et d'avertissements qui rendent la frontière du domaine de défaillance évidente.

Les devoirs du fournisseur et du client devraient être énoncés en langage opérationnel. Google devrait concevoir le système de stockage pour survivre aux dangers physiques attendus, publier des informations claires sur le domaine de défaillance, fournir des outils d'instantané et de réplication, préserver les preuves de l'incident et identifier les ressources affectées.

Le client devrait sélectionner un objectif de récupération, planifier les sauvegardes, valider les restaurations, placer les instantanés ou réplicas en dehors du domaine de défaillance pertinent et décider si les contraintes de localité permettent des copies hors zone ou hors région. Aucune des deux parties ne peut faire entièrement le travail de l'autre.

Les disques régionaux et la réplication modifient le modèle de défaillance, pas le besoin de réflexion sur la récupération

Google propose désormais des options haute disponibilité de disque persistant régional et Hyperdisk. La documentation sur les disques régionaux explique les disques répliqués entre zones dans une région pour une disponibilité accrue, et le guide de basculement des disques régionaux décrit l'attache forcée en cas de défaillance de la zone primaire. Le blog de Google sur les disques persistants régionaux pour les charges de travail à haute disponibilité rend explicite le cas d'utilisation de la disponibilité.

Ces fonctionnalités sont des améliorations significatives pour de nombreuses charges de travail, mais elles n'éliminent pas le jugement sur l'architecture. La réplication régionale peut protéger contre l'indisponibilité zonale ou les erreurs de stockage dans une zone. Elle peut ne pas protéger contre une corruption au niveau applicatif qui est répliquée, une suppression par le client, des informations d'identification compromises, un problème de contrôle à l'échelle de la région ou un point de récupération trop récent pour être utile. Un client a toujours besoin de sauvegardes pour la corruption, la rétention et le rollback.

Un disque répliqué est un mécanisme de haute disponibilité; ce n'est pas automatiquement un programme complet de protection des données.

La même prudence s'applique aux instantanés. Un instantané peut être indépendant du disque défaillant et peut être restauré dans une autre zone. Il peut encore être trop ancien, incohérent au niveau applicatif, indisponible pour le bon projet, chiffré avec une clé que l'environnement de récupération ne peut pas accéder, ou stocké dans un emplacement qui entre en conflit avec la politique. La documentation de Google sur le chiffrement des disques rappelle aux clients que les disques et les instantanés peuvent impliquer différents choix de clés.

La stratégie de sauvegarde doit inclure l'accès, les clés, la rétention, l'emplacement et les tests de restauration, pas seulement l'existence d'une entrée d'instantané.

Le SLA actuel de Compute Engine et la version historique du SLA de 2015 montrent une autre distinction. Les SLA traitent de la disponibilité du service et des crédits dans des conditions définies. Ils ne sont pas une déclaration complète de récupérabilité ou de perte commerciale. Un crédit peut compenser une fraction des frais de service tandis que le client doit encore restaurer les données, réconcilier les transactions, notifier les utilisateurs ou reconstruire la confiance.

Le fait que la page de statut ait indiqué aux clients concernés de restaurer à partir d'instantanés montre que la récupération opérationnelle se situait en dehors de la question du crédit SLA.

Pour les propriétaires de souveraineté des données, les choix de réplication nécessitent un travail politique minutieux. Un client peut exiger que les données restent en Europe ou en Belgique. Cela ne signifie pas que toutes les copies doivent se trouver dans une seule zone. Cela peut permettre des instantanés dans une multi-région européenne ou une autre région européenne, selon les conditions du service, les attentes des régulateurs et l'appétit pour le risque. À l'inverse, une exigence de localisation stricte peut empêcher certaines sauvegardes interrégionales et nécessiter une conception de disponibilité locale plus élevée.

L'acte responsable est de rendre ce compromis explicite avant la perte de données.

Les preuves de récupération client font partie de l'incident

Les rapports d'incident des fournisseurs se terminent souvent à la restauration du service. Les événements de perte de données nécessitent un deuxième registre: les preuves de récupération client. Quels disques avaient des erreurs de lecture? Quelles écritures étaient irrécupérables? Quels clients ont restauré à partir d'instantanés? Quels instantanés ont échoué ou étaient trop anciens? Quelles applications ont nécessité une réconciliation manuelle? Quelles charges de travail client n'avaient pas de sauvegarde? Quels messages ont été envoyés aux clients concernant la perte permanente et les étapes de contournement?

Une partie de ces preuves est privée, mais les catégories comptent publiquement.

Les pourcentages d'impact répétés sur la page de statut étaient utiles car ils évitaient une réassurance vague. Moins de 1% susceptible, moins de 0,1% avec des échecs de lecture, et moins de 0,000001% de perte permanente décrivent des catégories rétrécissantes. Ils ne doivent pas être fusionnés en une seule déclaration. Les disques susceptibles, les disques en échec actif et les données irrécupérables sont des états différents. Un client dans chaque état a besoin d'une action différente.

Le client a également besoin d'un avis spécifique à la ressource. Une page de statut générale indique au marché que quelque chose ne va pas. Elle ne dit pas à un opérateur de base de données si un disque spécifique est affecté. Google avait la plus grande capacité à identifier les ressources affectées, à corréler les systèmes de stockage et à fournir des avis au niveau du compte. Les clients avaient la plus grande capacité à vérifier la cohérence de l'application, à restaurer à partir de leurs propres instantanés et à décider quelles données commerciales récentes pourraient manquer. Les deux types de preuves sont nécessaires.

Cette division est particulièrement importante pour les auditeurs. Un auditeur examinant une charge de travail cloud après un tel événement ne devrait pas demander seulement si le fournisseur a signalé un petit pourcentage.

Les bonnes questions sont de savoir si l'organisation connaissait son objectif de point de récupération, si les instantanés existaient avant l'incident, si les tests de restauration avaient réussi, si les emplacements de sauvegarde correspondaient à la politique, si les propriétaires d'application avaient accepté la perte résiduelle et si l'avis du fournisseur fournissait suffisamment de détails pour classer les ressources affectées. Si la réponse est non, l'échec n'était pas seulement un incident fournisseur; c'était aussi un écart de gouvernance d'architecture.

Les achats devraient poser les mêmes questions à l'avance. Quel domaine de défaillance occupe ce disque? Quelle copie indépendante existe? Qui possède les plannings d'instantanés? Comment les restaurations sont-elles testées? Quel est l'intervalle maximal tolérable de perte d'écriture? La politique de localité permet-elle un réplica ailleurs? Quel avis le fournisseur donnera-t-il si les supports de stockage, l'alimentation ou les systèmes de contrôle menacent la durabilité des données? Quelle est la voie de support lors d'un événement de perte de données?

Ces questions transforment la « durabilité cloud » d'un slogan en une décision de risque.

Les achats ne devraient pas acheter une région comme s'il s'agissait d'une sauvegarde

L'incident belge est particulièrement utile pour les achats car il expose un raccourci courant. Un acheteur demande où les données vivront. Le fournisseur répond avec une région ou une zone. L'acheteur traite cette réponse comme une résilience. Mais la réponse de localisation et la réponse de récupération sont des questions contractuelles différentes. L'une décrit le placement; l'autre décrit ce qui se passe après une perte, une corruption ou une indisponibilité. Un contrat qui sécurise la localité des données mais laisse la conception de sauvegarde non définie n'a résolu que la moitié du problème.

Un dossier d'achat solide identifierait le point de récupération et le temps de récupération requis de la charge de travail avant de choisir le stockage. Une charge de travail de journalisation peut tolérer un certain retard mais pas une perte silencieuse. Une base de données transactionnelle peut avoir besoin de sauvegardes cohérentes au niveau applicatif toutes les quelques minutes. Un registre public peut avoir besoin de sauvegardes immuables et de restaurations testées. Un petit projet d'analyse peut accepter des instantanés quotidiens.

Le produit de stockage, le planning d'instantanés, l'emplacement du réplica, la conception de la clé de chiffrement et l'exercice de restauration devraient suivre l'exigence de mission, et non l'inverse.

Les achats devraient également exiger un modèle de notification du fournisseur. Pendant un incident de stockage, le fournisseur peut savoir qu'un disque est dans la population affectée avant que le client ne puisse le diagnostiquer à partir d'erreurs applicatives. Le contrat ou le plan de support devrait spécifier comment les ressources affectées sont identifiées, comment les clients sont informés si une restauration est recommandée, comment la perte permanente est signalée, comment les journaux sont conservés et comment le support technique est priorisé.

Une page de statut de service générique ne suffit pas pour un événement de perte de données car l'action du client est spécifique à la ressource.

L'acheteur devrait également éviter un faux choix entre souveraineté et résilience. Pour de nombreuses charges de travail européennes, une copie indépendante dans une autre région européenne peut satisfaire la politique tout en réduisant le risque de zone unique. Pour les charges de travail plus strictes, une réplication régionale à l'intérieur d'un pays ou des emplacements de sauvegarde soigneusement gouvernés peuvent être nécessaires. Pour certaines données, le coût et la complexité de copies supplémentaires peuvent être disproportionnés. Le point de responsabilité n'est pas que chaque charge de travail ait besoin de la même conception.

C'est que le compromis devrait être documenté et accepté par le propriétaire de l'entreprise qui comprend la conséquence des écritures perdues.

Les auditeurs devraient se méfier des réponses de checklist. « Les données sont stockées en Europe » ne répond pas à la question de savoir si elles peuvent être restaurées. « Le disque persistant est durable » ne répond pas à la question de savoir si l'application peut tolérer une perte d'écriture récente. « Les instantanés sont disponibles » ne répond pas à la question de savoir s'ils étaient configurés, récents, complets et testés. « Le fournisseur a un SLA » ne répond pas à la question de savoir si le client dispose d'une copie utilisable.

La preuve d'audit devrait inclure les résultats de test de restauration, l'âge de la sauvegarde, l'emplacement de la sauvegarde, l'accès aux clés et un enregistrement de qui a accepté le risque résiduel.

Les petites équipes ont besoin de valeurs par défaut qui rendent la récupérabilité visible

Les clients les plus susceptibles de mal comprendre la frontière sont souvent les moins équipés pour se remettre d'une infraction. Les grandes entreprises peuvent avoir des équipes de stockage, des plateformes de sauvegarde, des comités d'audit et des exercices de simulation. Les petites équipes peuvent avoir un ingénieur, un projet, une région et un tableau de bord qui rend le disque durable parce que la machine virtuelle peut être supprimée sans supprimer le volume. Leur risque n'est pas l'ignorance dans un sens péjoratif; c'est la conséquence normale de l'abstraction qui fait trop bien son travail.

Les fournisseurs cloud peuvent réduire ce risque par des valeurs par défaut et des avertissements. Lorsqu'un client crée un disque zonal unique pour une charge de travail de type base de données, l'interface peut demander des plannings de sauvegarde, recommander des politiques d'instantané, montrer le domaine de défaillance et avertir que les instantanés sont nécessaires pour une récupération indépendante. La documentation peut placer des tableaux de domaine de défaillance près des workflows de création plutôt que dans des guides de fiabilité profonds.

Les pages de prix peuvent montrer le coût de l'absence de sauvegarde comme une acceptation de risque, pas seulement le coût d'un instantané comme un supplément.

Les clients peuvent réduire le risque avec des routines simples. Chaque stockage de données persistant devrait avoir un propriétaire nommé, un objectif de point de récupération, un planning d'instantané ou de sauvegarde, une date de test de restauration, un emplacement de sauvegarde et un plan d'accès aux clés. Le premier test de restauration devrait avoir lieu avant le lancement de la production, pas pendant le premier incident. Le test devrait restaurer vers un environnement séparé, vérifier la cohérence de l'application et confirmer que l'équipe peut s'authentifier, déchiffrer et reconnecter la charge de travail.

Si l'équipe ne peut pas se permettre la conception de récupération, cela devrait être une décision commerciale consciente.

L'événement de 2015 est un bon cas d'enseignement car la perte n'était pas spectaculaire. Il n'y a pas eu d'effondrement global pour rendre la leçon inévitable. Le pourcentage était infime. Pourtant, une petite équipe avec un disque affecté et aucun instantané récent pourrait encore faire face à une perte permanente. L'éducation à la résilience se concentre souvent sur les désastres géants; cet incident montre que les défaillances rares et étroites suffisent à punir les hypothèses de sauvegarde non testées.

La même logique s'applique aux plateformes internes construites par les entreprises. Une équipe de plateforme d'entreprise peut offrir des « modèles cloud approuvés » aux équipes produit. Ces modèles ne devraient pas simplement créer un disque zonal et laisser les choix de sauvegarde aux propriétaires d'application qui peuvent ne pas comprendre la couche de stockage. La plateforme devrait exiger ou fortement guider les plannings d'instantané, les options de réplication, les périodes de rétention et les tests de restauration. La responsabilité partagée au sein d'une entreprise reflète la responsabilité partagée avec le fournisseur cloud.

La perte de données change le poids moral du langage de statut

De nombreux statuts de panne peuvent être écrits en termes d'erreurs élevées, de performances dégradées ou de restauration. La perte de données nécessite un vocabulaire différent. Les clients ont besoin de savoir si les données sont retardées, indisponibles, corrompues, restaurées, partiellement irrécupérables ou définitivement perdues. Ces catégories produisent des devoirs différents. Les données retardées peuvent nécessiter un traitement de file d'attente. Les données indisponibles peuvent nécessiter un basculement. Les données corrompues peuvent nécessiter une validation et un rollback.

La perte permanente peut nécessiter une notification, une réconciliation, une compensation ou un examen juridique.

La page de statut de Google est passée prudemment par des erreurs de lecture, des performances dégradées et des contournements par instantané. Les rapports contemporains ont ensuite enregistré une perte permanente pour une infime fraction de stockage. Le rétrécissement des populations affectées était utile, mais la leçon publique est que la perte permanente devrait être nommée clairement une fois connue. Une page de statut qui reste trop longtemps avec un langage de disponibilité peut amener les clients à traiter un événement de perte de données comme un problème de nouvelle tentative.

Une page de statut qui nomme la perte permanente trop largement peut provoquer une panique inutile. La précision n'est donc pas décorative; elle contrôle la réponse du client.

Un bon langage de statut pour les incidents de stockage devrait indiquer le produit affecté, la zone, la plage horaire, la classe de ressource, le symptôme, l'action client actuelle et l'état des preuves. Il devrait séparer les ressources à risque des ressources connues pour avoir des échecs de lecture et des ressources avec des données confirmées irrécupérables. Il devrait indiquer si les instantanés, les nouveaux disques, les disques régionaux ou d'autres produits de stockage sont affectés. Il devrait indiquer si le fournisseur peut identifier directement les ressources affectées et comment les clients seront contactés.

Il devrait être mis à jour lorsque le fournisseur passe de la réparation du service à la réconciliation des données.

Cette précision aide également les clients à rendre compte à leurs propres parties prenantes. Un délégué à la protection des données, un auditeur, un conseil d'administration ou un propriétaire de petite entreprise a besoin de savoir si l'événement a modifié la confidentialité, l'intégrité, la disponibilité ou la récupérabilité. L'événement de 2015 concernait la disponibilité et la récupérabilité pour une population de disques restreinte. Ce n'était pas une preuve d'accès non autorisé. Traiter chaque incident cloud comme une brèche est faux; traiter chaque incident de stockage comme un problème de disponibilité transitoire est également faux.

Les catégories devraient correspondre aux faits.

Les décisions de localité devraient inclure une histoire de sortie

Chaque décision de localité devrait inclure une histoire de sortie: si cette zone, région ou choix de stockage local échoue, où va la charge de travail et quelles données la suivent? Un client choisissant europe-west1-b en 2015 avait besoin de savoir si un disque défaillant pouvait être restauré dans une autre zone, si l'instantané existait en dehors du système défaillant, si l'application pouvait attacher le disque restauré, et si le DNS, les identifiants et les opérateurs pouvaient ramener le service. Ces questions restent d'actualité même si les noms de produits et les fonctionnalités ont changé.

Une histoire de sortie comporte plusieurs parties. La première sont les données: quelle copie existe, son âge et où elle se trouve. La deuxième est le calcul: quel environnement peut exécuter les données restaurées. La troisième est l'identité et les clés: qui peut y accéder et les déchiffrer. La quatrième est le réseau et le routage: comment les utilisateurs atteignent le service récupéré. La cinquième est la validation: comment l'équipe sait que l'application restaurée est correcte.

La sixième est la communication: comment les utilisateurs et les parties prenantes sont informés de ce qui s'est passé et de l'intervalle de données qui peut manquer.

Les contraintes de localité rendent l'histoire de sortie plus complexe, mais pas facultative. Si les données doivent rester en Belgique, la conception peut nécessiter une résilience locale multi-zone, des instantanés plus fréquents et des contrôles de sauvegarde sur site plus solides. Si les données peuvent rester en Europe, la conception peut utiliser une autre région européenne ou un stockage d'instantanés multi-région. Si la politique permet une sauvegarde mondiale pour la reprise après sinistre, la conception doit encore gérer la confidentialité, le chiffrement et les contrôles d'accès.

La clé est de décider explicitement plutôt que de laisser le placement de disque par défaut décider silencieusement.

Le fournisseur peut faciliter cela en présentant les domaines de défaillance dans le langage du client. Au lieu de seulement des noms de produits, l'interface peut décrire « survit à la suppression de VM », « survit à une classe de défaillance matérielle zonale », « survit à une panne de zone grâce à la réplication régionale » et « prend en charge la restauration à un instant dans le temps grâce aux instantanés ». Aucune phrase courte ne couvrira tous les cas, mais un langage simple de domaine de défaillance est plus difficile à mal interpréter que des adjectifs vagues de durabilité.

Inconnues et limites prudentes

Le dossier public ne nomme pas chaque client affecté, chaque écriture perdue, chaque modèle matériel interne ou chaque changement d'ingénierie post-incident. Il ne prouve pas que l'échec de sauvegarde d'un client spécifique a causé sa perte. Il n'établit pas de violation légale, de constat de négligence, de dommages-intérêts ou de violation de conformité. Il ne prouve pas non plus que tous les produits de stockage Google Cloud actuels comportent le même risque de 2015. L'infrastructure cloud et les fonctionnalités des produits ont considérablement changé depuis.

Le dossier public soutient plusieurs conclusions fermes. L'événement a affecté les disques persistants dans europe-west1-b. Les clients ont rencontré des erreurs de lecture. Google a dirigé les clients concernés vers la restauration à partir d'instantanés. Les rapports contemporains basés sur le récit de Google décrivaient quatre coups de foudre successifs sur le réseau électrique local, une brève perte de puissance des systèmes de stockage, une sensibilité matérielle dans un sous-ensemble de stockage et la perte permanente d'une infime fraction de l'espace de disque persistant alloué.

Google a déclaré qu'il examinerait la pile et mettrait à niveau le matériel de stockage. La documentation actuelle de Google rend explicites les instantanés, les sauvegardes planifiées, les disques régionaux et les choix de protection des données.

L'inférence la plus importante est soutenue mais doit être marquée comme une inférence: des informations plus claires sur le domaine de défaillance et des sauvegardes indépendantes testées réduisent la probabilité qu'un danger physique se transforme en perte permanente d'application. Ce n'est pas la même chose que de dire que chaque client sans instantané a été négligent ou que Google a manqué à une obligation légale. C'est une conclusion pratique de contrôle. Le fournisseur peut rendre la frontière visible et construire une infrastructure plus résiliente.

Le client peut choisir une conception de récupération qui ne repose pas sur un seul disque local.

L'incident met également en garde contre deux erreurs opposées. La première est le fatalisme cloud: conclure que parce qu'un fournisseur hyperscale a perdu une infime quantité de données une fois, le stockage cloud ne peut pas être fiable. La seconde est la complaisance cloud: conclure que parce que le pourcentage était infime, personne n'a besoin de sauvegardes indépendantes. La position mature est plus exigeante et plus utile. Utilisez la durabilité du fournisseur, mais ne la confondez pas avec un point de récupération. Utilisez la localité, mais ne la confondez pas avec la résilience.

Utilisez les SLA, mais ne confondez pas les crédits avec l'état restauré.

Le test de preuve pratique est assez simple à exécuter avant la conclusion d'un achat. Un acheteur devrait être capable de pointer vers le disque actif, le dernier point de récupération indépendant, la cible de restauration, le chemin d'identité et de clé, la personne responsable d'une restauration et le test réussi le plus récent. Un fournisseur devrait être capable de pointer vers le domaine de défaillance, le chemin de notification spécifique à la ressource, les catégories de statut d'incident et le chemin de support pour les clients confrontés à une perte permanente.

Si l'une ou l'autre des parties ne peut pas répondre à ces questions avant un événement de stockage rare, l'architecture repose sur l'espoir caché derrière des noms de produits respectables.

C'est pourquoi un petit événement de 2015 appartient toujours à un programme de responsabilité de 2026. Il transforme un modèle abstrait de responsabilité partagée en un contrat opérationnel visible. La pile du fournisseur peut être plus solide maintenant, et les clients ont plus d'outils, mais la logique de décision reste la même: la localité doit être associée à une copie récupérable, une copie récupérable doit être testée, et une récupération testée doit être comprise par le propriétaire de l'entreprise qui fera face aux utilisateurs lorsque les données manqueront.

Le propriétaire final de cette décision ne devrait pas être caché dans un raccourci d'infrastructure. Il devrait s'agir d'un propriétaire de service nommé qui comprend le coût d'une heure perdue, d'un jour perdu ou d'un intervalle de transaction perdu.

Ce propriétaire devrait également avoir l'autorité de financer la sauvegarde.

Le dossier de perte de disque belge reste utile car il est suffisamment petit pour être étudié et suffisamment sérieux pour changer les pratiques. Il montre que la redondance gérée par le fournisseur peut échouer à la limite d'un danger physique, que les pourcentages de statut doivent être lus par catégorie, que les instantanés ne sont importants que s'ils existent et se restaurent proprement, et que la localité n'est pas un substitut à la récupérabilité indépendante. Google contrôlait le centre de données et la pile de stockage; les clients contrôlaient leur architecture de récupération;

les auditeurs et les équipes d'achat contrôlaient si ces deux responsabilités étaient examinées avant le prochain événement rare. Le résultat responsable est un plan de stockage qui peut dire où les données vivent, où vit une copie récupérable, à quel point elle est fraîche, qui peut la restaurer et quelles preuves prouveront la récupération lorsque la zone locale ne le pourra plus.