Résumé

  • La perturbation d'Amazon S3 de février 2017 importe car le résumé public d'AWS a décrit une commande opérationnelle qui a retiré plus de capacité de sous-système que prévu, forçant la récupération du sous-système d'index et de placement avant que le comportement normal de stockage objet ne revienne.
  • Le problème de responsabilité n'est pas qu'un grand service distribué peut échouer. C'est qui avait le contrôle pratique sur les outils opérationnels, les garanties de capacité minimale, les hypothèses de redémarrage, la cartographie des services dépendants, la communication sur l'état de santé des services et les choix d'architecture client.
  • Le résumé public post-événement d'AWS est exceptionnellement utile car il nomme les sous-systèmes S3 affectés et donne une séquence datée des jalons de récupération. Il n'expose toujours pas chaque journal privé, perte client, arriéré de service spécifique ou remède contractuel.
  • Les clients qui ont traité la disponibilité de S3 dans une région comme une fondation universelle ont appris une leçon de continuité plus dure: le repli doit être testé contre la même dépendance cloud, la même concentration régionale, le même canal de statut et les mêmes services aval qui peuvent échouer ensemble.

Le stockage objet est devenu un registre de dépendances public

Amazon S3 est souvent décrit comme un stockage objet durable, mais l'incident du 28 février 2017 a révélé un rôle plus large. S3 n'était pas seulement un endroit où les clients stockaient des fichiers. C'était un registre de dépendances pour les sites web, les applications mobiles, les chemins de déploiement logiciel, les charges de travail d'analyse, la diffusion de médias, l'échange de données, les portails clients, les pages de service public, les outils de surveillance et d'autres services AWS.

Lorsque la région US-EAST-1 de S3 a connu des erreurs élevées et des opérations indisponibles, l'effet ne s'est pas limité à une interface de stockage. L'événement s'est propagé à travers les architectures qui avaient silencieusement utilisé S3 comme hypothèse de base.

Le résumé public post-événement d'AWS àhttps://aws.amazon.com/message/41926/est la source de preuve centrale pour ce cas. Le résumé a indiqué qu'à 9h37, heure du Pacifique, un membre autorisé de l'équipe S3 exécutait un playbook établi pour retirer la capacité d'un sous-système S3 utilisé par le processus de facturation S3. La commande a retiré plus de capacité que prévu. AWS a écrit que cela a retiré une capacité significative de deux sous-systèmes: le sous-système d'index, qui gère les métadonnées et les informations de localisation des objets dans la région, et le sous-système de placement, qui alloue le nouveau stockage. Ce cadrage importe. L'incident n'a pas été décrit comme une panne de courant, une coupure de fibre, une catastrophe naturelle ou une erreur de configuration côté client. C'était un événement de contrôle opérationnel côté fournisseur qui a réduit la capacité dans des sous-systèmes internes critiques.

La chronologie publique transforme ensuite la panne en un enregistrement de responsabilité. AWS a indiqué que le sous-système d'index devait redémarrer et que le redémarrage a pris plus de temps que prévu car les systèmes n'avaient pas été complètement redémarrés depuis de nombreuses années. Le résumé a rapporté que suffisamment de capacité d'index a été restaurée pour prendre en charge les requêtes GET, LIST et DELETE à 11h54, heure du Pacifique, ces opérations se rétablissant à 12h26.

Il a ensuite rapporté une récupération suffisante du sous-système de placement pour commencer à traiter les requêtes PUT à 13h18, les opérations PUT étant complètement rétablies à 13h54. La différence entre lecture/liste/suppression et placement d'écriture est importante car les clients ne vivent pas « S3 » comme un seul interrupteur abstrait. Ils vivent des opérations particulières qui échouent, se rétablissent, prennent du retard, réessayent et reviennent à la normale en séquence.

Cette séquence montre aussi pourquoi la responsabilité du stockage objet ne peut pas être réduite à la disponibilité agrégée. Un client exécutant un site web statique depuis S3, un pipeline de déploiement qui télécharge des artefacts, un travail d'analyse qui liste des objets et une application mobile qui récupère des médias peuvent voir des symptômes différents. Un objet statique peut continuer à être disponible via un cache, tandis qu'un nouvel téléchargement échoue. Une opération de liste peut se rétablir avant le placement d'un nouvel objet. Un service AWS aval peut rester dégradé car sa propre dépendance à S3 n'a pas été levée.

Une déclaration de rétablissement à l'échelle du fournisseur est précieuse, mais elle ne remplace pas la preuve de dépendance au niveau du client.

