Résumé

  • Les versions de service Fastly permettent de réactiver une configuration antérieure, mais l’état « actif » de l’API ne prouve pas que toutes les populations qui servent des requêtes ont convergé.
  • L’acceptation doit consigner, par PoP observé, la dernière réponse gouvernée par la version retirée, la version restaurée, le test précis et, si nécessaire, l’état de purge ou de génération du cache.

L’écran central affiche « terminé ». L’ancienne version est de nouveau active et le taux d’erreur baisse. Pourtant, une requête routée vers un PoP lointain suit encore la règle que l’exploitation voulait retirer. Cette scène est un test hypothétique, pas un incident Fastly signalé. Elle sépare une commande d’un résultat.

Chez Fastly, une version représente une configuration précise. Elle peut être clonée, verrouillée, activée ou désactivée ; une seule version est active et une ancienne version inactive peut être réactivée. C’est un mécanisme de retour utile. Il crée aussi un horodatage trompeur : la réponse de l’API.

Le propre tutoriel de Fastly indique qu’une configuration peut mettre quelques minutes à se propager. Ce délai n’est pas un défaut en soi. Il signifie simplement que l’état central et le comportement mondial des requêtes sont deux observations différentes.

Le PoP est une population d’exécution

Fastly décrit un PoP comme un groupe de serveurs de cache. Avec clustering et shielding, une même requête peut rencontrer plusieurs sites ou PoP. Le code peut lire server.datacenter en VCL ou FASTLY_POP en Compute, et enregistrer la version de service. Ces identités permettent de répondre à une question concrète : quelle version a pris cette décision, où et quand ?

Un contrôle de santé générique ne suffit pas. Le canari doit exercer le comportement retiré : réécriture de chemin, règle d’accès, origine, en-tête, clé de cache, branche Compute ou décision de sécurité. Une réponse verte sur une fonction sans rapport ne prouve rien sur le rollback.

La première heure utile est l’accusé central. L’heure décisive est la dernière réponse encore régie par la version retirée. L’écart est l’intervalle de convergence. Il faut mesurer son maximum, pas sa moyenne.

Les journaux ont eux aussi une limite

Fastly permet de diffuser les journaux presque en temps réel et d’enregistrer le centre de données qui a servi la requête. Une ligne montrant l’ancienne version après l’échéance constitue une preuve positive. Mais Fastly précise que la livraison est best effort et non garantie ; des enregistrements peuvent être perdus.

L’absence d’une ancienne version dans un flux incomplet ne prouve donc pas son absence mondiale. Il faut combiner sondes actives, marqueurs PoP/version, trafic réel, télémétrie de plateforme et liste des populations non observées. L’anycast empêche souvent de choisir chaque PoP à volonté ; la couverture doit être déclarée, jamais inventée.

La configuration et le cache ne reviennent pas ensemble

La documentation Fastly décrit plusieurs horloges. Un purge-all peut durer jusqu’à deux minutes. Une purge d’URL ou de surrogate key se diffuse en environ 150 ms. Une purge par clé lancée depuis le edge ne concerne par défaut que le PoP local. Une soft purge peut laisser l’objet ancien utilisable comme stale.

Fastly documente aussi une course où un shield renvoie un contenu antérieur à un edge après la purge. Pour purge-all, la plateforme expose une génération de cache en VCL et Compute. Ainsi, la configuration peut être restaurée tandis que le contenu, la clé ou l’état d’origine reste faux. Si la récupération exige une purge, il faut également protéger l’origine contre la recharge brutale.

La portée de l’incident de 2021

Fastly attribue la perturbation mondiale du 8 juin 2021 à un bug logiciel non découvert, déclenché par un changement de configuration client valide. Sa chronologie place le début à 09:47 UTC, l’identification de la configuration à 10:27, le début de la reprise à 10:36, la majorité des services rétablis à 11:00 et l’atténuation à 12:35.

Cela prouve qu’une configuration valide peut interagir avec la plateforme à l’échelle mondiale et que la reprise a plusieurs étapes. Le billet ne dit pas qu’un PoP précis aurait conservé une règle retirée. La conclusion légitime est que le temps de correction et la preuve de fin méritent un critère d’acceptation.

Le registre doit rassembler service, version retirée et restaurée, heure de la commande, version observée par requête et PoP, test nocif, trace, génération de cache, dernière réponse ancienne, première réponse rétablie, couverture, trous de logs et responsable autorisé à clore l’incident.

Sources