Le bug latent de Fastly et la responsabilité d'un edge CDN concentré

Résumé

• Fastly indique qu'un déploiement logiciel commencé le 12 mai 2021 a introduit un bug latent. Le 8 juin, un client a effectué un changement de configuration valide contenant les conditions inhabituelles qui l'ont activé. La défaillance qui en a résulté a provoqué des erreurs sur 85 % du réseau de Fastly. Fastly a détecté la perturbation en une minute et a rétabli 95 % du réseau en 49 minutes.
• L'incident n'a pas été publiquement identifié comme une fuite de route BGP, une panne de peering, un manque de transit, une cyberattaque ou une action client invalide. Des observations indépendantes ont révélé des erreurs applicatives tandis que la couche réseau semblait normale. Cette distinction importe: un CDN peut posséder une diversité physique et de transport étendue tout en restant corrélé par un logiciel commun, une sémantique de configuration, des systèmes de déploiement et des contrôles de rétablissement.
• Les résultats pour les clients dépendaient de l'architecture et de la préparation opérationnelle. GOV.UK disposait d'un CDN secondaire continuellement disponible et d'un processus de basculement documenté, mais la propagation DNS et les compromis du mode dégradé ont tout de même pris du temps. GitLab n'avait qu'une dépendance partielle pour son service principal, mais une dépendance externe de paquet a entravé le pipeline ordinaire que les ingénieurs souhaitaient utiliser pour contourner le CDN défaillant.
• La responsabilité se situe donc des deux côtés de la frontière de service sans être égale. Fastly contrôlait le code de la plateforme, les tests, le confinement du déploiement, l'isolation des défaillances globales et le rétablissement du fournisseur. Les clients contrôlaient la cartographie des dépendances, la livraison alternative, la capacité de l'origine, la préparation DNS et des certificats, les outils de rétablissement et la tolérance à l'impact commercial. Les conseils d'administration et les régulateurs devraient exiger des preuves testées des deux domaines, et non accepter un pourcentage de haute disponibilité ou un contrat avec un second fournisseur comme preuve de résilience.

Un changement valide, un domaine de défaillance global

À 09h47 UTC le 8 juin 2021, une grande partie du web public a commencé à renvoyer des erreurs. Les sites d'actualités, les services commerciaux, les plateformes de développement, les services de streaming et le site web du gouvernement central britannique figuraient parmi les victimes visibles. L'événement ressemblait, de l'extérieur, à de nombreuses organisations sans lien qui échouent simultanément. En termes d'infrastructure, ils étaient liés: les requêtes vers ces services convergeaient vers le réseau de diffusion de contenu de Fastly.

Le résumé de la panne du 8 juin de Fastly fournit le récit causal central. Un déploiement logiciel commencé le 12 mai a introduit un bug. Il est resté dormant jusqu'à ce qu'un client pousse un changement de configuration valide dans les conditions spécifiques nécessaires à son déclenchement. Fastly indique que 85 % de son réseau a alors renvoyé des erreurs. La surveillance a identifié la perturbation mondiale à 09h48, une minute après le début. La première mise à jour publique du statut a suivi à 09h58.

Les ingénieurs ont identifié la configuration du client à 10h27, le rétablissement a commencé à 10h36, et 95 % du réseau fonctionnait normalement dans les 49 minutes suivant le début. Fastly a marqué l'incident comme atténué à 12h35 et résolu à 12h44, puis a commencé à déployer un correctif permanent à 17h25.

L' incident de statut Fastly archivé ajoute un détail opérationnel qu'une simple chronologie binaire omet. Alors que le service revenait, les clients pouvaient subir une charge d'origine plus élevée et un taux de succès du cache plus faible. Le rétablissement de l'edge n'était pas nécessairement le rétablissement de l'ensemble du service client. Les caches devaient se réchauffer, les requêtes normalement servies à l'edge pouvaient atteindre les origines en volume inhabituel, et chaque dépendance propre du client devait se stabiliser. La restauration du fournisseur était une étape critique, pas la fin universelle de l'impact.

Fastly s'est excusé et a déclaré que l'incident était large et grave. Il a également fait une déclaration de responsabilité précieuse: bien que le déclencheur dépende de conditions spécifiques, le fournisseur aurait dû l'anticiper. Cette phrase rejette l'explication la plus facile mais la moins utile, qu'un client a changé quelque chose et donc a causé la panne. L'action du client était valide. La plateforme l'a acceptée. La réponse catastrophique provenait du logiciel du fournisseur et de la manière dont sa défaillance s'est propagée.

Le récit public reste délibérément de haut niveau. Il ne divulgue pas le sous-système affecté, la combinaison exacte de configuration, le défaut logiciel, la couverture de test interne, la topologie de déploiement ou le mécanisme par lequel la configuration d'un client a produit des erreurs sur des services clients sans lien. Ces omissions peuvent être raisonnables dans un rapport public court, en particulier lorsque la confidentialité des clients et la sécurité de la plateforme sont en jeu. Elles limitent également l'assurance externe. Le public peut vérifier la chronologie par rapport à l'observation;

il ne peut pas déterminer indépendamment du seul article de Fastly si le correctif permanent a retiré uniquement le déclencheur, réparé le défaut sous-jacent ou modifié l'architecture qui a permis un rayon d'explosion aussi large.

Cette lacune devrait façonner les conclusions. Le dossier soutient un bug latent, un déclencheur valide, un comportement d'erreur global, une détection rapide et une atténuation relativement rapide. Il ne soutient pas une théorie détaillée sur le code défectueux ou la conduite d'un ingénieur individuel. L'analyse de responsabilité devrait rester au niveau du contrôle: conception des tests, isolation de la configuration, sécurité du déploiement, confinement des défaillances globales, observabilité, autorité en cas d'incident et preuves fournies aux clients et aux administrateurs.