L'incident S3 est donc un cas de dépendance au cloud, pas seulement un cas de disponibilité de stockage. Les clients achètent des services gérés pour éviter de posséder des disques, du code de réplication, des installations physiques et une grande partie de la charge des systèmes distribués. Ce marché est rationnel. Mais la dépendance se déplace vers les outils du fournisseur, la conception de la région, la communication sur l'état de santé des services, l'architecture client et les preuves de support. La question de contrôle pratique est distribuée.

AWS contrôlait l'interface de commande opérationnelle, les garanties internes, le comportement de redémarrage des sous-systèmes, l'explication publique et le séquencement de la récupération. Les clients contrôlaient si leurs propres systèmes supposaient une seule région, s'ils utilisaient la réplication inter-régions, s'ils mettaient en cache les actifs publics critiques, s'ils pouvaient mettre en file d'attente les écritures et si leurs propres pages de statut restaient disponibles quand S3 ne l'était pas.

Le dossier public ne prouve pas chaque impact client. Il n'établit pas de conclusion juridique sur les dommages, la négligence, les crédits de service ou l'échec d'approvisionnement. Il montre qu'une petite action opérationnelle à l'intérieur d'un fournisseur cloud peut devenir un test de responsabilité public lorsque le service affecté est un fondement commun. La leçon correcte n'est pas simplement « éviter le cloud » ou « utiliser plus de cloud.

» La leçon correcte est plus précise: identifier les sous-systèmes et régions du fournisseur qui peuvent désactiver les workflows clients, préserver la preuve de la façon dont le fournisseur communique pendant l'incident, et concevoir des chemins de repli qui survivent à la même dépendance qui a causé la panne.

Le résumé post-événement identifie la surface de contrôle

La caractéristique la plus précieuse du résumé post-événement d'AWS de 2017 est qu'il nomme la surface de contrôle. L'événement initiateur était une commande. La commande a été exécutée par un opérateur autorisé. La commande faisait partie d'un playbook. La commande était destinée à retirer une petite quantité de capacité. La commande a plutôt retiré plus de capacité que prévu. Cette chaîne est un objet de gouvernance.

Elle demande si les outils rendaient l'action dangereuse trop facile, si les garde-fous imposaient un plancher de capacité minimale, si l'entrée humaine pouvait être validée avant exécution, si le retrait par étapes limitait le rayon d'explosion et si les hypothèses de récupération avaient été testées contre un redémarrage complet.

Le résumé d'AWS a également identifié des thèmes de réparation. Il a indiqué que S3 avait ajouté des garanties pour que la capacité puisse être retirée plus lentement et que les outils empêcheraient que la capacité ne tombe en dessous d'un niveau minimum requis. Il a indiqué qu'AWS audait d'autres outils opérationnels qui retirent de la capacité et apportait des modifications pour accélérer la récupération des sous-systèmes critiques. Il a également indiqué que S3 apportait des modifications pour partitionner davantage le sous-système d'index. Ce ne sont pas des détails mineurs de relations publiques.

Ce sont la différence entre un fournisseur disant « nous sommes désolés » et un fournisseur nommant la classe de contrôle qui a échoué.

La preuve du fournisseur est encore incomplète d'un point de vue externe. Le public ne peut pas voir la commande exacte, la validation pré-exécution, la chaîne d'approbation, l'état des alarmes, l'interface de l'opérateur, les outils de rollback, la topologie des sous-systèmes ou la revue interne. Le résumé public ne prouve pas comment chaque réparation interne a été testée. Il ne prouve pas l'effet exact sur chaque client ou chaque service AWS dépendant.

Mais le résumé donne suffisamment pour classer la panne: outils opérationnels, capacité des sous-systèmes, état de préparation au redémarrage, contrôle du rayon d'explosion et communication sur l'état de santé des services.

Cette classification est le point de départ de la diligence raisonnable du client. Un client qui dépend de S3 ne devrait pas seulement demander si S3 est durable. Il devrait demander comment sa propre charge de travail se comporte lorsque les opérations GET, LIST, DELETE ou PUT de S3 se dégradent séparément. Il devrait demander si la charge de travail peut tolérer une disponibilité en lecture avec une indisponibilité en écriture, ou une récupération en écriture avant le dégagement de l'arriéré.

Il devrait demander si l'application réessaie en toute sécurité, si les réessais peuvent amplifier la charge, si les versions d'objets sont protégées contre l'écrasement accidentel, si la mise en file d'attente préserve l'ordre et si les utilisateurs sont informés de ce qui s'est passé. La surface de contrôle du fournisseur devient la liste de contrôle de preuves du client.

