L'incident de perte de disque de Google Cloud en Belgique illustre les limites de la localisation face à la résilience

Résumé

• En août 2015, les disques persistants standard de Google Compute Engine dans la zone europe-west1-b ont subi des erreurs de lecture après que quatre impacts de foudre successifs ont affecté le réseau électrique local desservant un centre de données européen. Google a par la suite signalé qu'une très petite fraction de l'espace disque persistant alloué dans la zone avait subi des écritures récentes irrécupérables.
• La question de la responsabilité n'est pas de savoir si le pourcentage était élevé, mais si les clients comprenaient qu'un disque persistant zonal, même avec une redondance gérée par le fournisseur à l'intérieur de la zone, restait à l'intérieur d'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 de statut et la clarté des conseils de sauvegarde. Les clients contrôlaient l'architecture de la charge de travail, les planifications d'instantanés, les objectifs de récupération, les choix de réplication, et la question de savoir si les exigences de localisation étaient confondues avec la récupérabilité.
• Le bilan concret des réparations devrait distinguer le service restauré, les données irrécupérables, la solution de contournement par instantanés disponibles, les modifications matérielles et logicielles, les conseils de sauvegarde et les preuves client. Dans un incident cloud impliquant une perte de données, une page de statut verte ne peut pas constituer la seule preuve de récupération.

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

L'incident Google Cloud en Belgique est parfois considéré comme une curiosité parce que le pourcentage de stockage définitivement perdu était extrêmement faible. Ce n'est pas le bon point de départ. Pour un client dont le disque contenait l'écriture récente irrécupérable, le pourcentage importait peu. 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 lié au site physique suffisamment clair avant l'événement.

La page publique deCompute Engine Incident #15056de Google 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 pour cent des disques de la zone étaient susceptibles de subir des performances dégradées, puis que moins de 0,1 pour cent rencontraient des échecs de lecture sur certains blocs. Le rapport 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 articles de presse qui ont repris l'explication ultérieure de l'incident, notamment lerapport de centres de données Dynamics sur la foudre et la perte de donnéeset lecompte rendu de Silicon UK sur la cause de la panne, ont rapporté la déclaration de Google selon laquelle quatre impacts de foudre successifs sur le réseau électrique local ont provoqué une brève perte d'alimentation des systèmes de stockage hébergeant la capacité disque pour les instances GCE dans europe-west1-b. Google a indiqué que presque toutes les données avaient été sauvegardées sur un stockage stable, mais que dans quelques très rares cas, des écritures récentes étaient irrécupérables, entraînant une perte de données permanente sur disque persistant. Le chiffre largement répété était inférieur à 0,000001 pour cent de l'espace disque persistant alloué dans la zone concernée.

Ce bilan justifie à la fois la retenue et le sérieux. Il serait faux de décrire l'événement comme une destruction massive de données sur l'ensemble de 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 hors de la population affectée par la perte permanente. Il serait également faux de minimiser l'incident en raison de la taille du dénominateur. La durabilité des données est un fait binaire pour l'enregistrement qui compte.

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

La question de la responsabilité n'est donc pas « Pourquoi la foudre existe-t-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 public d'atteindre l'état du disque récemment écrit, qui contrôlait la clarté des conseils de durabilité et de sauvegarde, et qui contrôlait l'architecture client qui disposait ou non d'un point de récupération indépendant. Le déclencheur était physique.

Le problème fondamental de responsabilité é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. Lapage des emplacements cloudactuelle de Google et la documentation de Compute Engine sur lesrégions et zonesexpliquent que les ressources résident 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é et la localité des données concernent l'endroit où les données sont stockées ou traitées. La récupérabilité concerne l'existence d'une autre copie utilisable après une défaillance. Un disque peut satisfaire à une exigence de localisation tout en constituant une architecture de durabilité inadaptée pour une base de données si son seul état récupérable réside dans la même zone et sur la même classe de stockage. Un instantané peut assurer 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 tous les objectifs de point de récupération. Un deuxième fournisseur peut réduire la dépendance commune mais peut accroître la complexité opérationnelle et le risque de gouvernance des données. Ce sont des dimensions différentes.