La chronologie sépare le risque latent de la perturbation active

L'incident a duré moins d'une heure pour de nombreux utilisateurs, mais la fenêtre de contrôle pertinente a commencé près de quatre semaines plus tôt. Un défaut peut être opérationnellement présent sans produire de symptômes visibles. C'est ce qui rend les défauts latents difficiles et ce qui rend l'assurance de version plus que de surveiller les premières minutes après le déploiement.

Cette séquence montre pourquoi l'expression courante « un changement de configuration a causé la panne » est trop vague. Les changements de configuration se produisent constamment sur une plateforme edge dont la valeur inclut la programmabilité. Une configuration valide peut être le stimulus final dans une chaîne causale, tout comme une requête normale peut déclencher un défaut du serveur. Le propriétaire du contrôle est la partie capable de rendre les entrées valides sûres, de rejeter les combinaisons qu'elle ne peut pas traiter, ou de confiner une défaillance au service qui les a fournies.

Il serait également faux de prétendre que le déclencheur était sans importance. L'analyse du déclencheur importe pour la reproduction, la détection, le rollback et les garanties futures. Le point est que l'attribution du déclencheur et l'attribution de la responsabilité répondent à des questions différentes. Le client a fourni la condition. Fastly a fourni le comportement logiciel et l'environnement de production partagé. Le propre récit de Fastly accepte que la condition aurait dû être anticipée.

L'intervalle dormant est tout aussi important. Une version qui survit plusieurs semaines a accumulé de l'exposition en production, pas une preuve contre des états non testés. Les plateformes configurables font face à un problème combinatoire: le logiciel versionné interagit avec la VCL du client, les en-têtes, les origines, les règles de cache, le shielding, les contrôles d'accès, les feature flags et la logique edge. Tester exhaustivement chaque combinaison peut être impossible.

Cela rend le confinement, le déploiement progressif, la vérification des invariants, le fuzzing, les corpus de configuration représentatifs, l'isolation au moment de l'exécution et le rollback automatique rapide plus importants, pas moins.

C'était une défaillance applicative, pas un effondrement de routage

La panne appartient à une discussion sur le peering et le transit car un CDN est à la fois une activité d'interconnexion et une plateforme logicielle. Elle ne devrait pas être réécrite comme un incident de peering ou de transit. Les preuves pointent dans l'autre direction.

L' observation réseau contemporaine de Kentik a vu l'événement commencer à 09h49 UTC et a mesuré une baisse d'environ 75 % du trafic provenant de Fastly avant que le trafic ne commence à revenir à 10h39. L' analyse couche par couche de Cisco ThousandEyes a observé des erreurs de service alors que les chemins réseau continuaient de fonctionner et a décrit différents modèles de rétablissement des clients alors que le trafic se déplaçait entre les fournisseurs de livraison.

Une analyse ultérieure du produit ThousandEyes a énoncé directement la distinction: des erreurs 503 apparaissaient au niveau applicatif tandis que la couche réseau semblait normale.

La propre politique de peering de Fastly identifie AS54113 comme le système autonome par lequel il échange du trafic avec les fournisseurs de services Internet et les réseaux de contenu. Sa documentation sur les POP mondiaux explique que les points de présence sont placés près des emplacements denses d'échange Internet, avec la diversité des fournisseurs et la proximité du réseau parmi les facteurs de conception. Le DNS et l'anycast dirigent les utilisateurs vers la capacité Fastly la plus proche. En cas de défaillance physiquement localisée, ces propriétés peuvent contourner un lien, un opérateur, une installation ou un POP défaillant.

Avant l'incident, Fastly décrivait un réseau de 68 POP dans 26 pays et six continents, connectés via un mélange de transit, d'échanges Internet, de peering cloud et d'interconnexion privée. Son récit de planification de capacité indiquait qu'il modélisait les défaillances de POP et de connectivité et maintenait une marge régionale pour les débordements. Ce sont des formes significatives de résilience. Elles réduisent la dépendance à un seul câble, un seul opérateur, un seul bâtiment et un seul site métropolitain.

Elles n'ont pas traité le mode de défaillance du 8 juin. Si de nombreux POP exécutent le même code logiciel défectueux et acceptent un modèle de configuration commun, la diversité géographique peut reproduire plutôt qu'isoler le défaut. Plusieurs fournisseurs de transit peuvent transporter les utilisateurs de manière fiable vers des nœuds edge qui renvoient systématiquement des erreurs. Plus de sessions de peering peuvent améliorer la portée et le choix du chemin tout en laissant l'application de service indisponible.

L'anycast peut déplacer une requête vers un autre POP, mais si ce POP partage le même sort logiciel, l'utilisateur a changé d'emplacement sans changer de résultat.

Voici la leçon centrale de l'angle du peering: la diversité des chemins n'est pas la diversité des services. Les opérateurs réseau conçoivent depuis longtemps pour les défaillances de liens et de routes car ces défaillances sont visibles dans la couche qu'ils exploitent. Les services cloud et edge ajoutent des modes communs de couche supérieure. Le code partagé, la distribution globale de la configuration, l'identité, la journalisation, les plans de contrôle, les systèmes de certificats, l'automatisation du déploiement et les outils d'incident peuvent corréler une infrastructure qui semble physiquement indépendante.

Un examen sérieux de la résilience a donc besoin d'une matrice de domaines de défaillance plutôt que d'un décompte de POP ou d'opérateurs. Une colonne devrait lister les installations physiques, l'alimentation, le matériel, la fibre, le transit, le peering et le routage. Une autre devrait lister les versions logicielles, les compilateurs de configuration, les contrôleurs de déploiement, les services de clés et de certificats, le nommage, l'observabilité et l'accès administratif.