Les pages produit et documentation publiques actuelles d'AWS S3 fournissent le contexte moderne pour cette liste de contrôle. La page de service S3 àhttps://aws.amazon.com/s3/décrit la famille de services et le cadrage de durabilité. Le guide utilisateur S3 àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.htmldonne le point d'entrée opérationnel pour les buckets, les objets, les classes de stockage, les contrôles d'accès et les fonctionnalités. La documentation sur la réplication S3 àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html, la documentation sur le versionning àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.htmlet la documentation sur Entité Lock àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/entité-lock.htmlne sont pas des conclusions sur ce qu'un client spécifique a utilisé en 2017. Elles sont pertinentes car elles définissent les contrôles côté client pour la résilience, la protection contre les changements et la preuve de récupération.

La distinction entre le contrôle du fournisseur et le contrôle du client est facile à brouiller lors d'une panne. Les clients peuvent et doivent concevoir pour la panne régionale, les lectures mises en cache, les budgets de réessai, la contre-pression et la continuité inter-régions lorsque le cas commercial le justifie. Mais ces contrôles clients n'effacent pas la responsabilité du fournisseur pour des outils opérationnels sûrs. Les garanties de retrait de capacité côté fournisseur et la conception multi-région côté client sont des voies de preuve différentes. Un examen sérieux post-incident devrait les garder séparées.

Il ne devrait pas utiliser les faiblesses architecturales du client pour éviter d'examiner les contrôles du fournisseur, et il ne devrait pas utiliser les contrôles du fournisseur pour excuser la concentration de dépendance non testée d'un client.

Cette séparation est également utile pour l'approvisionnement. Un acheteur cloud n'a pas besoin de chaque détail interne d'AWS pour poser de meilleures questions. Il peut demander si l'application a un inventaire des dépendances, si l'entreprise sait quelles fonctions dépendent de S3 dans une seule région, si l'organisation s'abonne à AWS Health et aux mises à jour de l'état de santé des services, si sa page de statut public dépend de la même région, si les objets critiques sont répliqués ou mis en cache, et si les chemins d'écriture peuvent être mis en file d'attente sans corrompre l'état. Ce sont des questions pratiques.

Elles découlent directement de la surface de contrôle que le résumé d'AWS a exposée.

La communication sur l'état de santé des services a fait partie de la panne

L'incident de 2017 est également mémorable car la communication sur l'état de santé des services est elle-même devenue une partie de l'histoire de la responsabilité. Le résumé d'AWS a indiqué que le tableau de bord de l'état de santé des services AWS a été affecté car sa console administrative utilisait S3 dans la région touchée, ce qui a retardé les mises à jour du statut des services individuels. Ce détail est plus important qu'un inconvénient de tableau de bord. Un système de statut est un contrôle opérationnel.

Si le contrôle dépend du même service qui est dégradé, le client perd un canal de décision clé au moment où il en a le plus besoin.

La page de statut AWS Health actuelle àhttps://health.aws.amazon.com/health/statuset le point d'entrée du tableau de bord de l'état de santé des services AWS hérité àhttps://status.aws.amazon.com/ne sont donc pas seulement des liens informatifs. Ils représentent le canal public par lequel de nombreux clients commencent la classification des incidents. Un client peut voir des téléchargements échoués, des timeouts, des taux d'erreur élevés, des actifs vides, des déploiements bloqués ou des tableaux de bord cassés. La première question est de savoir si le problème est local, côté fournisseur, régional, global, lié à l'authentification, lié au réseau ou un bug d'application aval. Si le canal de statut du fournisseur est lent, trop large ou lui-même dégradé, les clients perdent du temps sur le mauvais diagnostic.

La communication de statut doit répondre à plusieurs tests pratiques. Elle doit nommer le service et la région affectés. Elle doit distinguer les classes d'opérations lorsque possible. Elle doit montrer si le fournisseur enquête, atténue, surveille ou a résolu. Elle doit décrire les services dépendants lorsque ces dépendances sont matérielles. Elle doit rester disponible via un chemin qui ne partage pas la dépendance défaillante. Elle doit préserver l'historique des incidents pour une réconciliation ultérieure.

Elle ne doit pas forcer les clients à compter sur des rumeurs, des fragments de réseaux sociaux ou des plaintes d'utilisateurs comme preuve principale.

AWS a reconnu une partie de ce problème dans le résumé post-événement en indiquant qu'il avait modifié le tableau de bord de l'état de santé des services afin qu'il puisse être mis à jour dans plusieurs régions AWS. C'est une revendication de réparation concrète. Cela ne prouve pas une communication future parfaite, mais cela identifie la classe de panne: l'administration du statut ne devrait pas être verrouillée derrière la même dépendance régionale dégradée. C'est une leçon générale pour les clients également.

