Resumo

  • As versões de serviço da Fastly permitem reativar uma configuração antiga, mas o estado ativo da API é um fato do plano de controle, não prova de convergência de todas as populações.
  • A aceitação precisa registrar a última resposta da versão retirada por PoP, a versão restaurada, o teste do comportamento nocivo e o estado separado de purge ou geração de cache.

O painel central informa sucesso, a versão anterior volta a ficar ativa e os erros caem. Mesmo assim, uma solicitação em um PoP distante continua aplicando a regra retirada. É um teste hipotético, não um incidente atribuído à Fastly. A pergunta é se o comando e o resultado têm o mesmo horário.

Na Fastly, cada versão representa uma configuração. Ela pode ser clonada, bloqueada, ativada ou desativada; só uma fica ativa e uma versão antiga pode ser reativada. Isso facilita o retorno, mas torna tentador usar a resposta da API como conclusão.

O tutorial da própria Fastly diz que mudanças de configuração podem levar alguns minutos para se propagar. Não é, por si, defeito. Significa que estado central e comportamento global são observações distintas.

O PoP executa decisões

Fastly define PoP como um grupo de servidores de cache. Com clustering e shielding, uma requisição pode passar por mais de um local. server.datacenter em VCL e FASTLY_POP em Compute identificam a população; a versão do serviço identifica a configuração. Assim se mede qual versão decidiu, onde, quando e em qual teste.

O canário deve atravessar exatamente a regra retirada — reescrita, acesso, origem, cabeçalho, chave de cache, ramo Compute ou decisão de segurança. Um health check genérico não prova o rollback.

O primeiro tempo é o aceite central. O decisivo é a última resposta governada pela versão antiga. A diferença é a convergência, medida pelo máximo entre os PoPs observados, não pela média.

Logs são evidência incompleta

Fastly oferece streaming quase em tempo real e variáveis do data center. Um registro antigo depois do prazo prova falha. A empresa também afirma que a entrega é best effort e não garantida; registros podem ser perdidos.

Logo, não encontrar a versão antiga no log não prova ausência mundial. Combine sondas, marcadores de PoP e versão, tráfego real, telemetria e uma lista de populações não observadas. Anycast dificulta escolher qualquer PoP; a cobertura real deve ser declarada.

Configuração e cache têm relógios próprios

Segundo a documentação, purge-all pode levar até dois minutos; purges por URL ou surrogate key se propagam em cerca de 150 ms. Cache-key purge disparado no edge é local por padrão. Soft purge pode conservar objetos stale.

Fastly descreve ainda uma corrida em que um shield devolve conteúdo anterior ao edge depois da purga. Para purge-all, VCL e Compute expõem a geração de cache. Portanto, a configuração pode estar restaurada enquanto objeto, chave, dado dinâmico ou origem segue errado. Uma purga também precisa proteger a origem do pico de recarga.

O limite da evidência de 2021

Fastly diz que a interrupção global de 8 de junho de 2021 veio de um bug não descoberto acionado por uma mudança válida de configuração. A cronologia marca início às 09:47 UTC, identificação às 10:27, recuperação às 10:36, maioria recuperada às 11:00 e mitigação às 12:35.

Isso mostra que uma configuração válida pode ter impacto global e que a recuperação tem etapas. Não diz que um PoP específico manteve uma regra retirada. A conclusão legítima é exigir evidência própria de tempo e conclusão do rollback.

O registro deve juntar serviço, versão retirada e restaurada, aceite central, versão e PoP observados, canário exato, trace, geração, última resposta antiga, primeira restaurada, cobertura, lacunas e o responsável por encerrar o incidente.

Fontes