Une troisième devrait lister les dépendances contrôlées par le client telles que le DNS faisant autorité, l'hébergement d'origine, le CDN alternatif, la politique WAF, le stockage d'objets et les pipelines de publication. La diversité n'existe que là où le même événement ne peut pas désactiver à la fois le service principal et la route utilisée pour le rétablir.

Distribution et concentration peuvent coexister

La panne a produit un paradoxe visuel. L'infrastructure affectée était répartie dans le monde entier, mais une seule condition latente a généré des défaillances simultanées dans de nombreux endroits et organisations. La distribution décrit où se trouvent les ressources. La concentration décrit combien de décisions indépendantes, d'implémentations et de chemins de rétablissement se trouvent entre un défaut et un préjudice généralisé. Un système peut obtenir un score élevé sur le premier et faible sur le second.

Des recherches publiées après l'incident aident à quantifier le cadre général sans prouver la part de marché exacte de Fastly ce jour-là. Une étude sur les dépendances de services tiers dans 50 pays a révélé une dépendance étendue aux fournisseurs externes de DNS, CDN et d'autorités de certification, avec une variation substantielle par pays et un ensemble de fournisseurs très concentré.

Une autre étude, A First Look at the Consolidation of DNS and Web Hosting Providers, a constaté que Cloudflare, Amazon, Akamai, Fastly et Google hébergeaient ensemble environ 62 % des pages d'index dans le top 10 000 de Tranco dans sa mesure et fournissaient une majorité des ressources externes de nombreux sites.

Ces mesures sont des instantanés avec des limites méthodologiques. Elles ne doivent pas être converties en une affirmation selon laquelle 62 % du web dépendait de Fastly ou que toutes les relations d'hébergement mesurées étaient critiques. Leur pertinence est structurelle. Les services populaires s'appuient souvent sur un petit groupe de fournisseurs, et une page individuelle peut contenir des ressources de plusieurs d'entre eux. La concentration peut donc apparaître à plusieurs niveaux:

• Un client peut utiliser un seul CDN pour le document racine et chaque objet essentiel.
• Un client peut utiliser plusieurs CDN mais laisser un script, une police, une image, une API, un certificat ou un chemin de redirection critique sur un seul fournisseur.
• Deux CDN nominalement indépendants peuvent partager un cloud d'origine, un fournisseur DNS faisant autorité, un chemin de transit, un référentiel de configuration, un système d'identité ou un pipeline de déploiement.
• De nombreuses organisations sans lien peuvent choisir indépendamment le même fournisseur, créant une dépendance commune intersectorielle qu'aucun client individuel ne peut observer pleinement.
• Un plan de secours peut exister techniquement mais nécessiter des personnes, des identifiants, du code, des dépôts de paquets, des informations de statut ou des canaux de communication qui sont dégradés pendant le même événement.

La concentration du marché et la concentration architecturale sont liées mais pas identiques. Un marché peut avoir plusieurs fournisseurs majeurs tandis qu'une organisation particulière reste mono-hébergée. Inversement, un client peut contracter avec deux fournisseurs et créer tout de même un domaine de défaillance logique via un DNS partagé, une origine partagée, une mauvaise configuration synchronisée ou un basculement non testé. Les conseils d'administration devraient résister à l'utilisation du nombre de fournisseurs comme substitut à l'analyse des dépendances.

La portée sociale d'un CDN importe également. Fastly ne possédait pas les journaux, les boutiques, les projets logiciels ou les services gouvernementaux affectés. Pourtant, les utilisateurs ont fait l'expérience de leur indisponibilité via un intermédiaire partagé que la plupart des utilisateurs ne voient jamais. C'est une forme de pouvoir opérationnel délégué. Le fournisseur peut améliorer la vitesse et absorber la charge à une échelle que chaque client aurait du mal à reproduire, mais un défaut du fournisseur peut également synchroniser des défaillances qui auraient autrement été indépendantes.

Cela ne rend pas la concentration intrinsèquement irresponsable. L'expertise et l'infrastructure concentrées peuvent créer une meilleure sécurité, performance et fiabilité que des milliers de déploiements individuels faibles. La question de responsabilité est de savoir si l'efficacité gagnée grâce à une infrastructure commune est compensée par des contrôles de mode commun plus forts, des preuves d'incident transparentes et des options de sortie ou de repli réalistes. Plus l'agrégation est conséquente, moins il est convaincant de traiter la sécurité à l'échelle de la plateforme comme un problème ordinaire de qualité de produit.

GOV.UK avait une sauvegarde et a quand même subi une panne

Le rapport d'incident public du Government Digital Service pour GOV.UK est l'un des enregistrements les plus clairs de la prise de décision côté client. GOV.UK a détecté son impact quatre minutes après son début, a établi des responsables d'incident et de communication, a confirmé le CDN principal comme source et a localisé un processus documenté pour basculer vers un fournisseur secondaire.

Ce n'était pas une redondance uniquement sur papier. Le CDN secondaire était continuellement disponible, bien qu'il ne transportait normalement aucun trafic de production. Le code de basculement était prêt. L'équipe comprenait le CDN principal comme un point de défaillance unique possible. Ces contrôles plaçaient GOV.UK dans une position matériellement plus forte qu'une organisation découvrant ses options pendant la panne.

Malgré tout, les utilisateurs n'ont pas pu accéder aux informations et services de GOV.UK pendant moins d'une heure. L'équipe a intentionnellement attendu 15 minutes après la détection avant de décider de basculer car le secondaire offrait une expérience dégradée. Les fonctions dynamiques telles que la recherche et les services basés sur la localisation ne fonctionneraient pas à leur qualité habituelle, et basculer trop tôt pendant un incident court du fournisseur pourrait prolonger ou aggraver la perturbation. Après la décision, les changements DNS avaient encore besoin de temps pour se propager.

En 30 minutes, les changements ont été déployés et le trafic commençait à se déplacer, mais Fastly était déjà en train de se rétablir. L'équipe est ensuite repassée au service principal plus performant.