Si la propre page de statut public d'une organisation, la base de connaissances du support client, le chat d'incident ou le tableau de bord de reporting exécutif dépend entièrement de la même région et du même service cloud que le produit, l'organisation peut perdre sa voix pendant la panne.

Le problème de communication affecte également l'évaluation de la gravité. Un fournisseur peut dire qu'un service est dégradé du point de vue de sa propre télémétrie. Un client peut vivre une interruption complète car l'opération affectée se trouve dans le chemin critique. Un autre client peut voir un impact limité car il sert des actifs mis en cache ou met en file d'attente les écritures. Un bon enregistrement de statut ne devrait pas prétendre connaître chaque workflow client, mais il devrait fournir suffisamment d'informations pour que les clients puissent prendre rapidement leur propre décision de gravité.

L'incident S3 montre pourquoi le détail au niveau de l'opération compte: la lecture, la liste, la suppression et le placement d'écriture n'ont pas eu le même moment de récupération.

Pour les petites et moyennes entreprises, la spécificité du statut peut décider si les procédures de continuité sont utilisées du tout. Un petit détaillant, une école, un cabinet de santé, un site de médias local ou une startup logicielle peut ne pas avoir une grande équipe d'exploitation. Il peut compter sur les pages de statut du fournisseur et les contrôles de santé des services gérés pour décider s'il faut suspendre les déploiements, changer la diffusion de contenu, avertir les clients, retarder un lancement ou arrêter les tempêtes de réessais.

Si l'enregistrement public de statut est tardif ou vague, le coût du diagnostic se déplace vers le client. Ce transfert de coût fait partie de la question de responsabilité même lorsque personne ne l'a voulu.

Pour les utilisateurs du secteur public, les enjeux peuvent être différents. Un site web d'agence publique, un flux de données, un portail d'approvisionnement, une archive d'informations d'urgence, un service de données ouvertes ou un système d'entrepreneur peut dépendre du stockage objet. Toutes ces utilisations ne sont pas critiques. Mais lorsqu'un service est public, l'organisation a besoin d'un chemin de communication qui survit à la dégradation du fournisseur. Une mise à jour de statut du fournisseur aide, mais l'agence a toujours besoin de sa propre explication destinée aux citoyens et de son repli.

L'événement AWS rappelle que la continuité du secteur public devrait inclure l'ingestion du statut cloud, l'indépendance des communications locales et la preuve des services vérifiés et non affectés.

Le repli client doit être testé contre la dépendance en mode commun

Le repli est souvent décrit trop cavalièrement. Un client peut dire qu'il peut utiliser un autre bucket, une autre région, un autre fournisseur, un cache local, un réseau de diffusion de contenu ou des opérations manuelles. La question de responsabilité est de savoir si ce repli survit à la même panne. Un bucket différent dans la même région affectée peut ne pas aider. Un objet répliqué peut ne pas aider si l'application écrit dans une région et n'a pas de chemin de lecture testé ailleurs.

Un cache de diffusion de contenu peut aider pour les actifs publics mais pas pour les nouveaux téléchargements, les données privées, les opérations de liste ou l'état des workflows. Un second fournisseur peut ne pas aider si la synchronisation des données, l'identité, l'approbation de conformité et le routage d'application n'ont jamais été testés.

La documentation S3 fournit de nombreux outils de résilience côté client, mais les outils deviennent des contrôles seulement lorsqu'ils sont implémentés, testés et gouvernés. Les points d'accès multi-régions àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.htmlpeuvent aider à acheminer les requêtes entre régions pour certaines architectures. La documentation sur le contrôle du temps de réplication àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.htmlexplique une fonctionnalité de réplication avec des attentes temporelles. S3 Storage Lens àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/storage_lens.htmlpeut soutenir la visibilité sur l'utilisation du stockage et l'activité. La documentation sur les notifications d'événements àhttps://docs.aws.amazon.com/AmazonS3/latest/userguide/EventNotifications.htmlpeut aider à intégrer les événements d'objets dans les workflows. Aucun de ces documents ne prouve qu'un client avait de la résilience en 2017. Ils montrent le vocabulaire de contrôle qu'un client devrait maintenant appliquer.

La clé est l'analyse en mode commun. Si l'application dépend de S3 pour les actifs, les artefacts de déploiement, les journaux et sa propre page de statut, ce ne sont pas des risques séparés. C'est un groupe de dépendances. Si l'organisation utilise S3 pour stocker les fichiers nécessaires à la réponse aux incidents, la panne peut ralentir la réparation. Si une copie de sauvegarde se trouve dans la même région et est régie par les mêmes identifiants, elle peut ne pas être assez indépendante.

