Le bug latent de Fastly et la responsabilité d'une périphérie CDN concentrée

Résumé

• Fastly indique qu’un déploiement logiciel entamé le 12 mai 2021 a introduit un bug latent. Le 8 juin, un client a effectué une modification de configuration valide réunissant les conditions inhabituelles qui l’ont activé. La défaillance qui en a résulté a conduit 85 % du réseau de Fastly à renvoyer des erreurs. Fastly a détecté la perturbation en moins d’une minute et a rétabli le fonctionnement normal de 95 % du réseau en 49 minutes.
• L’incident n’a pas été publiquement attribué à une fuite de route BGP, une défaillance de peering, une pénurie de transit, une cyberattaque ni une action client invalide. Des observations indépendantes ont révélé des erreurs applicatives alors que la couche réseau semblait normale. Cette distinction est importante: un CDN peut bénéficier d’une grande diversité physique et de plusieurs opérateurs tout en restant corrélé par un socle logiciel commun, une sémantique de configuration, des systèmes de déploiement et des contrôles de reprise identiques.
• Le sort des clients a dépendu de leur architecture et de leur préparation opérationnelle. Le GOV.UK disposait d’un CDN secondaire continuellement disponible et d’une procédure de basculement documentée, mais la propagation DNS et les compromis liés au 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 à un paquet externe a entravé le pipeline ordinaire que les ingénieurs voulaient utiliser pour contourner le CDN défaillant.
• La responsabilité repose 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 des déploiements, l’isolation des défaillances globales et la récupération du fournisseur. Les clients contrôlaient la cartographie des dépendances, la diffusion alternative, la capacité des serveurs d’origine, la préparation DNS et des certificats, les outils de reprise et les tolérances aux impacts métier. Les conseils d’administration et les régulateurs devraient exiger des preuves testées des deux domaines, et non accepter un pourcentage de disponibilité élevé ou un simple contrat avec un second fournisseur comme preuve de résilience.

Une modification valide, un domaine de défaillance global

À 09h47 UTC le 8 juin 2021, une grande partie du web public a commencé à renvoyer des erreurs. Des sites d’actualité, des services de commerce, des plateformes de développement, des sites de streaming et le site du gouvernement central du Royaume-Uni figuraient parmi les victimes visibles. Vu de l’extérieur, l’événement ressemblait à une panne simultanée de nombreuses organisations sans lien entre elles. Du point de vue de l’infrastructure, elles étaient liées: les requêtes à destination de ces services convergeaient vers le réseau de diffusion de contenu de Fastly.

Lerécapitulatif de l'incident du 8 juin par Fastlyen fournit le récit causal central. Un déploiement logiciel débuté le 12 mai a introduit un bug. Il est resté latent jusqu’à ce qu’un client applique une modification de configuration valide réunissant les conditions précises pour le déclencher. Fastly indique que 85 % de son réseau s’est alors mis à renvoyer des erreurs. La surveillance a identifié la perturbation globale à 09h48, une minute après son début. La première mise à jour publique du statut a suivi à 09h58. Les ingénieurs ont identifié la configuration cliente à 10h27, la récupération a commencé à 10h36 et 95 % du réseau fonctionnait normalement dans les 49 minutes suivant le début. Fastly a qualifié l’incident de « atténué » à 12h35 et de « résolu » à 12h44, puis a commencé le déploiement d’un correctif permanent à 17h25.

L’incident archivé sur la page de statut de Fastlyajoute un détail opérationnel qu’une simple chronologie binaire ne montre pas. À mesure que le service revenait, les clients pouvaient subir une charge d’origine plus élevée et un taux de hits du cache plus faible. La récupération de la périphérie n’équivalait pas nécessairement à la récupération complète du service client. Les caches devaient se réchauffer, des requêtes habituellement servies en périphérie pouvaient atteindre les serveurs d’origine dans des volumes inhabituels, et les dépendances propres à chaque client devaient se stabiliser. Le rétablissement du fournisseur constituait un jalon critique, pas la fin universelle de l’impact.

Fastly a présenté ses excuses et déclaré que l’incident était vaste et sévère. La société 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û les anticiper. Cette phrase rejette l’explication la plus facile mais la moins utile, selon laquelle un client aurait modifié quelque chose et donc 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 compte rendu public est volontairement général. Il ne dévoile 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 ni le mécanisme par lequel la configuration d’un client a produit des erreurs sur des services de clients sans lien entre eux. Ces omissions peuvent être raisonnables dans un court rapport public, surtout lorsque la confidentialité des clients et la sécurité de la plateforme sont en jeu. Elles limitent toutefois l’assurance externe. Le public peut vérifier la chronologie par l’observation; il ne peut pas déterminer de façon indépendante, à partir du seul billet de Fastly, si le correctif permanent a uniquement supprimé le déclencheur, réparé le défaut sous-jacent ou modifié l’architecture qui a permis un rayon de souffle aussi large.