Voici à quoi ressemble une véritable résilience: une option avec des coûts, des transitions d'état, du jugement et du délai. La sauvegarde a réduit le risque d'une panne longue. Elle n'a pas rendu le basculement instantané ou sans conséquence. L'incident a également exposé une dépendance de communication avec les utilisateurs. La page 503 générique de Fastly se situait en dehors du contrôle du contenu de GOV.UK et tombait en deçà des normes du service pour des informations publiques utiles.

Le dossier de GOV.UK offre plusieurs tests de responsabilité. Le secondaire était-il réellement chaud? Oui. Y avait-il un processus documenté et une autorité nommée? Oui. La dégradation était-elle comprise? Oui. Le mécanisme de basculement était-il suffisamment rapide pour la tolérance à l'impact du service? La chronologie observée donne aux décideurs des preuves pour répondre, plutôt qu'une assurance théorique. Le rapport démontre également pourquoi les conseils d'administration devraient demander le temps médian et le pire cas pour déplacer un trafic utilisateur significatif, et non simplement si un deuxième CDN est sous contrat.

Pour les services publics, la distinction est particulièrement importante. Une panne au niveau de l'edge de présentation peut rendre les conseils fiscaux, les informations sur les prestations, le matériel de santé, les instructions réglementaires et les communications d'urgence inaccessibles même si les systèmes départementaux sous-jacents restent sains. L'edge n'est pas décoratif lorsqu'il est le point d'entrée public. La cartographie de l'impact commercial devrait traiter la perte de livraison comme la perte du service que les utilisateurs peuvent réellement atteindre.

GitLab a trouvé une dépendance dans le chemin de rétablissement

Le dossier d'incident de production public de GitLab montre une architecture différente et une défaillance différente. Fastly servait les assets pour GitLab.com, donc le site principal était sévèrement dégradé pour les utilisateurs dont les navigateurs manquaient de JavaScript et d'images en cache. About.GitLab.com, où Fastly était le premier point d'entrée, était totalement indisponible. Les fonctions API, Git, Registry et Pages ont continué, montrant la valeur de séparer les chemins de service.

À 10h18 UTC, les ingénieurs de GitLab ont préparé une merge request pour remplacer le CDN utilisé pour les assets. Ils n'ont pas pu l'appliquer via le pipeline normal car une image dans ce pipeline tentait d'installer un paquet depuis un dépôt externe également affecté par la perturbation Fastly. Un mécanisme de rétablissement prévu a hérité du même événement externe par une dépendance qui n'était pas le paramètre CDN en cours de modification.

C'est un exemple compact de concentration transitive. Sur un diagramme d'architecture, l'application, le pipeline de configuration, l'image conteneur, l'index de paquets et le CDN peuvent apparaître comme des boîtes différentes. Opérationnellement, une action de rétablissement dépend de chaque boîte nécessaire à son exécution. Si une étape de construction atteint un service externe indisponible, le pipeline est indisponible exactement au moment où il est nécessaire pour retirer une autre dépendance.

GitLab a testé un contournement manuel en staging, puis sur une tranche canary, pendant que Fastly se rétablissait. Ses actions correctives comprenaient des images immuables pour les composants critiques, des runbooks pour appliquer les changements manuellement, un bucket backend et un équilibreur de charge pour un rétablissement plus rapide du CDN, l'examen de CDN redondants et un exercice pour les cas où les workflows normaux sont entravés par des facteurs externes. Ces actions sont précieuses car elles abordent la capacité de rétablissement, et pas seulement la défaillance du fournisseur d'origine.

La nature partielle de l'impact de GitLab met également en garde contre les registres de dépendances binaires. Marquer « Fastly: tiers » dit peu. Une carte utile identifie quels noms d'hôte, chemins, objets et parcours utilisateur nécessitent le fournisseur; si les navigateurs peuvent utiliser les assets en cache; si les API restent accessibles; où se termine le TLS; comment fonctionnent les redirections; et si le personnel peut déployer un contournement sans contacter le chemin défaillant.

La décomposition des services peut préserver les fonctions de grande valeur, mais seulement si les évaluations d'impact reflètent ce que les utilisateurs peuvent accomplir lorsque les composants visuels ou côté client sont absents.

GitLab et GOV.UK ont atteint des résultats différents car la résilience est locale à une implémentation. L'incident du fournisseur était commun. Le rayon d'explosion client ne l'était pas. C'est pourquoi la responsabilité du client ne peut être écartée en disant que le fournisseur est tombé en panne, et la responsabilité du fournisseur ne peut être diluée en disant que certains clients manquaient d'un deuxième CDN. Fastly possédait la prévention et la restauration de la défaillance partagée. Chaque client possédait la forme et la préparation de sa dépendance.

Le rétablissement peut transformer l'efficacité du cache en pression sur l'origine

Un CDN protège normalement une origine d'une grande partie de la charge de requêtes. GOV.UK a indiqué qu'environ 93 % de ses requêtes étaient servies depuis le cache. La documentation sur le shielding de Fastly décrit le schéma ordinaire: les POP edge servent les objets en cache, et un shield désigné peut consolider les misses avant qu'ils n'atteignent l'origine. L'architecture améliore les performances et peut réduire fortement le trafic vers l'origine.

Pendant le rétablissement, cette efficacité peut s'inverser. Si les caches sont froids ou que les taux de succès chutent, plus de requêtes edge remontent en amont. Si un client contourne complètement le CDN, l'origine peut recevoir un trafic pour lequel elle n'a jamais été dimensionnée car la planification de capacité normale supposait une absorption à l'edge. Si de nombreux utilisateurs réessayent après des erreurs répétées, la vague peut être plus grande que la demande ordinaire. L'avertissement de Fastly concernant l'augmentation de la charge sur l'origine n'était donc pas une note de bas de page.

