Zusammenfassung

  • Fastly-Serviceversionen erlauben die Reaktivierung einer älteren Konfiguration; der aktive API-Status ist jedoch Steuerungssicht und kein Nachweis für alle ausführenden Populationen.
  • Die Abnahme muss je beobachtetem PoP die letzte alte Antwort, die restaurierte Version, den schädlichen Test und einen separaten Purge- oder Cache-Generation-Status erfassen.

Die Zentrale meldet Erfolg, die frühere Version ist wieder aktiv und die Fehlerrate sinkt. Trotzdem folgt eine Anfrage in einem entfernten PoP noch der zurückgezogenen Regel. Das ist ein hypothetischer Abnahmetest, kein gemeldeter Fastly-Vorfall. Er trennt Befehl von Ergebnis.

Bei Fastly ist eine Version eine konkrete Servicekonfiguration. Sie lässt sich klonen, sperren, aktivieren oder deaktivieren; nur eine ist aktiv, eine ältere inaktive Version kann erneut aktiviert werden. Das erleichtert Rückkehr, verführt aber dazu, die API-Antwort als Endzeit zu nehmen.

Fastlys eigenes Tutorial sagt, dass die Verteilung einige Minuten dauern kann. Das ist in einem verteilten System kein Defektbeweis, zeigt aber, dass Zentralzustand und globales Anfrageverhalten verschiedene Beobachtungen sind.

Ein PoP ist eine Ausführungspopulation

Fastly beschreibt einen PoP als Cache-Server-Cluster. Durch Clustering und Shielding kann eine Anfrage mehrere Standorte oder PoPs berühren. server.datacenter in VCL und FASTLY_POP in Compute identifizieren den Ort; die Serviceversion identifiziert die Entscheidungskonfiguration.

Der Canary muss die zurückgezogene Funktion auslösen: Pfadumschreibung, Zugriffsregel, Origin, Header, Cache-Key, Compute-Zweig oder Sicherheitsentscheidung. Ein allgemeiner Healthcheck beweist nur Erreichbarkeit.

Der erste Zeitpunkt ist die zentrale Bestätigung. Entscheidend ist die letzte Antwort unter der alten Version. Die Differenz ist das Konvergenzintervall. Maßgeblich ist das Maximum der beobachteten PoPs, nicht der Durchschnitt.

Logs beweisen Treffer, nicht zwingend Abwesenheit

Fastly bietet nahezu Echtzeit-Logs und Datacenter-Variablen. Eine alte Version nach der Frist ist ein positiver Beleg. Fastly erklärt zugleich, dass Logzustellung best effort und nicht garantiert ist; Datensätze können fehlen.

Keine alte Version im Stream bedeutet deshalb nicht automatisch weltweite Abwesenheit. Aktive Sonden, PoP- und Versionsmarker, echter Verkehr, Plattformbelege und eine Liste unbeobachteter Populationen müssen zusammenkommen. Anycast verhindert oft eine freie PoP-Auswahl; die tatsächliche Abdeckung gehört in den Bericht.

Konfiguration und Cache haben getrennte Uhren

Purge-all kann laut Fastly bis zu zwei Minuten dauern. URL- und Surrogate-Key-Purges verteilen sich in etwa 150 ms. Ein Edge-Cache-Key-Purge wirkt standardmäßig nur lokal. Soft Purge kann alte Objekte als stale verfügbar halten.

Fastly dokumentiert außerdem ein Rennen, bei dem ein Shield nach dem Purge alten Inhalt an das Edge zurückgibt. Für purge-all ist eine Cache-Generation in VCL und Compute sichtbar. Die Version kann also korrekt sein, während Objekt, Schlüssel, dynamische Daten oder Originzustand falsch bleiben. Ein Purge-Plan muss auch den Origin vor der Wiederbefüllung schützen.

Was 2021 belegt

Fastly führt die weltweite Störung vom 8. Juni 2021 auf einen unentdeckten Softwarefehler zurück, der durch eine gültige Kundenkonfiguration ausgelöst wurde. Beginn war 09:47 UTC, Identifikation 10:27, Erholung ab 10:36, Mehrheit bis 11:00, Minderung 12:35.

Das zeigt globale Wirkung und stufenweise Wiederherstellung. Es sagt nicht, dass ein bestimmter PoP eine zurückgezogene Regel behielt. Zulässig ist die Folgerung, Rollback-Zeit und Endnachweis separat abzunehmen.

Das Register verbindet Service, alte und restaurierte Version, zentrale Bestätigung, beobachtete Version und PoP, konkreten Canary, Trace, Generation, letzte alte und erste restaurierte Antwort, Abdeckung, Lücken und Abschlussverantwortung.

Quellen