Cette lacune doit orienter les conclusions. Les éléments étayent l’existence d’un bug latent, d’un déclencheur valide, d’un comportement d’erreur global, d’une détection rapide et d’une atténuation relativement rapide. Ils n’étayent pas une théorie détaillée sur le code bogué ou la conduite d’un ingénieur en particulier. L’analyse de la responsabilité devrait rester au niveau des contrôles: la conception des tests, l’isolation des configurations, la sécurité des déploiements, le confinement des défaillances globales, l’observabilité, l’autorité en matière d’incident et les preuves fournies aux clients et aux dirigeants.

La chronologie distingue le risque dormant 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é presque quatre semaines plus tôt. Un défaut peut être présent en production sans produire de symptômes visibles. C’est ce qui rend les défauts latents difficiles et qui fait que l’assurance de publication ne se limite pas à observer les premières minutes qui suivent le déploiement.

Cette chronologie montre pourquoi l’expression courante « une modification de configuration a causé la panne » est trop imprécise. Les modifications de configuration surviennent constamment sur une plateforme de périphérie dont la valeur inclut la programmabilité. Une configuration valide peut être le stimulus final d’une chaîne causale, tout comme une requête normale peut déclencher un défaut du serveur. Le détenteur du contrôle est la partie capable de rendre les entrées valides sûres, de rejeter les combinaisons qu’il ne peut traiter ou de contenir une défaillance au service qui les a fournies.

Il serait également erroné d’affirmer que le déclencheur n’a pas d’importance. L’analyse du déclencheur est importante pour la reproduction, la détection, l’annulation et les protections futures. Le fait 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 du logiciel et l’environnement de production partagé. Fastly reconnaît lui-même 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 les états non testés. Les plateformes configurables sont confrontées à un problème combinatoire: le logiciel versionné interagit avec le VCL client, les en-têtes, les origines, les règles de mise en cache, le shielding, les contrôles d’accès, les indicateurs de fonctionnalité et la logique de périphérie. Tester exhaustivement chaque combinaison peut s’avérer impossible. Cela rend le confinement, le déploiement progressif, la vérification d’invariants, le fuzzing, les corpus de configuration représentatifs, l’isolation à l’exécution et l’annulation automatique rapide plus importants, pas moins.

Il s’agissait d’une défaillance applicative, pas d’un effondrement du routage

La panne mérite d’être discutée sous l’angle du peering et du transit, car un CDN est autant une activité d’interconnexion qu’une plateforme logicielle. Elle ne doit pas être réécrite comme un incident de peering ou de transit. Les preuves pointent dans l’autre sens.

L’observation réseau contemporaine de Kentika vu l’événement débuter à 09h49 UTC et a mesuré une baisse d’environ 75 % du trafic en provenance de Fastly avant que le trafic ne recommence à revenir à 10h39. L’analyse couche par couche de Cisco ThousandEyesa observé des erreurs de service alors que les chemins réseau continuaient de fonctionner et a décrit différents schémas de récupération client à mesure que le trafic basculait entre les fournisseurs de diffusion. Une analyse produit ultérieure de ThousandEyes a énoncé directement la distinction: des erreurs 503 sont apparues au niveau de la couche applicative tandis que la couche réseau semblait normale.

La proprepolitique de peering de Fastlyidentifie l’AS54113 comme le système autonome par lequel il échange du trafic avec les fournisseurs d’accès Internet et les réseaux de contenu. Sadocumentation sur le réseau mondial de POPexplique que les points de présence sont situés à proximité de points d’échange Internet denses, la diversité des fournisseurs et la proximité réseau figurant 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 physique 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 répartis dans 26 pays et sur six continents, interconnectés par un mélange de transit, d’échanges Internet, de peering cloud et d’interconnexions privées. Soncompte rendu de planification capacitaireindiquait qu’il modélisait les pannes de POP et de connectivité et maintenait une marge régionale pour absorber les débordements. Il s’agit de formes de résilience significatives. 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 de plateforme défectueux et acceptent un modèle de configuration commun, la diversité géographique peut reproduire le défaut au lieu de l’isoler. Plusieurs fournisseurs de transit peuvent acheminer les utilisateurs de manière fiable vers des nœuds de périphérie qui renvoient systématiquement des erreurs. Davantage de sessions de peering peuvent améliorer la portée et le choix de 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.

C’est la leçon centrale de la perspective peering: la diversité des chemins n’est pas la diversité des services. Les opérateurs de réseau ont depuis longtemps conçu leurs réseaux pour faire face aux pannes de liens et de routes, car ces défaillances sont visibles dans la couche qu’ils exploitent. Les services cloud et de périphérie ajoutent des modes communs de couche supérieure. Le partage de code, 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 de gestion d’incident peuvent corréler des infrastructures qui semblent physiquement indépendantes.