Il identifiait un risque de second ordre produit par la restauration.

La conception multi-CDN doit en tenir compte. Un fournisseur secondaire qui n'a pas d'objets chauds peut immédiatement tirer depuis la même origine. Deux fournisseurs en rétablissement peuvent générer des misses en double. Une configuration de shielding peut réduire la charge mais créer un autre point de concentration important. Les limites de débit, l'authentification, les listes blanches, les règles WAF et les limites de connexion à l'origine peuvent différer entre les fournisseurs. Les journaux peuvent arriver dans des formats ou à des vitesses différents au moment où les intervenants ont besoin d'une vue cohérente.

Le basculement direct vers l'origine n'est pas automatiquement plus sûr. Publier les adresses d'origine peut modifier la surface d'attaque. Les certificats et le routage des hôtes doivent être corrects. L'origine doit être capable d'absorber la demande et de se défendre sans les services normalement fournis à l'edge. Un contournement qui restaure les pages statiques mais désactive la connexion, le paiement, la recherche, la personnalisation ou les contrôles d'abus peut être le mode dégradé correct, mais ce mode nécessite une approbation commerciale explicite et une communication avec les utilisateurs.

Le test pratique est un exercice de trafic. L'organisation peut-elle diriger un pourcentage limité du trafic de production vers le chemin alternatif sans crise? L'alternative renvoie-t-elle le même contenu essentiel et les mêmes en-têtes de sécurité? Peut-elle gérer la charge attendue et une vague de nouvelles tentatives? L'invalidation du cache et la publication d'urgence sont-elles disponibles? Les ingénieurs peuvent-ils l'opérer en utilisant des identifiants, des appareils, des dépôts et des systèmes de communication en dehors du domaine de défaillance du fournisseur principal?

Les étapes de restauration sont-elles réversibles sans créer un second incident?

Les accords de niveau de service ne répondent pas à ces questions. Les crédits compensent une mesure contractuelle étroite après coup. Ils ne restaurent pas une transaction manquée, un avis public retardé ou un workflow de développeur. Un client qui se fie à un SLA au lieu d'exercer le basculement a transféré une conséquence financière, pas la responsabilité opérationnelle de la continuité.

Le multi-CDN est un modèle opérationnel, pas une case à cocher d'approvisionnement

ThousandEyes a observé que les clients disposant de plusieurs fournisseurs de livraison avaient différents niveaux de succès. Certains ont déplacé le trafic racine loin de Fastly mais ont continué à charger des objets de page critiques depuis celui-ci. D'autres ont mis plus de temps à retirer toutes les dépendances Fastly. Ce comportement illustre un piège de conception: l'orientation du trafic à la première requête ne suffit pas si la page nécessite ensuite des scripts, des styles, des API, des images, des polices, des redirections ou des ressources d'authentification provenant du fournisseur défaillant.

Une conception multi-CDN exécutable a au moins huit propriétés exigeantes.

Premièrement, la configuration doit être portable. Les clés de cache, les durées de vie, le comportement en cas de contenu obsolète, la sélection de l'origine, les redirections, le code edge, les politiques WAF, les contrôles de robots et la manipulation des en-têtes diffèrent selon les fournisseurs. Une configuration nominalement équivalente peut se comporter différemment sous des requêtes inhabituelles. La portabilité nécessite une équivalence sémantique testée, pas un fichier traduit attendant dans un dépôt.

Deuxièmement, le nommage doit permettre un changement rapide. Des valeurs TTL DNS faibles peuvent raccourcir certaines transitions, mais les résolveurs et les clients ne se rafraîchissent pas tous au moment idéal. Les enregistrements apex, les chaînes CNAME, les adresses anycast et la validation des certificats imposent des contraintes. Une couche d'orientation peut elle-même devenir une dépendance concentrée. Les organisations ont besoin de données de propagation mesurées à partir d'exercices de basculement réels.

Troisièmement, l'origine doit accepter les deux fournisseurs de livraison. Les listes blanches réseau, le TLS mutuel, les requêtes signées, les health checks, les pools de connexions et les limites de débit doivent fonctionner avant une urgence. Un CDN alternatif qui ne peut pas s'authentifier auprès de l'origine est un inventaire, pas une résilience.

Quatrièmement, le contenu critique doit être complet. La page racine, les objets essentiels, les pages d'erreur, les redirections, les API et les communications utilisateur nécessitent une livraison indépendante. Un second fournisseur servant uniquement des images peut améliorer les performances mais pas la disponibilité. La cartographie des dépendances doit suivre les parcours utilisateur plutôt que les contrats de fournisseurs.

Cinquièmement, l'alternative a besoin de capacité et d'autorisation commerciale. Un fournisseur dormant peut ne pas avoir de capacité réservée pour un basculement mondial soudain. Les niveaux de trafic engagés, la tarification des pics, les hypothèses DDoS et la réponse du support doivent être convenus à l'avance. La concentration ne peut être résolue en créant un secondaire qui échoue sous la première charge réelle.

Sixièmement, la télémétrie doit survivre. Les sondes externes doivent tester via différents réseaux d'accès et régions. Les journaux des deux fournisseurs doivent atteindre un chemin d'analyse indépendant. Les pages de statut et les outils de pager ne doivent pas être exclusivement derrière le service dont ils rapportent le statut. Le client doit pouvoir distinguer rapidement une défaillance DNS, de routage, TLS, d'application edge, d'origine et de niveau objet.

Septièmement, l'autorité doit être explicite. L'équipe de GOV.UK avait un responsable d'incident et un seuil pour décider quand un basculement dégradé était préférable. Sans cette conception de décision, les intervenants peuvent perdre la panne à débattre s'ils sont autorisés à déplacer le trafic, à accepter une fonctionnalité réduite ou à encourir un coût plus élevé.