Lesconditions de résidence des donnéesactuelles de Google et ses engagements européens matériels concernent l'endroit 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 du disque persistant décrit lestockage en bloc durable, et la documentation de Compute Engine sur lesdisques persistantsindique que le disque persistant 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 événements de maintenance. Ce sont des engagements significatifs du fournisseur. Ils ne garantissent pas que tout danger à l'échelle du site laissera zéro écriture récente irrécupérable dans toutes les configurations.

L'incident de 2015 a mis en évidence l'écart d'interprétation. Un client pourrait comprendre le terme « persistant » comme signifiant que le disque survit à une machine virtuelle, ce qui est exact. Un autre pourrait comprendre qu'il est immunisé contre la perte de données, ce qui n'est pas une déduction sûre. Un client pourrait considérer « 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 favorise 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 quant aux domaines de défaillance. Un disque persistant zonal est durable dans les limites de 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, et non pas seulement après qu'une page de statut leur dise de restaurer à partir d'instantanés.

La divulgation la plus précieuse est un mappage clair entre le choix de stockage, le domaine de défaillance, le point de récupération, le temps de récupération et le devoir du client.

Le déclencheur physique fait partie du bilan de responsabilité du 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, les micrologiciels, les racks, la distribution électrique et les événements du réseau électrique restent des composants du service. Le client paie le fournisseur pour gérer ces couches parce que le fournisseur possède une plus grande échelle et une plus grande expertise. Cela fait de la résilience physique un devoir du fournisseur, tout en laissant l'architecture de récupération applicative en partie au client.

L'explication de l'incident rapportée par plusieurs médias indiquait que des systèmes auxiliaires automatiques avaient rapidement rétabli l'alimentation et que les systèmes de stockage étaient conçus avec une batterie de secours, mais que certaines données récemment écrites se trouvaient sur des systèmes plus sensibles aux pannes d'alimentation résultant d'une décharge prolongée ou répétée de la batterie. Cette phrase est importante car elle distingue un seul impact 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 « anciens disques » utilisé dans certains reportages doit être traité avec prudence: les articles publics ont décrit la sensibilité du matériel, mais le registre 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 de disque persistant, et qu'il mettait à niveau le matériel de stockage pour le rendre moins sensible à ce type de panne d'alimentation. Lerapport actualisé de centres de données Knowledgea indiqué que Google remplaçait les systèmes de stockage par du matériel plus résilient électriquement et qu'une grande partie du stockage sur disque persistant é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 couche physique et de stockage, et non comme des actions d'architecture du 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és. Ce bilan est nettement meilleur que le silence. Il est toutefois passé des erreurs de lecture et des performances dégradées à la perte permanente au fur et à mesure de l'avancement de l'enquête.

Les clients avaient besoin de savoir quels disques présentaient 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 les 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 applicative, le rapprochement des données et la perte possible 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 client signifie que la charge de travail dispose d'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, qui est trop ancien, qui est au mauvais endroit, qui manque de cohérence applicative ou qui n'a jamais été testé n'est pas un chemin de récupération. L'incident a donc transformé une expression courante du cloud, la responsabilité partagée, en une question concrète: qui avait effectivement créé et vérifié un point de récupération avant l'événement physique?

Leguide de protection des données pour les disques et les instancesactuel de Google encadre la récupération autour de l'objectif de délai de récupération, de l'objectif de point de récupération, du cas d'usage et du coût. Ladocumentation sur la création d'instantanésexplique les instantanés standard et d'archive. Laprésentation des instantanésdécrit les instantanés incrémentiels. Leguide des instantanés programmésrecommande les planifications comme une pratique de sauvegarde, et lapage des meilleures pratiques d'instantanésajoute des contraintes pratiques et des conseils de fiabilité. Cette documentation actuelle est plus claire que de nombreuses hypothèses des débuts de l'ère cloud.