Un examen sérieux de la résilience nécessite donc une matrice des domaines de défaillance plutôt qu’un décompte de POP ou d’opérateurs. Une colonne devrait lister les installations physiques, l’alimentation électrique, 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, la résolution de noms, l’observabilité et les accès administratifs. 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 le chemin utilisé pour le rétablir.

Distribution et concentration peuvent coexister

La panne a produit un paradoxe visuel. L’infrastructure touchée était répartie dans le monde entier, et pourtant une seule condition latente a généré des défaillances simultanées dans de nombreux lieux et organisations. La distribution décrit où se trouvent les ressources. La concentration décrit combien de décisions, d’implémentations et de chemins de récupération indépendants s’interposent entre un défaut et des dommages étendus. Un système peut obtenir un score élevé sur le premier critère et médiocre sur le second.

Des recherches publiées après l’incident aident à quantifier le contexte plus large sans prouver la part de marché exacte de Fastly ce jour-là. Une étude sur lesdépendances aux services tiers dans 50 paysa révélé un recours important aux fournisseurs externes de DNS, de CDN et d’autorités de certification, avec des variations substantielles selon les 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 du top 10 000 Tranco dans sa mesure et fournissaient la majorité des ressources externes de nombreux sites.

Ces mesures sont des instantanés comportant des limites méthodologiques. Elles ne doivent pas être transformées 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 reposent souvent sur un petit groupe de fournisseurs, et une page individuelle peut contenir des ressources provenant de plusieurs d’entre eux. La concentration peut donc apparaître à plusieurs niveaux:

• Un client peut utiliser un 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 de DNS faisant autorité, un chemin de transit, un dépôt de configuration, un système d’identité ou un pipeline de déploiement.
• De nombreuses organisations sans lien entre elles peuvent choisir indépendamment le même fournisseur, créant une dépendance commune intersectorielle qu’aucun client ne peut pleinement observer à lui seul.
• Un plan de repli 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 perturbés pendant le même événement.

La concentration du marché et la concentration architecturale sont liées mais pas identiques. Un marché peut compter plusieurs fournisseurs majeurs alors qu’une organisation particulière reste mono-fournisseur. Inversement, un client peut contracter avec deux fournisseurs et néanmoins créer un domaine de défaillance logique unique 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 à une analyse des dépendances.

La portée sociale d’un CDN compte également. Fastly ne possédait pas les journaux, boutiques, projets logiciels ou services gouvernementaux touchés. Pourtant, les utilisateurs ont subi leur indisponibilité par l’intermédiaire d’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 aussi synchroniser des pannes qui auraient autrement été indépendantes.

Cela ne rend pas la concentration intrinsèquement irresponsable. Une expertise et une infrastructure concentrées peuvent produire une meilleure sécurité, de meilleures performances et une meilleure fiabilité que des milliers de déploiements individuels fragiles. La question de responsabilité est de savoir si l’efficacité gagnée par une infrastructure commune s’accompagne de contrôles plus solides contre les modes communs, de preuves d’incident transparentes et d’options de sortie ou de repli réalistes. Plus l’agrégation est lourde de conséquences, moins il est convaincant de traiter la sécurité à l’échelle de la plateforme comme un problème ordinaire de qualité produit.

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

Lerapport d’incident public du Government Digital Service pour GOV.UKest l’un des témoignages les plus clairs de la prise de décision côté client. GOV.UK a détecté l’impact quatre minutes après le début, a désigné des responsables de l’incident et de la communication, a confirmé que le CDN principal était à l’origine et a trouvé une procédure documentée de basculement vers un fournisseur secondaire.

Il ne s’agissait pas d’une redondance sur le papier. Le CDN secondaire était continuellement disponible, bien qu’il n’ait normalement aucun trafic de production. Le code de basculement était prêt. L’équipe considérait le CDN principal comme un point de défaillance unique possible. Ces contrôles plaçaient GOV.UK dans une position nettement plus solide qu’une organisation découvrant ses options pendant la panne.

Même ainsi, les utilisateurs n’ont pas pu accéder aux informations et services de GOV.UK pendant près d’une heure. L’équipe a volontairement attendu 15 minutes après la détection avant de décider de basculer, car le fournisseur secondaire offrait une expérience dégradée. Les fonctions dynamiques telles que la recherche et les services géolocalisés ne fonctionnaient pas à leur qualité habituelle, et basculer trop tôt pendant un bref incident du fournisseur risquait de prolonger ou d’aggraver la perturbation. Une fois la décision prise, les modifications DNS devaient encore se propager. En 30 minutes, les modifications étaient déployées et le trafic commençait à se déplacer, mais Fastly récupérait déjà. L’équipe est alors revenue au service principal, plus performant.

