Resumen

  • Las versiones de servicio de Fastly permiten reactivar una configuración anterior, pero el estado activo de la API no demuestra el comportamiento de todas las poblaciones que atienden solicitudes.
  • La aceptación debe registrar la última respuesta de la versión retirada en cada PoP observado, la versión restaurada, la prueba dañina y el estado separado de purga o generación de caché.

La consola central indica que el rollback terminó. La versión anterior vuelve a estar activa y los errores disminuyen. Sin embargo, una solicitud que llega a un PoP distante todavía ejecuta la regla retirada. Es una prueba hipotética, no un incidente atribuido a Fastly. Distingue el acuse de recibo del resultado.

Fastly define cada versión como una configuración del servicio. Puede clonarse, bloquearse, activarse o desactivarse; solo una permanece activa y una versión inactiva anterior puede reactivarse. Es un buen objeto de recuperación. También invita a usar como hora final el instante en que responde la API.

El tutorial de Fastly advierte que la configuración puede tardar un par de minutos en propagarse. Ese tiempo es normal en un sistema distribuido, pero demuestra que el estado central y el comportamiento global son observaciones diferentes.

Un PoP es un lugar de ejecución

Fastly describe el PoP como un grupo de servidores de caché. Con clustering y shielding, una solicitud puede atravesar más de un sitio o PoP. server.datacenter en VCL y FASTLY_POP en Compute permiten identificar dónde se atendió; la versión del servicio permite identificar qué configuración decidió.

El canario debe recorrer la conducta retirada: reescritura, permiso, origen, encabezado, clave de caché, rama Compute o regla de seguridad. Una respuesta genérica de salud solo prueba que algo responde.

El primer tiempo es el acuse central. El tiempo decisivo es la última respuesta gobernada por la versión antigua. El intervalo entre ambos es la convergencia real. Importa el máximo por población, no el promedio.

Ver un registro prueba; no verlo puede no probar nada

Fastly ofrece logs casi en tiempo real y variables para indicar el centro de datos. Una línea que muestre la versión antigua después del plazo es evidencia positiva. La compañía también dice que la entrega es best effort y no está garantizada; algunos registros pueden perderse.

Por eso, el silencio del log no certifica ausencia mundial. Deben combinarse sondas activas, versión y PoP en la respuesta, tráfico real, telemetría de plataforma y una lista de poblaciones no observadas. Anycast impide dirigir cada prueba a cualquier PoP; la cobertura debe expresarse como cobertura, no como certeza.

Caché y configuración tienen relojes distintos

La documentación de purga de Fastly dice que purge-all puede tardar hasta dos minutos. Las purgas por URL o surrogate key se propagan en unos 150 ms. Una purga por clave lanzada desde el edge es local al PoP salvo que se elija alcance global. La soft purge puede mantener contenido antiguo disponible como stale.

Fastly también documenta una carrera donde un shield devuelve contenido previo a un edge después de la purga. Para purge-all expone una generación de caché en VCL y Compute. Restaurar la versión no garantiza que el objeto, la clave o el estado de origen también sean correctos. Si hace falta purgar, el plan debe proteger el origen de la oleada de recarga.

Lo que aporta 2021

Fastly atribuyó la interrupción global del 8 de junio de 2021 a un bug no descubierto activado por un cambio válido de configuración de cliente. Su cronología sitúa el inicio a las 09:47 UTC, la identificación de la configuración a las 10:27, el comienzo de recuperación a las 10:36, la mayoría recuperada a las 11:00 y la mitigación a las 12:35.

El episodio muestra que una configuración válida puede interactuar con el software a escala global y que la recuperación tiene fases. No afirma que un PoP concreto retuviera una regla retirada. La conclusión legítima es exigir evidencia del tiempo y del final del rollback.

El registro debe unir servicio, versión retirada y restaurada, acuse central, versión observada por solicitud y PoP, prueba exacta, traza, generación de caché, última respuesta antigua, primera restaurada, cobertura, huecos y responsable que puede cerrar el incidente.

Fuentes