La cohérence applicative reste une préoccupation du client. Un instantané de disque capture l'état du bloc; une base de données peut nécessiter une mise au repos, une vidange ou des opérations de sauvegarde coordonnées pour rendre l'état restauré utilisable. Ladocumentation sur les instantanés cohérents applicatifs sous Linuxde Google explique les planifications d'instantanés avec vidange invité. Le point important n'est pas l'ensemble exact des fonctionnalités en 2015 par rapport à maintenant. C'est le principe de contrôle durable: la récupérabilité nécessite un processus de sauvegarde adapté à l'application, et non une simple promesse de stockage du fournisseur.

Les petites équipes sont particulièrement exposées à cet écart. Une start-up ou un projet municipal peut choisir une seule zone cloud pour réduire la latence et les coûts. Il 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 à une conception de sauvegarde. Il 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 ayant moins d'expertise interne ont besoin d'options de stockage et d'avertissements qui rendent évidente la frontière du domaine de défaillance.

Les devoirs du fournisseur et du client doivent être formulés en langage opérationnel. Google doit concevoir le système de stockage pour survivre aux dangers physiques prévus, publier des informations claires sur les domaines 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 doit sélectionner un objectif de récupération, planifier les sauvegardes, valider les restaurations, placer les instantanés ou les 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 tout le travail de l'autre.

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

Google propose désormais des disques persistants régionaux et des options de haute disponibilité Hyperdisk. Ladocumentation sur les disques régionauxexplique les disques répliqués entre les zones d'une région pour une plus grande disponibilité, et leguide de basculement des disques régionauxdécrit le rattachement forcé en cas de défaillance de la zone principale. Le billet de blog de Google sur lesdisques persistants régionaux pour des charges de travail hautement disponiblesexplicite le cas d'usage de la disponibilité.

Ces fonctionnalités constituent des améliorations significatives pour de nombreuses charges de travail, mais elles n'éliminent pas le jugement architectural. 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 la corruption au niveau applicatif qui est répliquée, la 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 la restauration.

Un disque répliqué est un mécanisme de haute disponibilité; il ne constitue 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 applicatif, indisponible pour le bon projet, chiffré avec une clé à laquelle l'environnement de récupération ne peut pas accéder ou stocké dans un emplacement qui entre en conflit avec la politique. Ladocumentation sur le chiffrement des disquesde Google rappelle aux clients que les disques et les instantanés peuvent impliquer des choix de clés différents. La stratégie de sauvegarde doit inclure l'accès, les clés, la rétention, l'emplacement et les tests de restauration, et pas seulement l'existence d'une entrée d'instantané.

LeSLA actuelde Compute Engine et laversion du SLA de 2015historique montrent une autre distinction. Les SLA traitent de la disponibilité du service et des crédits dans des conditions définies. Ils ne constituent pas une énonciation complète de la récupérabilité ou de la perte commerciale. Un crédit peut compenser une fraction des frais de service tandis que le client doit encore restaurer les données, rapprocher les transactions, informer 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 responsables de la souveraineté des données, les choix de réplication exigent 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, en fonction des conditions de service, des attentes du régulateur et de l'appétit pour le risque. Inversement, une exigence de localisation stricte peut empêcher certaines sauvegardes inter-régions et exiger une conception de disponibilité locale plus élevée.

L'acte responsable consiste à expliciter ce compromis avant la perte de données.

Les preuves de récupération du 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 du client. Quels disques ont eu 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é un rapprochement manuel? 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 sont importantes publiquement.

Les pourcentages d'impact répétés de la page de statut étaient utiles parce qu'ils évitaient une vague réassurance. Moins de 1 pour cent de disques sensibles, moins de 0,1 pour cent avec des échecs de lecture et moins de 0,000001 pour cent de perte permanente décrivent des catégories qui se rétrécissent. Elles ne doivent pas être fondues en une seule déclaration. Les disques sensibles, 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 applicative, à restaurer à partir de leurs propres instantanés et à décider quelles données commerciales récentes pouvaient 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 se demander seulement si le fournisseur a signalé un faible pourcentage.