Voici à quoi ressemble la vraie résilience: une option avec des coûts, des transitions d’état, du jugement et des délais. La sauvegarde a réduit le risque d’une longue panne. Elle n’a pas rendu le basculement instantané ni sans conséquence. L’incident a également révélé une dépendance en matière de communication avec les utilisateurs. La page 503 générique de Fastly échappait au contrôle du contenu de GOV.UK et ne répondait pas aux normes du service en matière d’information publique utile.

Le rapport de GOV.UK fournit plusieurs tests de responsabilité. Le fournisseur secondaire était-il réellement chaud? Oui. Existait-il une procédure documentée et une autorité nommée? Oui. La dégradation était-elle comprise? Oui. Le mécanisme de basculement était-il assez rapide pour la tolérance aux impacts du service? La chronologie observée donne aux décideurs des éléments de réponse fondés sur des preuves, plutôt qu’une assurance théorique. Le rapport montre également pourquoi les conseils d’administration devraient demander le temps médian et le pire temps nécessaire pour déplacer un trafic utilisateur significatif, et pas seulement si un second CDN est sous contrat.

Pour les services publics, la distinction est particulièrement importante. Une panne au niveau de la périphérie de présentation peut rendre inaccessibles des conseils fiscaux, des informations sur les prestations, du matériel de santé, des instructions réglementaires et des mises à jour d’urgence, même si les systèmes ministériels sous-jacents restent sains. La périphérie n’est pas décorative lorsqu’elle constitue le point d’entrée public. La cartographie des impacts métier devrait traiter la perte de diffusion comme la perte du service que les utilisateurs peuvent effectivement atteindre.

GitLab a découvert une dépendance à l’intérieur du chemin de récupération

Lerelevé d’incident de production public de GitLabmontre une architecture différente et une défaillance différente. Fastly diffusait les assets de GitLab.com, de sorte que le site principal était sévèrement dégradé pour les utilisateurs dont les navigateurs ne disposaient pas des fichiers JavaScript et des images en cache. Le site About.GitLab.com, pour lequel Fastly était le premier point d’entrée, était totalement indisponible. Les fonctions API, Git, Registry et Pages ont continué de fonctionner, montrant l’intérêt de séparer les chemins de service.

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

Voici un exemple compact de concentration transitive. Sur un diagramme d’architecture, l’application, le pipeline de configuration, l’image de conteneur, l’index de paquets et le CDN peuvent apparaître comme des boîtes différentes. Sur le plan opérationnel, une action de récupération 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 au moment précis où l’on en a besoin pour supprimer une autre dépendance.

GitLab a testé un contournement manuel en préproduction, puis sur une tranche de production partielle (canary), pendant que Fastly récupérait. Ses actions correctives comprenaient des images immuables pour les composants critiques, des procédures opérationnelles pour appliquer les modifications manuellement, un compartiment backend et un équilibreur de charge pour accélérer la récupération du CDN, l’étude de CDN redondants et un exercice de crise pour les cas où les flux de travail normaux sont perturbés par des facteurs externes. Ces actions sont précieuses car elles traitent la capacité de récupération, et pas seulement la défaillance initiale du fournisseur.

La nature partielle de l’impact pour GitLab met également en garde contre les registres de dépendance binaires. Noter « Fastly: tierce partie » n’apporte pas grand-chose. Une cartographie utile identifie quels noms d’hôte, chemins, objets et parcours utilisateur nécessitent le fournisseur; si les navigateurs peuvent utiliser des assets en cache; si les API restent joignables; où le TLS se termine; comment les redirections fonctionnent; et si le personnel peut déployer un contournement sans passer par le chemin défaillant. La décomposition des services peut préserver des fonctions à forte valeur, mais seulement si les évaluations d’impact reflètent ce que les utilisateurs peuvent accomplir lorsque des composants visuels ou côté client sont manquants.

GitLab et le GOV.UK ont abouti à des résultats différents parce que la résilience est propre à chaque implémentation. L’incident du fournisseur était commun. Le rayon de souffle client ne l’était pas. C’est pourquoi la responsabilité du client ne peut pas être écartée en disant que le fournisseur est tombé, et la responsabilité du fournisseur ne peut pas être diluée en disant que certains clients manquaient d’un second CDN. Fastly était responsable de la prévention et de la restauration de la défaillance partagée. Chaque client était responsable de la forme et de l’état de préparation de sa dépendance.

La récupération peut transformer l’efficacité du cache en pression sur l’origine

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

Pendant la récupération, cette efficacité peut s’inverser. Si les caches sont froids ou si les taux de succès chutent, davantage de requêtes de périphérie remontent vers l’amont. Si un client contourne entièrement le CDN, l’origine peut recevoir un trafic pour lequel elle n’a jamais été dimensionnée, car la planification normale de la capacité supposait une absorption par la périphérie. Si de nombreux utilisateurs réessaient après des erreurs répétées, la surtension peut être supérieure à la demande ordinaire. L’avertissement de statut de Fastly concernant l’augmentation de la charge d’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 solliciter la même origine. Deux fournisseurs en cours de récupération peuvent générer des défauts de cache 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 d’autorisation, les règles WAF et les limites de connexion à l’origine peuvent différer d’un fournisseur à l’autre. Les journaux peuvent arriver dans des formats différents ou à des vitesses différentes au moment même où les intervenants en incident ont besoin d’une vue cohérente.