Si le client compte sur un service AWS qui dépend lui-même de S3 dans la même région, changer uniquement la couche applicative peut ne pas restaurer le workflow. L'inventaire des dépendances doit suivre le chemin réel, pas les noms de fournisseurs dans un tableur d'approvisionnement.

Les tests devraient inclure la panne spécifique à l'opération. Les utilisateurs peuvent-ils toujours lire le contenu critique si PUT échoue? L'entreprise peut-elle mettre en file d'attente les écritures pour plus tard sans perdre l'ordre ou l'état de traitement en double? L'application peut-elle se dégrader gracieusement si LIST est lent ou indisponible? Le personnel de support peut-il distinguer le contenu manquant du nouvel téléchargement échoué? Le site peut-il afficher un message utile si les actifs privés sont indisponibles? Le déploiement peut-il s'arrêter sans corrompre l'état de production?

Les journaux de facturation, d'analyse et de conformité peuvent-ils être réconciliés après l'incident? Ces questions ne sont pas exotiques. Elles découlent de la séquence d'opérations dans le résumé AWS.

Le comportement de réessai mérite une attention particulière. Les clients de systèmes distribués réessayent souvent après des erreurs, et les réessais peuvent être utiles. Ils peuvent aussi amplifier la charge, augmenter le coût, créer un travail en double et cacher l'impact utilisateur. L'article de l'AWS Builders Library sur les timeouts, les réessais et le backoff avec jitter àhttps://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/est pertinent car il explique comment la conception des réessais peut prévenir la surcharge et les tempêtes de réessais synchronisées. L'article sur l'évitement du repli dans les systèmes distribués àhttps://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/est également pertinent car il avertit que les chemins de repli peuvent être peu fiables s'ils sont rarement exercés. Ce sont des références d'ingénierie AWS actuelles, pas des conclusions sur l'incident de 2017. Elles sont utiles car elles correspondent au modèle de panne que les clients doivent concevoir.

La même chose s'applique au rayon d'explosion. L'article de l'AWS Builders Library sur la réduction de la portée de l'impact avec une architecture cellulaire àhttps://aws.amazon.com/builders-library/reducing-scope-of-impact-with-cell-based-architecture/et l'article sur la stabilité statique utilisant les zones de disponibilité àhttps://aws.amazon.com/builders-library/static-stability-using-availability-zones/donnent un langage public pour concevoir des systèmes dont les pannes sont contenues. S3 lui-même est un service régional, et les architectures clients varient, mais le concept général de responsabilité est clair: un système qui dépend d'un composant partagé sans limite de confinement testée peut transformer un incident fournisseur en un incident client beaucoup plus large.

Cela ne signifie pas que chaque client devrait construire des systèmes actif-actif multi-régions coûteux. Le coût, la complexité, la cohérence des données, la conformité, la latence, l'expertise du personnel et le risque opérationnel comptent tous. Un site web à faible risque peut accepter un retard. Une page de service public critique, un workflow de support de paiement ou un chemin de distribution de logiciel peut nécessiter des contrôles plus forts. Le dossier de responsabilité devrait correspondre à la criticité commerciale.

Ce qu'il ne devrait pas faire est de prétendre qu'une dépendance de service géré mono-région est la même qu'une conception de continuité testée.

Les services AWS dépendants ont rendu le rayon d'explosion visible

La perturbation S3 a également affecté d'autres services AWS qui dépendaient de S3 dans US-EAST-1. Le résumé d'AWS a indiqué que certains services ont été affectés et qu'ils se sont rétablis après la récupération des opérations S3. Cela importe car les clients cloud assemblent souvent des services du même fournisseur en supposant que les services gérés échouent suffisamment indépendamment pour les objectifs clients. Parfois c'est le cas. Parfois ils partagent une dépendance qui n'est pas évidente jusqu'à un incident. Le rôle de S3 dans l'écosystème AWS a fait de l'événement de 2017 une leçon sur la cartographie des dépendances de service.

Le matériel général sur l'architecture et les opérations d'AWS aide à cadrer cela. Le pilier de fiabilité AWS Well-Architected àhttps://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.htmlmet l'accent sur la conception de la charge de travail pour la récupération après panne, la mise à l'échelle et la gestion des changements. Les conseils de résilience AWS àhttps://aws.amazon.com/resilience/fournissent un langage au niveau du fournisseur autour de la résilience. L'article de la Builders Library sur la mise en œuvre des contrôles de santé àhttps://aws.amazon.com/builders-library/implementing-health-checks/est pertinent car les contrôles de santé ne sont utiles que s'ils reflètent les dépendances qui décident de l'expérience utilisateur réelle. Un service peut sembler sain à un niveau tout en échouant à l'opération de stockage dont l'utilisateur a besoin.