Les bonnes questions sont de savoir si l'organisation connaissait son objectif de point de récupération, si des 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'applications acceptaient 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 une lacune de gouvernance architecturale.

Les achats devraient poser les mêmes questions à l'avance. Quel domaine de défaillance ce disque occupe-t-il? Quelle copie indépendante existe-t-il? Qui possède les planifications d'instantanés? Comment les restaurations sont-elles testées? Quel est l'intervalle maximal tolérable d'écritures perdues? La politique de localité permet-elle une réplique ailleurs? Quel avis le fournisseur donnera-t-il si le support de stockage, l'alimentation ou les systèmes de contrôle menacent la durabilité des données? Quel est le chemin de support pendant 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 parce qu'il expose un raccourci courant. Un acheteur demande où les données résideront. Le fournisseur répond avec une région ou une zone. L'acheteur traite cette réponse comme de la résilience. Mais la réponse sur la localisation et la réponse sur la 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 la sauvegarde indé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 délai de récupération requis par 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 nécessiter des sauvegardes cohérentes applicatives toutes les quelques minutes. Un registre public peut nécessiter des sauvegardes immuables et des restaurations testées. Un petit projet d'analyse peut accepter des instantanés quotidiens.

Le produit de stockage, la planification des instantanés, l'emplacement de la réplique, la conception des clés de chiffrement et l'exercice de restauration devraient découler de l'exigence de mission, et non l'inverse.

Les achats devraient également exiger un modèle d'avis du fournisseur. Lors d'un incident de stockage, le fournisseur peut savoir qu'un disque fait partie de 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 préservés et comment le support technique est priorisé.

Une page de statut de service générique n'est pas suffisante pour un événement de perte de données parce que 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 des charges de travail plus strictes, une réplication régionale à l'intérieur d'un pays ou des emplacements de sauvegarde soigneusement régis 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 soit documenté et accepté par le propriétaire de l'activité qui comprend la conséquence des écritures perdues.

Les auditeurs devraient se méfier des réponses de liste de contrôle. « 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 a une copie utilisable.

Les preuves d'audit devraient inclure les résultats de test de restauration, l'âge des sauvegardes, l'emplacement des sauvegardes, 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 de sa traversée. Les grandes entreprises peuvent avoir des équipes de stockage, des plates-formes 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 donne l'impression que le disque est durable parce que la machine virtuelle peut être supprimée sans supprimer le volume. Leur risque n'est pas de l'ignorance au sens péjoratif; c'est la conséquence normale d'une abstraction qui fait trop bien son travail.

Les fournisseurs de cloud peuvent réduire ce risque par des valeurs par défaut et des avertissements. Lorsqu'un client crée un disque mono-zonal pour une charge de travail de type base de données, l'interface peut poser des questions sur les planifications de sauvegarde, recommander des politiques d'instantanés, 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 les tableaux de domaines de défaillance à proximité des flux de travail de création plutôt qu'au fond des guides de fiabilité.

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

Les clients peuvent réduire le risque avec des routines simples. Chaque magasin de données persistant devrait avoir un propriétaire nommé, un objectif de point de récupération, une planification 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 la mise en production, et non pendant le premier incident. Le test devrait restaurer vers un environnement séparé, vérifier la cohérence applicative 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 parce que la perte n'était pas spectaculaire. Il n'y a pas eu d'effondrement mondial pour rendre la leçon incontournable. 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 grands désastres; cet incident montre que des 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'applications qui peuvent ne pas comprendre la couche de stockage. La plateforme devrait exiger ou fortement guider les planifications d'instantanés, les options de réplication, les périodes de rétention et les tests de restauration.

La responsabilité partagée à l'intérieur d'une entreprise reflète la responsabilité partagée avec le fournisseur de cloud.

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

De nombreux statuts de panne peuvent être rédigés 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 entraînent 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 une restauration.

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

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

Une page de statut qui nomme la perte permanente de manière trop large 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 temporelle, la classe de ressources, le symptôme, l'action actuelle du client et le statut 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 irrécupérables confirmées. Il devrait dire 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 au rapprochement des données.