Le repli 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 d’hôte doivent être corrects. L’origine doit pouvoir absorber la demande et se défendre sans les services normalement fournis en périphérie. Un contournement qui rétablit les pages statiques mais désactive la connexion, le paiement, la recherche, la personnalisation ou les contrôles anti-abus peut être le mode dégradé approprié, mais ce mode nécessite une approbation métier explicite et une communication aux 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? Le chemin alternatif renvoie-t-il le même contenu essentiel et les mêmes en-têtes de sécurité? Peut-il gérer la charge attendue et une surtension de nouvelles tentatives? L’invalidation du cache et la publication d’urgence sont-elles disponibles? Les ingénieurs peuvent-ils l’exploiter en utilisant des identifiants, des appareils, des dépôts et des systèmes de communication extérieurs au 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 a posteriori. Ils ne rétablissent pas une transaction manquée, un avis public retardé ou un flux de travail de développeur. Un client qui s’appuie sur un SLA au lieu d’exercer le repli a transféré certaines conséquences financières, mais pas la responsabilité opérationnelle de la continuité.

Le multi-CDN est un modèle opérationnel, pas une case à cocher dans un achat

ThousandEyes a observé que les clients disposant de plusieurs fournisseurs de diffusion ont connu différents niveaux de succès. Certains ont déplacé le trafic racine loin de Fastly tout en continuant à charger des objets de page critiques depuis ce dernier. D’autres ont mis plus de temps à supprimer toutes les dépendances envers Fastly. Ce comportement illustre un piège de conception: orienter le trafic à la première requête ne suffit pas si la page nécessite par la suite des scripts, des styles, des API, des images, des polices, des redirections ou des ressources d’authentification provenant du fournisseur défaillant.

Un design multi-CDN exécutable possède au moins huit propriétés exigeantes.

Premièrement, la configuration doit être portable. Les clés de cache, les règles de TTL, le comportement du contenu périmé, la sélection des origines, les redirections, le code de périphérie, les politiques WAF, les contrôles anti-bots et la manipulation des en-têtes diffèrent selon le fournisseur. Une configuration nominalement équivalente peut se comporter différemment face à des requêtes inhabituelles. La portabilité exige une équivalence sémantique testée, et non un fichier traduit attendant dans un dépôt.

Deuxièmement, la résolution de noms doit permettre une modification rapide. Des valeurs de 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’aiguillage peut elle-même devenir une dépendance concentrée. Les organisations ont besoin de données de propagation mesurées issues d’exercices réels de basculement.

Troisièmement, l’origine doit accepter les deux fournisseurs de diffusion. Les listes d’autorisation réseau, le TLS mutuel, les requêtes signées, les contrôles de santé, les pools de connexions et les limites de débit doivent fonctionner avant une situation d’urgence. Un CDN alternatif qui ne peut pas s’authentifier auprès de l’origine est un actif d’inventaire, pas de la 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 aux utilisateurs nécessitent une diffusion indépendante. Un second fournisseur ne servant que des images peut améliorer les performances mais pas la disponibilité. La cartographie des dépendances devrait suivre les parcours utilisateurs plutôt que les contrats fournisseurs.

Cinquièmement, le fournisseur alternatif a besoin de capacité et d’une autorisation commerciale. Un fournisseur dormant peut ne pas avoir réservé de capacité pour un basculement mondial soudain. Les niveaux de trafic engagés, la tarification des pointes, les hypothèses DDoS et la réponse du support doivent être convenus à l’avance. On ne résout pas la concentration en créant un fournisseur secondaire qui tombe en panne à la première charge réelle.

Sixièmement, la télémétrie doit survivre. Des sondes externes devraient tester via différents réseaux d’accès et régions. Les journaux des deux fournisseurs doivent parvenir à un chemin d’analyse indépendant. Les pages de statut et les outils d’alerte ne devraient pas se trouver exclusivement derrière le service dont ils rapportent le statut. Le client doit pouvoir distinguer rapidement les défaillances au niveau DNS, routage, TLS, application de périphérie, origine et objet.

Septièmement, l’autorité doit être explicite. L’équipe du GOV.UK disposait d’un responsable d’incident et d’un seuil pour décider quand un repli dégradé était préférable. Sans cette conception décisionnelle, 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 à la normale exige la même rigueur que le basculement. Les caches, les réponses DNS, les sessions, les certificats et la charge d’origine peuvent être instables pendant que le trafic revient. La restauration initiale de Fastly et la résolution finale de l’incident étaient des jalons distincts. Les clients devraient définir leur propre point de récupération en se basant sur des parcours utilisateurs réussis et une capacité stable, et non en reflétant automatiquement la couleur du statut du fournisseur.