La cartographie des dépendances doit être concrète. Un client devrait savoir si les actifs de l'application, les journaux, les sauvegardes, les packages de déploiement, les entrées de machine learning, les pièces jointes de support, les téléchargements utilisateur, les sites web statiques, les téléchargements publics et les travaux d'analyse reposent tous sur S3 dans une région. Il devrait savoir quels services AWS gérés dans son architecture utilisent S3 ou sont affectés par la disponibilité de S3. Il devrait savoir quelles dépendances sont visibles via sa propre télémétrie et lesquelles ne sont visibles que via le statut du fournisseur.

Il devrait savoir quel processus métier s'arrête si une seule opération de stockage objet est indisponible.

Ce type de cartographie est souvent moins glamour que l'architecture multi-région. Il est aussi plus immédiatement utile. De nombreux incidents commencent par la confusion: les utilisateurs signalent des pannes, les ingénieurs voient des erreurs éparses, les tableaux de bord ne sont pas d'accord et les équipes poursuivent les symptômes. Une carte des dépendances raccourcit cette période. Elle indique à l'équipe que le chargement d'image échoué, les exportations cassées, les pannes de déploiement et l'analyse bloquée peuvent partager une cause. Elle empêche également la réaction excessive.

Si la carte montre qu'un système de support client ne dépend pas du chemin S3 affecté, l'organisation peut maintenir ce service en fonctionnement et préserver la communication client.

Du côté du fournisseur, il y a un devoir parallèle. Un fournisseur cloud devrait comprendre quels services internes dépendent d'un service critique et comment séquencer la récupération. En 2017, les sous-systèmes d'index et de placement de S3 ont dû récupérer avant que le comportement normal des requêtes ne revienne. D'autres services AWS ont ensuite dû effacer leurs propres effets de dépendance. Les clients publics ne peuvent pas voir tout ce séquencement, donc le statut du fournisseur et le résumé post-événement portent un poids supplémentaire. Ils sont le substitut public à la visibilité de l'infrastructure.

La preuve publique ne doit pas être surinterprétée. Elle ne dit pas à un observateur externe quel service AWS exact avait quelle dépendance interne exacte à quelle minute, ou quel client a été le plus affecté. Mais elle prouve la classe du problème. Un écosystème cloud peut avoir des dépendances internes partagées qui importent pour la continuité client. C'est suffisant pour justifier des examens de dépendance plus solides à la fois par les fournisseurs et les acheteurs.

Les preuves de réparation doivent être traitées comme une revendication de contrôle

Le résumé post-événement d'AWS incluait des revendications de réparation: retrait de capacité plus lent, garanties d'outils pour empêcher la capacité de tomber en dessous des niveaux minimums, audits des outils opérationnels, travail de récupération plus rapide pour les sous-systèmes critiques, partitionnement supplémentaire du sous-système d'index et modifications du tableau de bord de l'état de santé des services. Ces revendications doivent être lues comme des revendications de contrôle. Chacune implique un objectif de contrôle testable. Un retrait plus lent réduit la chance d'un effondrement soudain de capacité.

Les garanties de capacité minimale réduisent les entrées dangereuses de l'opérateur. Les audits d'outils recherchent des risques similaires ailleurs. Le travail de récupération teste les hypothèses de redémarrage. Le partitionnement réduit le rayon d'explosion. L'indépendance du tableau de bord de statut améliore la communication.

Le public ne reçoit pas la preuve complète des tests pour ces contrôles. C'est normal pour les opérations internes d'un fournisseur. Mais les clients et les auditeurs peuvent encore utiliser les revendications pour façonner leur propre examen. Si un fournisseur dit que les outils de retrait de capacité imposent désormais des limites, un acheteur peut demander comment le fournisseur communique les futurs incidents opérationnels et si un langage de garantie similaire apparaît dans les résumés post-événement.

Si un fournisseur dit qu'un sous-système est davantage partitionné, les clients peuvent demander si le statut du service distingue maintenant les régions et les classes d'opérations assez clairement. Si un fournisseur dit que l'outillage du tableau de bord a changé, les clients peuvent tester si leur propre surveillance de statut voit les mises à jour via plusieurs canaux.

L'article de l'AWS Builders Library sur l'automatisation des déploiements sûrs et sans intervention àhttps://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/est pertinent car il montre le vocabulaire d'ingénierie plus large d'AWS autour de la sécurité des changements, de l'automatisation, du temps de cuisson, des alarmes et du rollback. L'incident S3 de 2017 n'était pas un problème de déploiement normal orienté client, mais il partage la même logique de gouvernance: les changements dangereux ont besoin de contrôles de sécurité automatisés, d'effet par étapes, de détection rapide et de rollback ou récupération testés. Un playbook manuel ne devient pas sûr simplement parce qu'il est établi. Il devient plus sûr lorsque les outils imposent les contraintes que les humains pourraient autrement manquer.