Huitièmement, le retour en arrière nécessite la même discipline que le basculement. Les caches, les réponses DNS, les sessions, les certificats et la charge de l'origine peuvent être instables pendant le retour du trafic. La restauration initiale de Fastly et la résolution finale de l'incident étaient des jalons séparés. Les clients devraient définir leur propre point de rétablissement basé sur des parcours utilisateur réussis et une capacité stable, et non refléter automatiquement la couleur de statut du fournisseur.

Ces exigences expliquent pourquoi le multi-CDN peut être justifié pour un service critique sans être économique pour chaque site. Les petites organisations peuvent rationnellement accepter une panne courte plutôt que de financer une ingénierie de livraison en double. La responsabilité n'exige pas une architecture identique pour chaque client. Elle exige une tolérance explicite à l'impact, une dépendance comprise, un choix de rétablissement proportionné et aucune fausse affirmation selon laquelle la redondance ordinaire du fournisseur couvre une défaillance logicielle à l'échelle de la plateforme.

La réponse de Fastly a été rapide, mais l'assurance publique était étroite

Sur la chronologie de la réponse, Fastly a bien performé à plusieurs égards. La surveillance a détecté le problème mondial en une minute. Les ingénieurs ont identifié la configuration déclencheur en 40 minutes. Sa désactivation a ramené 95 % du réseau en 49 minutes. Un correctif permanent a commencé à être déployé plus tard dans la journée. L'entreprise a communiqué que le changement du client était valide et a accepté qu'elle aurait dû anticiper la condition.

Ces faits ne doivent pas être minimisés. La détection et la restauration rapides ont réduit matériellement le préjudice public. Les systèmes distribués échouent, et la responsabilité en cas d'incident devrait reconnaître la performance du contrôle ainsi que l'échec du contrôle. Une organisation qui expose un défaut grave puis le contient en moins d'une heure présente un risque différent d'une organisation qui ne peut pas voir ou inverser l'état de sa propre plateforme.

Le post-mortem public laisse néanmoins le volet prévention non résolu. Il indique que Fastly enquêterait sur les raisons pour lesquelles l'assurance qualité et les tests n'ont pas détecté le bug, évaluerait les moyens d'améliorer le temps de remédiation et poursuivrait une plus grande isolation via WebAssembly et Compute@Edge. Il ne publie pas l'enquête qui en a résulté, les propriétaires des actions, les délais, les preuves de clôture ou une évaluation indépendante.

Il n'y a aucune explication publique de la raison pour laquelle une configuration a affecté des services sans lien, si le déploiement était progressif par POP ou cohorte de clients, ou quelle garde empêche désormais la récurrence de la même classe.

Cela n'établit pas que Fastly n'a pas effectué ces actions en interne. Les grands fournisseurs donnent souvent aux clients des rapports privés sous conditions de confidentialité. Cela établit une limite à la confiance publique. Les observateurs externes peuvent créditer le rétablissement observé et les engagements déclarés; ils ne peuvent pas traiter le bref article comme une preuve de remédiation achevée.

Le rapport trimestriel de Fastly pour juin 2021 a converti l'événement en divulgation formelle des risques. Le dossier décrivait un bug logiciel non découvert causé par une erreur humaine, déclenché par une configuration client valide. Il indiquait que les clients avaient réduit ou supprimé le trafic et formulé des réclamations au titre des niveaux de service.

Il a également divulgué des dépendances plus larges sur la bande passante contractée et la possibilité que des pannes de fournisseur, des litiges, une défaillance du fournisseur de réseau, des événements naturels, des limites de trafic ou une réglementation rendent cette capacité indisponible.

L'expression « causé par une erreur humaine » est moins informative que la séquence technique de l'entreprise. Tout logiciel est écrit et opéré par des personnes. La question de gouvernance est de savoir quel système a permis à une action humaine ordinaire de créer une défaillance large et corrélée. Le langage de l'erreur individuelle peut obscurcir les mécanismes de conception et d'assurance qui existent précisément parce que les personnes et le code sont faillibles.

Le dossier économique a fait de la fiabilité un enjeu de gouvernance

La lettre aux actionnaires du deuxième trimestre de Fastly indiquait que la panne avait affecté presque tous les clients. Les volumes de trafic ont diminué, des crédits clients ont été émis, quelques clients, dont un client du top dix, n'avaient pas encore ramené leur trafic, et plusieurs clients ont retardé de nouveaux projets. Comme le modèle de Fastly était basé sur l'utilisation, moins de trafic s'est traduit directement par une pression sur les revenus. L'entreprise a déclaré que la panne et le trafic retardé affecteraient ses perspectives pour le troisième trimestre et l'année complète.

La même lettre rapportait un chiffre d'affaires de 85 millions de dollars au deuxième trimestre et fixait des prévisions de chiffre d'affaires annuel entre 340 et 350 millions de dollars, tout en déclarant que les perspectives reflétaient la panne, le calendrier de remontée du trafic et les renouvellements attendus. Ces facteurs ne peuvent pas être séparés proprement des chiffres publics, il serait donc incorrect d'attribuer l'ensemble du changement des attentes à une heure de temps d'arrêt.

La conclusion défendable est plus étroite: la panne a produit des crédits de service et des décisions de trafic des clients qui ont prolongé son effet économique au-delà de l'incident technique.

Le rapport annuel 2021 de Fastly a ensuite indiqué que les clients affectés étaient revenus, mais pas tout le trafic n'était revenu aux niveaux d'avant la panne. Il a également divulgué une interruption de plateforme antérieure en janvier 2021 causée par un bug non découvert dans une mise à jour logicielle, qui avait conduit à des réclamations au titre des niveaux de service. Les deux incidents n'ont pas été décrits comme ayant la même cause technique.

Leur coexistence fait cependant de la résilience des versions logicielles un sujet raisonnable pour une attention soutenue du conseil d'administration plutôt qu'une anomalie opérationnelle ponctuelle.