Ces exigences expliquent pourquoi le multi-CDN peut se justifier pour un service critique sans être économique pour tous les sites. Les petites organisations peuvent rationnellement accepter une courte panne plutôt que de financer une ingénierie de diffusion 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écupération proportionné et l’absence d’affirmation trompeuse selon laquelle une redondance fournisseur ordinaire couvre une défaillance logicielle à l’échelle de la plateforme.

La réponse de Fastly a été rapide, mais l’assurance publique était limitée

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

Ces faits ne doivent pas être minimisés. Une détection et une restauration rapides ont matériellement réduit les dommages publics. Les systèmes distribués tombent parfois en panne, et la responsabilité en matière d’incident devrait reconnaître tant la performance des contrôles que leur défaillance. Une organisation qui expose un défaut sévère puis le contient en moins d’une heure présente un risque différent de celle qui ne peut ni voir ni inverser l’état de sa propre plateforme.

L’autopsie publique laisse néanmoins le dossier de la prévention non résolu. Elle 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 chercherait une meilleure isolation grâce à WebAssembly et Compute@Edge. Elle ne publie pas l’enquête qui en a résulté, les responsables des actions, les échéances, les preuves de clôture ni une évaluation indépendante. Il n’y a pas d’explication publique sur la raison pour laquelle une configuration a affecté des services sans lien entre eux, si le déploiement était échelonné par POP ou par cohorte de clients, ni quel garde-fou empêche désormais la récurrence de la même classe de problèmes.

Cela n’établit pas que Fastly n’a pas mené ces actions en interne. Les grands fournisseurs transmettent souvent des rapports privés à leurs clients sous couvert de confidentialité. Cela fixe une limite à la confiance publique. Les observateurs extérieurs peuvent saluer la récupération constatée et les engagements exprimés; ils ne peuvent pas considérer le bref billet comme une preuve que la remédiation est achevée.

Lerapport trimestriel de Fastly pour juin 2021a converti l’événement en divulgation formelle des risques. Le dépôt décrit un bug logiciel non découvert causé par une erreur humaine, déclenché par une configuration client valide. Il indique que des clients avaient réduit ou supprimé le trafic et présenté des réclamations au titre des niveaux de service. Il a également divulgué des dépendances plus larges en matière de bande passante contractée et la possibilité que des pannes de fournisseur, des litiges, des défaillances de fournisseurs de réseau, des événements naturels, des limites de trafic ou la réglementation rendent cette capacité indisponible.

L’expression « causé par une erreur humaine » est moins informative que la chronologie technique de l’entreprise. Tous les logiciels sont écrits et exploités par des personnes. La question de gouvernance est de savoir quel système a permis qu’une action humaine ordinaire crée une défaillance étendue et corrélée. Le langage de l’erreur individuelle peut masquer les mécanismes de conception et d’assurance qui existent précisément parce que les personnes et le code sont faillibles.

Les données économiques ont fait de la fiabilité un enjeu de gouvernance

Lalettre aux actionnaires du deuxième trimestre de Fastlyindique que la panne a touché presque tous les clients. Les volumes de trafic ont diminué, des crédits clients ont été émis, quelques clients, dont un client du top 10, n’avaient pas encore rétabli leur trafic et plusieurs clients avaient reporté de nouveaux projets. Le modèle de Fastly étant basé sur l’usage, la baisse de trafic s’est directement traduite par une pression sur les revenus. La société a déclaré que la panne et le report de trafic affecteraient ses perspectives pour le troisième trimestre et l’ensemble de l’exercice.

La même lettre a fait état de 85 millions de dollars de revenus au deuxième trimestre et a fixé des prévisions de revenus annuels entre 340 et 350 millions de dollars, tout en indiquant que les perspectives reflétaient la panne, le calendrier de montée en charge du trafic et les renouvellements anticipés. Ces facteurs ne peuvent pas être clairement dissociés des chiffres publics, de sorte qu’il serait hasardeux d’attribuer l’intégralité du changement des attentes à une heure d’indisponibilité. La conclusion défendable est plus étroite: la panne a entraîné des crédits de service et des décisions de trafic des clients qui ont prolongé son impact économique au-delà de l’incident technique.

Lerapport annuel 2021 de Fastlya indiqué par la suite que les clients touchés avaient rétabli leur trafic, mais que tout le trafic n’était pas 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, ayant entraîné 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 néanmoins de la résilience des mises en production logicielles un sujet raisonnable pour une attention continue du conseil d’administration, plutôt qu’une anomalie opérationnelle ponctuelle.