Les preuves de réparation devraient également être spécifiques au client. Un client ne devrait pas terminer son examen par « AWS a réparé S3. » Il devrait demander quelles applications internes ont échoué, quels utilisateurs ont été affectés, quels réessais ont été exécutés, quelles données ont été retardées, quels messages de statut ont été envoyés, quelles dépendances ont été nouvellement cartographiées et quels changements architecturaux ont été effectués ou rejetés. Certains clients peuvent raisonnablement décider qu'aucun changement majeur n'est justifié.

D'autres peuvent choisir la réplication inter-régions, la mise en cache des actifs publics, l'hébergement de statut indépendant, la conception de file d'attente ou des procédures opérationnelles alternatives. Le point n'est pas que chaque incident nécessite une redondance maximale. Le point est que la décision devrait être fondée sur des preuves.

Les conseils d'administration devraient être particulièrement sceptiques quant à la clôture vague. « Le fournisseur a récupéré » n'est pas un contrôle local. « Nous savons maintenant que les images de produits, les artefacts de déploiement et les pages de statut dépendaient tous d'une région S3, et nous avons déplacé la page de statut et les actifs critiques vers un chemin indépendant » est un contrôle. « Nous avons testé la mise en file d'attente d'écriture pendant l'indisponibilité de PUT S3 » est un contrôle. « Nous nous sommes abonnés à AWS Health et avons construit une corrélation locale pour les erreurs d'opération S3 » est un contrôle.

« Nous avons accepté le risque résiduel pour les téléchargements non critiques » est une décision de gouvernance. L'incident de 2017 donne aux organisations le vocabulaire pour faire ces distinctions.

Le dossier de preuves client devrait survivre à la même panne

La réponse client la plus utile après un incident de type S3 est un dossier de preuves qui peut survivre à l'incident qu'il décrit. Cela signifie que l'organisation ne devrait pas conserver toutes les procédures d'incident, les listes de contacts, les brouillons de statut, les diagrammes architecturaux, les scripts de récupération et les cartes de dépendances actuelles uniquement dans le service ou la région affectée. Si les preuves nécessaires pour coordonner la réponse sont stockées dans le même chemin de stockage objet qui est en panne, l'incident supprime à la fois le service et la carte.

Une conception de continuité mature conserve un petit ensemble de preuves d'incident dans un chemin séparé avec des règles d'accès connues.

Ce dossier devrait commencer par des étiquettes de dépendances qu'un non-spécialiste peut comprendre. « S3 » est trop large. Un meilleur enregistrement sépare les actifs publics statiques, les téléchargements clients, les pièces jointes privées, les artefacts de déploiement, les journaux d'application, les exportations de sauvegarde, les entrées d'analyse, les ensembles de données de machine learning, les archives de conformité et les propres communications de statut de l'organisation.

Chaque dépendance devrait nommer la région, le type d'opération, le propriétaire métier, le délai acceptable, la route de repli et la preuve nécessaire après la récupération. Cela rend l'examen des incidents opérationnel plutôt que symbolique.

Le dossier devrait également préserver le temps. Lors d'une panne, les équipes se souviennent souvent de la première plainte, de la première alerte, de la première mise à jour du fournisseur, de la première solution de contournement et du moment où les utilisateurs ont arrêté de se plaindre. Ces souvenirs sont utiles mais faibles. Un enregistrement plus fort préserve les horodatages des journaux d'application, des pages de statut du fournisseur, des événements AWS Health lorsqu'ils sont disponibles, des tickets de support, du chat d'incident, des avis clients et des vérifications post-récupération.

Les horodatages n'ont pas besoin d'être parfaits pour être précieux. Ils doivent être assez bons pour montrer si la détection locale était tardive, si la communication du fournisseur était tardive, si l'activation du repli était retardée et si la récupération a été vérifiée plutôt que supposée.

Le dossier devrait distinguer l'intégrité des données de la continuité du service. L'incident S3 de 2017 était une perturbation de service, pas un registre de vol de données public. Cela ne signifie pas que chaque risque client était le même. Certains clients avaient besoin de savoir si les écritures retardées étaient réessayées, si les requêtes en double créaient des objets répétés, si des objets obsolètes étaient servis, si des journaux manquaient, si des artefacts de déploiement étaient partiellement téléchargés ou si des transactions orientées utilisateur nécessitaient une réconciliation.