La déclaration de procuration 2021 de l'entreprise, déposée avant l'assemblée générale de juin, indiquait que le conseil était responsable de la surveillance éclairée des risques et du suivi de l'exposition aux risques stratégiques, tandis que les dirigeants géraient les risques matériels au quotidien. Elle attribuait la surveillance du risque de sécurité de l'information au comité d'audit. Le dossier ne révèle pas ce que le conseil savait du risque de disponibilité à l'échelle de la plateforme avant la panne ni ce qu'il a examiné après. Il établit l'architecture de gouvernance, pas la qualité de l'enquête réelle du conseil.

Pour un fournisseur dont le produit est une infrastructure opérationnelle partagée, la disponibilité appartient à la surveillance stratégique même lorsque le mandat déclaré du comité d'audit met l'accent sur la sécurité de l'information. Un défaut d'une heure a modifié les décisions de routage des clients, l'exposition aux crédits de service, les attentes de revenus et la confiance. C'est un pont direct entre les contrôles d'ingénierie et la valeur de l'entreprise.

Les administrateurs n'ont pas besoin de déboguer le logiciel edge, mais ils ont besoin de preuves que la direction peut limiter une version logicielle, isoler la configuration d'un locataire, restaurer en toute sécurité et vérifier la remédiation.

La responsabilité est partagée, mais elle n'est pas floue

La responsabilité partagée est souvent invoquée après des incidents cloud comme si elle répartissait la responsabilité si largement qu'aucune partie ne reste clairement responsable. La meilleure méthode est d'allouer la responsabilité par capacité de contrôle.

Fastly contrôlait le déploiement de code qui a introduit le défaut. Il contrôlait l'analyseur, le compilateur, l'environnement d'exécution ou tout autre mécanisme de plateforme qui a accepté et traité la configuration valide. Il contrôlait si un changement limité à un client pouvait affecter des clients sans lien, comment le logiciel atteignait les POP, ce que la surveillance pouvait voir, et à quelle vitesse la plateforme pouvait désactiver le déclencheur et déployer un correctif. Ce sont des responsabilités du fournisseur car les clients ne pouvaient pas les inspecter ni les opérer.

Les clients contrôlaient la décision de placer des parcours utilisateur particuliers derrière Fastly, la capacité et la sécurité des origines, l'utilisation d'un ou plusieurs CDN, les arrangements DNS et de certificats, le contenu de repli statique, les chemins alternatifs et la préparation des procédures de rétablissement. Ils contrôlaient également si les outils internes critiques de déploiement et de communication partageaient les mêmes dépendances. Ce sont des responsabilités du client car Fastly ne pouvait pas déterminer la panne acceptable de chaque service ni financer le repli de chaque client.

Les partenaires de peering et les fournisseurs de transport transportaient le trafic vers et depuis Fastly, mais le dossier public ne les identifie pas comme la cause. Leur diversité a peut-être aidé à maintenir le réseau accessible pendant que l'application échouait. Attribuer la responsabilité à « l'Internet » ou à BGP effacerait les preuves de couche.

Le client qui a fourni la configuration déclencheur contrôlait son propre changement de service valide. Le dossier public n'identifie pas le client, ne divulgue pas la configuration et ne suggère pas d'inconduite. Une plateforme multi-locataire devrait supposer que des actions valides de locataires se produiront. Aucune responsabilité ne devrait être attribuée à ce client au-delà du fait non étayé d'être le déclencheur.

Les conseils d'administration des deux côtés contrôlaient l'appétit pour le risque et les demandes de preuves. Le conseil de Fastly pourrait demander si une version de plateforme a des contrôles indépendants de rayon d'explosion et si une action de locataire peut traverser les frontières de service. Les conseils des clients pourraient demander quels services importants sont mono-hébergés et si le temps de basculement reste dans la tolérance à l'impact de l'entreprise. Aucun conseil ne peut externaliser sa question à l'autre.

Les régulateurs ont un rôle plus étroit mais important là où des fournisseurs communs soutiennent des secteurs critiques. La boîte à outils sur les risques tiers du Conseil de stabilité financière distingue la gestion des risques tiers au niveau de l'entreprise du besoin des autorités d'identifier les dépendances systémiques. La SS2/21 de la Banque d'Angleterre sur l'externalisation et le risque tiers attend des entreprises réglementées qu'elles gèrent la concentration et la résilience opérationnelle.

Le Règlement sur la résilience opérationnelle numérique de l'UE a ensuite formalisé l'attention portée à la concentration des TIC tiers et à la responsabilité des organes de direction pour les entités financières couvertes.

Ces cadres ne créent pas de constat rétrospectif contre Fastly, et ils ne s'appliquent pas identiquement à chaque client de CDN. Ils montrent la direction politique: les utilisateurs de services critiques restent responsables de leurs dépendances, tandis que les superviseurs ont également besoin de visibilité sur les fournisseurs communs dont la défaillance peut affecter de nombreuses entreprises simultanément. Le basculement au niveau de l'entreprise et la concentration au niveau du système sont des problèmes distincts nécessitant des preuves différentes.

Ce que les conseils d'administration devraient exiger après une défaillance edge latente

Le dossier du conseil devrait commencer par une carte des domaines de défaillance, pas par une taille de flotte. Le nombre de POP, la capacité et l'étendue du peering sont utiles, mais les administrateurs devraient voir quels contrôles sont globaux et lesquels sont indépendamment isolés. La carte devrait relier les versions logicielles, la distribution de la configuration, les limites des locataires, les plans de contrôle, le DNS, les certificats, la journalisation, la communication de statut, le shielding de l'origine et les outils de rétablissement du fournisseur.

Pour le fournisseur, les preuves devraient répondre à des questions concrètes:

• Quelle classe d'entrée valide a activé le défaut, et quel invariant aurait dû le rejeter ou le contenir?
• Pourquoi les tests de préproduction, les canaris de production et l'intervalle de déploiement du 12 mai n'ont-ils pas réussi à le révéler?
• Combien de clients, de POP et de requêtes une configuration ou une cohorte de version peut-elle affecter avant un arrêt automatique?
• Les groupes canaris sont-ils indépendants en termes de code, de plan de contrôle, de géographie et de trafic, ou partagent-ils le mécanisme testé?
• La plateforme peut-elle désactiver une configuration de locataire déclencheur sans dépendre du chemin de service défaillant?
• L'isolation au moment de l'exécution transforme-t-elle un état mal formé ou des exceptions logicielles en une erreur limitée au locataire plutôt qu'en une défaillance de processus ou de flotte?
• Quelles preuves montrent que le correctif permanent et les contrôles de classe plus large sont déployés partout où prévu?
• Quelles mesures de rétablissement décrivent l'expérience client, la charge de l'origine, le réchauffement du cache et les erreurs résiduelles, plutôt que seulement la santé des nœuds?

Pour le client, le dossier devrait montrer les parcours utilisateur importants et les ressources externes exactes dont chacun a besoin. Il devrait nommer un propriétaire, une tolérance à l'impact, un mode de repli, un seuil de décision et une date de dernier exercice. Le temps de détection, de décision, de changement de DNS ou d'orientation, de desserte d'un trafic significatif et de retour sécurisé devrait être mesuré séparément. Un basculement qui s'achève après la tolérance à l'impact est un mécanisme d'apprentissage, pas encore un contrôle efficace.

Le guide de planification d'urgence du NIST fournit une séquence durable: analyse d'impact commercial, contrôles préventifs, stratégies de rétablissement, plans, tests, formation, exercices et maintenance. Sa portée fédérale ne doit pas être confondue avec un mandat juridique universel, mais le principe opérationnel voyage bien. Un plan de rétablissement devient fiable par l'exercice et la maintenance.

Les directives sur les risques de chaîne d'approvisionnement du NIST soulignent également la visibilité réduite sur la manière dont la technologie acquise est développée, intégrée et déployée. Un client de CDN ne peut pas inspecter tous les internes du fournisseur. Il peut néanmoins exiger des conditions d'incident, la divulgation des dépendances matérielles, des horloges de notification, des preuves de rétablissement, des droits d'audit proportionnés à la criticité, la portabilité de la configuration, l'exportation des données et un support pour une sortie testée.

Les métriques devraient éviter les signaux verts faciles. « Deux CDN sous contrat » est faible. « Quatre-vingt-dix pour cent des parcours critiques servis via l'alternative en huit minutes lors du dernier exercice non annoncé » est plus fort. « Réseau mondial restauré » est faible pour un client dont l'origine est surchargée. « Transactions réussies stables au budget d'erreur normal pendant 30 minutes » est plus fort. « Bug corrigé » est faible sans classe de régression, preuve de déploiement et propriétaire de clôture.

La leçon durable concerne le rétablissement indépendant

La panne du 8 juin de Fastly était grave, visible et comparativement brève. Cette combinaison peut encourager les mauvaises conclusions. L'une est la complaisance: parce que la plupart des services sont revenus en 49 minutes, l'événement devient une impressionnante histoire de rétablissement. Une autre est le fatalisme: parce qu'un fournisseur majeur peut tomber en panne, les pannes sont inévitables et aucune responsabilité supplémentaire n'est utile. Les preuves ne soutiennent ni l'un ni l'autre.

Un rétablissement rapide mérite du crédit. De même que l'aveu de Fastly qu'il aurait dû anticiper la condition déclencheuse. Mais le défaut latent a survécu du 12 mai, un changement client valide a affecté la majeure partie du réseau, et le dossier public de remédiation est resté mince. La prévention, le confinement, la réponse et l'assurance sont des contrôles différents. Une performance solide dans la réponse ne ferme pas les trois autres.

Pour les clients, l'incident a démontré qu'une origine, un second contrat ou une procédure DNS n'est pas automatiquement un chemin de rétablissement indépendant. Le secondaire préparé de GOV.UK impliquait toujours une attente délibérée, un service dégradé et une propagation DNS. Le chemin de changement ordinaire de GitLab touchait une dépendance externe de paquet affectée par le même événement. Ce ne sont pas des arguments contre la planification d'urgence. Ils sont la preuve que les contingences ne deviennent réelles que lorsqu'elles sont exercées à travers toutes leurs dépendances.

Pour le risque réseau, la panne a montré pourquoi l'analyse du peering et du transit doit monter dans la pile. L'edge géographiquement distribué et multiplement connecté de Fastly a réduit de nombreux risques physiques. Il n'a pas empêché un logiciel partagé de transformer cet edge en un seul domaine de défaillance logique. La même interconnexion qui offre des performances extraordinaires peut distribuer une erreur commune avec une portée égale.

Le jugement final de responsabilité est donc spécifique. Fastly était responsable du défaut côté fournisseur, de sa propagation et de la preuve que la classe de défaillance avait été contenue. Les clients étaient responsables de savoir ce qui devenait indisponible lorsque Fastly échouait et de choisir un repli proportionné à ce préjudice. Les administrateurs étaient responsables de tester si les assurances du fournisseur et du client se rencontraient à une frontière de rétablissement réellement exécutable.

Les régulateurs, là où des secteurs critiques étaient impliqués, étaient responsables de regarder au-delà des contrats individuels vers les dépendances communes qu'aucune entreprise individuelle ne pouvait voir.

La question pertinente après la prochaine panne edge ne sera pas de savoir si le réseau est distribué. Elle sera de savoir si le sort logiciel, l'autorité opérationnelle et la capacité de rétablissement sont eux aussi distribués indépendamment.