Ladéclaration de procuration 2021de la société, déposée avant l’assemblée annuelle de juin, indique que le conseil était responsable de la supervision éclairée des risques et du suivi de l’exposition aux risques stratégiques, tandis que les dirigeants géraient les risques significatifs au quotidien. Elle a confié la supervision du risque lié à la sécurité de l’information au comité d’audit. Le document 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é par la suite. 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é relève de la supervision stratégique même lorsque le mandat affiché 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 prévisions de revenus et la confiance. Cela constitue un lien 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 de périphérie, mais ils ont besoin de preuves que la direction peut circonscrire une mise en production, isoler la configuration d’un locataire, rétablir le service en toute sécurité et vérifier la remédiation.

La responsabilité est partagée, mais elle n’est pas diluée

La responsabilité partagée est souvent invoquée après les incidents cloud comme si elle répartissait la responsabilité si largement qu’aucune partie ne demeure clairement comptable. La meilleure méthode consiste à attribuer la responsabilité en fonction de la capacité de contrôle.

Fastly contrôlait le déploiement du code qui a introduit le défaut. Il contrôlait l’analyseur syntaxique, 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 une modification limitée à un client pouvait affecter des clients sans lien entre eux, comment le logiciel atteignait les POP, ce que la surveillance pouvait voir et avec quelle rapidité 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 ni les inspecter ni les exploiter.

Les clients contrôlaient la décision de placer des parcours utilisateurs spécifiques derrière Fastly, la capacité et la sécurité des origines, l’utilisation d’un ou plusieurs CDN, les dispositions relatives au DNS et aux certificats, le contenu de repli statique, les chemins alternatifs et l’état de préparation des procédures de récupération. Ils contrôlaient également si les outils critiques de déploiement interne 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 pour chaque service ni financer le repli de chaque client.

Les partenaires de peering et les fournisseurs de transit ont transporté le trafic à destination et en provenance de Fastly, mais les informations publiques ne les identifient pas comme la cause. Leur diversité a peut-être contribué à maintenir le réseau joignable pendant que l’application défaillait. Attribuer la faute à « Internet » ou au protocole BGP effacerait les preuves au niveau des couches.

Le client qui a fourni la configuration déclencheuse contrôlait sa propre modification valide de service. Les informations publiques n’identifient pas le client, ne divulguent pas la configuration et ne suggèrent aucune faute. Une plateforme multi-locataire devrait supposer que des actions valides de la part des locataires se produiront. Aucune responsabilité ne devrait être attribuée à ce client au-delà du fait non étayé d’avoir été le déclencheur.

Les conseils d’administration des deux côtés contrôlaient l’appétit pour le risque et les exigences de preuves. Le conseil de Fastly pouvait demander si une mise en production de la plateforme dispose de contrôles indépendants du rayon de souffle et si une action d’un locataire peut franchir les frontières de service. Les conseils clients pouvaient demander quels services importants sont mono-fournisseur et si le temps de basculement reste dans les limites de la tolérance à l’impact de l’entreprise. Aucun des deux conseils ne peut déléguer sa question à l’autre.

Les régulateurs ont un rôle plus étroit mais important lorsque des fournisseurs communs soutiennent des secteurs critiques. Laboîte à outils sur le risque de tiersdu Conseil de stabilité financière distingue la gestion des tiers au niveau des entreprises de la nécessité pour les autorités d’identifier les dépendances systémiques. LaSS2/21 de la Banque d’Angleterresur l’externalisation et le risque de tiers attend des entreprises réglementées qu’elles gèrent la concentration et la résilience opérationnelle. LeDigital Operational Resilience Act (DORA)de l’UE a formalisé par la suite l’attention portée à la concentration des tiers TIC et à la responsabilité des organes de direction pour les entités financières concernées.

Ces cadres ne créent pas de constat rétrospectif à l’encontre de Fastly et ne s’appliquent pas de manière identique à tous les clients CDN. Ils indiquent l’orientation des politiques: les utilisateurs de services critiques restent responsables de leurs dépendances, tandis que les autorités de surveillance 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 exigeant des preuves différentes.

Ce que les conseils d’administration devraient exiger après une défaillance de périphérie latente

Le dossier destiné au conseil devrait commencer par une carte des domaines de défaillance, et non par la taille du parc. 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 isolés de manière indépendante. La carte devrait relier les versions logicielles, la distribution de la configuration, les frontières entre locataires, les plans de contrôle, le DNS, les certificats, la journalisation, la communication de statut, le shielding des origines et les outils de récupération 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û la rejeter ou la contenir?
• Pourquoi les tests de préproduction, les mises en production canary et l’intervalle de déploiement du 12 mai n’ont-ils pas permis de le révéler?
• Combien de clients, de POP et de requêtes une configuration ou une cohorte de mise en production peut-elle affecter avant un arrêt automatique?
• Les groupes canary 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éclencheuse sans dépendre du chemin de service défaillant?
• L’isolation à l’exécution transforme-t-elle un état malformé 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 plus larges de la même classe sont déployés partout où ils sont prévus?
• Quels indicateurs de récupération décrivent l’expérience client, la charge d’origine, le réchauffement des caches et les erreurs résiduelles, plutôt que seulement l’état de santé des nœuds?