Un service peut se rétablir alors qu'un client a encore du travail de nettoyage. Traiter cela comme un seul événement cache le travail qui protège réellement les utilisateurs.

Enfin, le dossier devrait enregistrer les contrôles rejetés. Toutes les organisations n'adopteront pas une conception active-active multi-région. Certaines décideront que le coût et la complexité dépassent la valeur pour un workflow à faible criticité. C'est un choix de gouvernance légitime s'il est explicite. Ce qui est faible est l'acceptation silencieuse: pas de carte des dépendances, pas de test, pas de propriétaire, pas de repli et aucun enregistrement de pourquoi le risque a été accepté. La perturbation S3 de 2017 reste utile car elle donne aux organisations un mode de défaillance concret sur lequel baser ces décisions.

Le dossier de preuves devrait également inclure une étape de réconciliation de récupération. Après le retour de S3 à un fonctionnement normal, un client doit encore prouver que ses propres écritures mises en file d'attente, lectures retardées, téléchargements échoués, rapports partiels, actifs statiques et workflows orientés utilisateur se sont stabilisés dans un état correct. La récupération du fournisseur ne prouve pas automatiquement la récupération du client.

Un arriéré peut se vider dans le désordre, une boucle de réessai peut créer des objets en double, une page mise en cache peut cacher un actif obsolète, et un workflow de support peut continuer à échouer après que la dépendance principale est saine. L'étape de réconciliation devrait nommer les enregistrements qui prouvent la clôture locale: profondeur de file d'attente, rejeu de travaux échoués, comptages d'objets, sommes de contrôle d'écriture lorsque pertinent, tendances des plaintes utilisateur, vérification des artefacts de déploiement et clôture des messages de statut. Cette preuve protège le client de déclarer victoire trop tôt.

Pour les fournisseurs, la même idée s'applique en interne. Lorsqu'un sous-système critique récupère, les services dépendants peuvent encore avoir besoin de travail de rattrapage, de reconstruction de cache, de lissage de réessai ou de contrôles de santé différés visibles par le client. Un résumé post-événement qui distingue la récupération du sous-système fournisseur de la récupération du service dépendant donne aux clients un modèle de restauration plus réaliste. Il aide également les clients à concevoir leurs propres tests. La leçon de responsabilité est que la récupération de dépendance est une séquence, pas un interrupteur.

Dossier de preuves pour le lecteur

Cet article utilise les sources publiques suivantes comme dossier de preuves pour la perturbation de S3 US-EAST-1, la communication de statut AWS, le contexte du service S3, les contrôles de résilience côté client et la conception de panne de système distribué. Les sources rédigées par le fournisseur sont traitées comme une preuve de ce qu'AWS a dit publiquement et de la façon dont AWS documente les services actuels. Elles ne sont pas traitées comme une preuve indépendante de chaque journal privé, impact client, remède contractuel ou résultat d'audit interne.

Questions pour le conseil d'administration

Un conseil d'administration ou un comité des risques ne devrait pas seulement demander si AWS S3 a eu une panne en 2017. Il devrait demander quels processus métier actuels dépendent de S3, quelles régions ils utilisent, quelles opérations sont critiques, quels actifs ou workflows ont des replis indépendants, quels canaux de statut restent disponibles lors d'un incident cloud et quelle télémétrie locale peut prouver l'impact et la récupération. La réponse devrait être datée, testable et liée à la criticité métier.

L'examen devrait séparer cinq voies de preuve. La première voie est la preuve du fournisseur: le résumé post-événement d'AWS, les canaux de statut actuels et le matériel public de résilience. La deuxième voie est la preuve applicative: les journaux locaux, les erreurs de requête, les opérations affectées, le comportement de file d'attente, l'impact utilisateur et la clairance de l'arriéré. La troisième voie est la preuve architecturale: réplication, mise en cache, conception multi-région, politique de réessai et communications indépendantes.

La quatrième voie est la preuve de gouvernance: qui a accepté le risque résiduel, qui possède les tests de repli et qui décide quand un service est restauré localement. La cinquième voie est la communication client: ce qui a été dit aux utilisateurs, agences, employés ou contreparties et quand.

Pour ce cas spécifique, la question directrice reste: qui avait le contrôle pratique sur les commandes opérationnelles, les garanties de capacité des sous-systèmes, la concentration régionale, la cartographie des dépendances de service, l'architecture de repli client, la visibilité du statut et la preuve que la récupération du stockage objet a restauré les services dépendants? Une réponse complète devrait nommer les contrôles AWS, les contrôles clients, les lacunes de preuve, les publics affectés et la preuve de réparation qui changerait une future décision d'achat cloud ou d'architecture.