Cette précision aide également les clients à rendre compte à leurs propres parties prenantes. Un responsable de 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 était un problème de disponibilité et de récupérabilité pour une population étroite de disques. Il ne s'agissait pas d'une preuve d'accès non autorisé.

Traiter chaque incident cloud comme une violation est faux; traiter chaque incident de stockage comme un problème de disponibilité transitoire est également faux. Les catégories doivent correspondre aux faits.

Les décisions de localité devraient inclure un scénario de sortie

Chaque décision de localité devrait inclure un scénario de sortie: si ce choix de zone, de région ou de stockage local échoue, où va la charge de travail et quelles données la suivent? Un client choisissant europe-west1-b en 2015 devait 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 informations d'identification et les opérateurs pouvaient remettre le service en ligne. Ces questions restent d'actualité même si les noms de produits et les fonctionnalités ont changé.

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

La sixième concerne 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 le scénario de sortie plus complexe, mais pas facultatif. 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 forts. 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égional. 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.

L'essentiel est de décider explicitement plutôt que de laisser le placement par défaut du disque décider silencieusement.

Le fournisseur peut faciliter cela en présentant les domaines de défaillance dans un langage client. Au lieu de simples noms de produits, l'interface peut décrire « survit à la suppression de la VM », « survit à la 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 point dans le temps grâce aux instantanés ». Aucune phrase courte ne couvrira tous les cas limites, mais un langage simple sur les domaines de défaillance est plus difficile à mal interpréter que de larges adjectifs de durabilité.

Inconnues et limites prudentes

Le dossier public ne nomme pas tous les clients affectés, chaque écriture perdue, chaque modèle de 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 une violation légale, une conclusion de négligence, une attribution de dommages-intérêts ou une violation de conformité. Il ne prouve pas non plus que tous les produits de stockage actuels de Google Cloud comportent le même risque qu'en 2015. L'infrastructure cloud et les fonctionnalités des produits ont considérablement changé depuis lors.

Le dossier public soutient plusieurs conclusions fermes. L'événement a affecté les disques persistants dans europe-west1-b. Les clients ont subi des erreurs de lecture. Google a demandé aux clients affectés de restaurer à partir d'instantanés. Les rapports contemporains basés sur le compte rendu de Google ont décrit quatre impacts de foudre successifs sur le réseau électrique local, une brève perte d'alimentation des systèmes de stockage, une sensibilité matérielle dans un sous-ensemble de stockage et une perte permanente d'une fraction infime de l'espace 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 programmé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: une divulgation plus claire des domaines de défaillance et des sauvegardes indépendantes testées réduisent le risque qu'un danger physique du site devienne une perte applicative permanente. Cela ne revient pas à dire que tout client sans instantané était négligent ou que Google a manqué à un devoir légal. C'est une conclusion de contrôle pratique. 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 à grande échelle a perdu une infime quantité de données une fois, le stockage cloud n'est pas 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 pratique des preuves est assez simple à exécuter avant la clôture des achats. Un acheteur devrait pouvoir indiquer 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 dernier test réussi le plus récent. Un fournisseur devrait pouvoir indiquer le domaine de défaillance, le chemin d'avis 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 partie 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 a encore sa place dans 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 est peut-être plus forte 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'activité qui fera face aux utilisateurs lorsque des données manqueront.

Le propriétaire final de cette décision ne devrait pas être caché derrière des raccourcis d'infrastructure. Il devrait s'agir d'un propriétaire de service nommé qui comprend le coût d'une heure perdue, d'une journée perdue ou d'un intervalle de transaction perdu.

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

La typographie est l'art et la technique d'agencer les caractères pour rendre la langue écrite lisible, compréhensible et visuellement attrayante. Elle implique la sélection de polices, de tailles de points, de longueurs de ligne, d'espacement des lignes et d'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés incluent le choix de la police, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

Le dossier de la perte de disque en Belgique reste utile parce qu'il est assez petit pour être étudié et assez 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é ne remplace pas 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 résident, où une copie récupérable réside, à 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.