Pour le client, le dossier devrait montrer les parcours utilisateurs importants et les ressources externes exactes que chacun nécessite. Il devrait nommer un responsable, une tolérance à l’impact, un mode de repli, un seuil de décision et la date du dernier exercice. Le temps de détection, de décision, de modification du DNS ou d’aiguillage, de diffusion d’un trafic significatif et de retour à la normale en toute sécurité 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.

Leguide de planification de la continuité du NISTpropose une séquence durable: analyse d’impact métier, contrôles préventifs, stratégies de récupération, plans, tests, formation, exercices et maintenance. Son champ d’application fédéral ne doit pas être confondu avec un mandat légal universel, mais le principe opérationnel s’applique bien. Un plan de récupération devient fiable par l’exercice et la maintenance.

Lesrecommandations du NIST sur le risque de la chaîne d’approvisionnementsoulignent de même la visibilité réduite sur la façon dont la technologie acquise est développée, intégrée et déployée. Un client CDN ne peut pas inspecter tous les composants internes du fournisseur. Il peut néanmoins exiger des conditions d’incident, une divulgation des dépendances significatives, des délais de notification, des preuves de récupération, des droits d’audit proportionnés à la criticité, la portabilité de la configuration, l’exportation des données et la prise en charge d’une sortie testée.

Les indicateurs devraient éviter les signaux verts faciles. « Deux CDN sous contrat » est faible. « 90 % des parcours critiques servis par l’alternative en huit minutes lors du dernier exercice inopiné » est plus fort. « Réseau mondial rétabli » est faible pour un client dont l’origine est surchargée. « Transactions réussies stables dans la limite du budget d’erreur normal pendant 30 minutes » est plus fort. « Bug corrigé » est faible sans une classe de régression, des preuves de déploiement et un responsable de clôture.

La leçon durable concerne la récupération indépendante

La panne de Fastly du 8 juin a été sévère, visible et relativement brève. Cette combinaison peut encourager de mauvaises conclusions. L’une est l’autosatisfaction: parce que la plupart des services sont revenus en 49 minutes, l’événement devient une histoire de récupération impressionnante. Une autre est le fatalisme: puisqu’un grand fournisseur peut tomber en panne, les pannes sont inévitables et aucune responsabilité supplémentaire n’est utile. Les preuves ne soutiennent ni l’une ni l’autre.

Une récupération rapide mérite d’être reconnue. Tout comme l’aveu de Fastly selon lequel il aurait dû anticiper la condition déclencheuse. Mais le défaut latent a survécu depuis le 12 mai, une seule modification valide d’un client a affecté la majeure partie du réseau, et le dossier de remédiation publique est resté mince. La prévention, le confinement, la réponse et l’assurance sont des contrôles différents. Une bonne performance en matière de réponse ne dispense pas des trois autres.

Pour les clients, l’incident a démontré qu’une origine, un second contrat ou une procédure DNS ne constitue pas automatiquement un chemin de récupération indépendant. Le fournisseur secondaire préparé du GOV.UK a impliqué une attente délibérée, un service dégradé et une propagation DNS. Le chemin de modification ordinaire de GitLab a touché une dépendance de paquet externe affectée par le même événement. Ce ne sont pas des arguments contre la planification de la continuité. Ce sont des preuves que les plans de continuité ne deviennent réels que lorsqu’ils sont exercés à travers toutes leurs dépendances.

Pour le risque réseau, la panne a montré pourquoi l’analyse du peering et du transit doit remonter la pile. La périphérie géographiquement distribuée et multi-connectée de Fastly a réduit de nombreux risques physiques. Elle n’a pas empêché un logiciel partagé de transformer cette périphérie en un seul domaine de défaillance logique. La même interconnexion qui offre des performances extraordinaires peut diffuser une erreur commune avec une portée égale.

Le jugement final en matière de responsabilité est donc spécifique. Fastly était responsable du défaut côté fournisseur, de sa propagation et des preuves que la classe de défaillance avait été contenue. Les clients étaient responsables de savoir ce qui devenait indisponible lorsque Fastly tombait en panne et de choisir un repli proportionné à ce préjudice. Les administrateurs étaient responsables de vérifier si les assurances du fournisseur et du client se rencontraient à une frontière de récupération réellement exécutable. Les régulateurs, lorsque des secteurs critiques étaient impliqués, étaient responsables de regarder au-delà des contrats individuels vers les dépendances communes qu’aucune entreprise ne pouvait voir seule.

La question pertinente après la prochaine défaillance de périphérie ne sera pas de savoir si le réseau est distribué. Elle sera de savoir si le destin logiciel, l’autorité opérationnelle et la capacité de récupération sont également distribués de manière indépendante.