A alteração de configuração de um único cliente quebrou um quinto da web.

Uma única alteração de configuração, válida por si só, feita por um cliente da Fastly, despoletou um erro latente com cinco semanas e deixou 85% da rede da Fastly fora do ar — arrastando consigo o Reddit, a Amazon, a Twitch, sites governamentais e grandes órgãos de notícias em todo o mundo, em simultâneo.

custo da falha da Fastly causa da falha de CDN falha da Fastly de junho de 2021 risco de dependência de fornecedor único
Percorra para ver a cronologia
49 min Da deteção a 95% recuperado
85% Da rede da Fastly a devolver erros

O que aconteceu, numa só tabela.

A Fastly nunca revelou um custo financeiro para este incidente, o que é, em si, digno de nota — este estudo de caso é incluído pela sua lição sobre a velocidade de resposta, não pelo valor em dólares.

Data 8 de junho de 2021, aproximadamente entre as 05:50 e as 06:45, hora do leste dos EUA.
O que falhou Uma implementação de software a 12 de maio tinha introduzido um erro latente que só podia ser despoletado por uma configuração de cliente específica. A 8 de junho, um cliente implementou uma alteração de configuração válida que coincidiu exatamente com essas condições, segundo o resumo da própria Fastly.
Escala Cerca de 85% da rede da Fastly começou a devolver erros, derrubando Reddit, Twitch, Spotify, PayPal, Shopify, Stripe, gov.uk e grandes órgãos de notícias, incluindo CNN, The Guardian e The New York Times — sites sem qualquer relação entre si além de partilharem a mesma CDN.
Recuperação A Fastly detetou a interrupção em menos de um minuto, identificou e desativou o fator desencadeante e conseguiu que 95% da sua rede voltasse a funcionar normalmente em 49 minutos — uma das recuperações mais rápidas de uma falha de escala global nesta lista.
Custo reportado Ao contrário dos outros estudos de caso aqui apresentados, nenhum custo financeiro agregado foi divulgado publicamente pela Fastly nem estimado de forma independente para este incidente — um lembrete de que muitas falhas de grande visibilidade nunca chegam a produzir um valor em dólares citável.

O erro era antigo. O gatilho era novo.

Este incidente mostra tanto o risco da infraestrutura partilhada como o aspeto de uma resposta a incidentes bem ensaiada.

01

Os erros latentes esperam pelo gatilho certo

O defeito esteve ativo em produção durante quase quatro semanas antes de a configuração de algum cliente o ativar por acaso — um lembrete de que "ainda não houve incidentes" não é o mesmo que "não existe risco".

02

A ação de um cliente, a falha de todos

Uma única alteração de configuração válida e permitida de um único cliente foi suficiente para degradar a plataforma partilhada para todos os outros clientes — a infraestrutura multi-inquilino precisa de controlos de raio de impacto que não dependam de nenhum cliente em particular agir com cautela.

03

A deteção rápida muda toda a curva de custos

Um tempo de deteção de um minuto e uma recuperação de 49 minutos mantiveram este incidente suficientemente curto para que, ao que parece, nenhuma das empresas envolvidas tenha divulgado uma perda específica — a prova de que investir no MTTR compensa precisamente quando é mais necessário.

A falha da Fastly, esclarecida.

Perguntas que surgem ao citar este incidente num caso de dependência de CDN ou de resposta a incidentes.

Isto foi um ciberataque? Não — a Fastly atribuiu-o a um erro de software despoletado por uma alteração de configuração legítima de um cliente, e não a qualquer ataque externo.
Porque não existe um valor de custo para este incidente? Nem a Fastly nem os sites dos clientes afetados divulgaram publicamente um impacto financeiro — a curta duração da falha provavelmente limitou o incentivo ou a necessidade de o quantificar publicamente.
Porque é que tantos sites sem relação entre si caíram ao mesmo tempo? Todos eles utilizavam a Fastly como a sua rede de distribuição de conteúdo, pelo que uma falha na infraestrutura partilhada da Fastly afetou todos os clientes que dependiam da mesma capacidade afetada, independentemente das práticas de fiabilidade de cada site.
Como é que isto se traduz na calculadora? Use a calculadora de tempo de inatividade do site com um MTTR curto para ver o quanto uma recuperação rápida limita a exposição total, mesmo em grande escala.

Quanto lhe custaria uma falha detetada e resolvida rapidamente?

Simule o seu próprio tráfego, receita e um MTTR curto usando a mesma fórmula.

Modo

Destaque