Estudo de caso · Fevereiro de 2017

Um comando mal digitado derrubou uma fatia da internet.

Uma única entrada incorreta num comando de depuração de rotina removeu mais servidores do que o previsto de um subsistema do AWS S3 — e o reinício demorou horas a mais do que o esperado, porque os sistemas afetados não tinham sido totalmente reiniciados havia anos.

custo da falha do AWS S3 falha do AWS us-east-1 em 2017 causa da falha do S3 exemplo de custo de falha de um provedor de nuvem
Ler os factos rápidos Modelar uma falha de infraestrutura
Deslize para ver a cronologia
~4 h Duração na região US-EAST-1
150 M$ Custo estimado para empresas do S&P 500
Factos rápidos

O que aconteceu, numa tabela.

As fontes estão ligadas no texto, incluindo o próprio resumo público da AWS após o incidente.

Data 28 de fevereiro de 2017, com início por volta das 9h37 (hora do Pacífico).
O que falhou Um engenheiro autorizado, seguindo um manual estabelecido para depurar o sistema de faturação do S3, executou um comando destinado a remover um pequeno número de servidores — mas uma entrada foi introduzida incorretamente, removendo um conjunto de servidores muito maior do que o previsto e deixando dois subsistemas centrais do S3 fora de linha, segundo o próprio resumo da AWS.
Escala A falha durou aproximadamente quatro horas na região US-EAST-1 e afetou uma grande parte da internet, uma vez que uma vasta gama de sites, aplicações e até outras ferramentas de estado da própria AWS dependiam do S3 para armazenamento ou configuração — a AWS nem sequer conseguiu atualizar o seu próprio painel de estado do serviço, porque o próprio painel dependia da região afetada.
Estrangulamento na recuperação Os subsistemas afetados tinham crescido tanto ao longo de anos de operação que nunca tinham sido totalmente reiniciados nessa escala, e o processo de reinício demorou substancialmente mais do que o previsto como resultado — uma lacuna de capacidade e de testes operacionais, não uma repetição do erro original.
Custo reportado O The Wall Street Journal reportou uma estimativa da empresa de modelação de risco cibernético Cyence segundo a qual a falha custou às empresas do S&P 500 cerca de 150 milhões de dólares no total — uma cifra amplamente citada, mas modelada por terceiros, e não uma soma de divulgações individuais das empresas.
Porque custou tanto

O raio de impacto foi o grafo de dependências de toda a internet.

Quase nada deste custo pertenceu aos próprios clientes da AWS do subsistema de faturação — pertenceu a todos os outros que dependiam do S3 sem perceberem quão profundamente.

01

Um comando de rotina continua a ser uma alteração em produção

O operador estava a seguir um manual estabelecido, não a improvisar — ainda assim, uma única entrada mal digitada teve um raio de impacto desproporcionado, razão pela qual a validação de entradas e os limites ao raio de impacto importam mesmo em comandos operacionais "de rotina".

02

Sistemas que nunca reiniciam são sistemas que não foram testados

A recuperação demorou mais do que o esperado precisamente porque os subsistemas afetados não tinham sido reiniciados anteriormente à sua escala atual — caminhos de recuperação não testados são uma fonte oculta de risco de MTTR que o crescimento de capacidade cria silenciosamente.

03

A dependência de terceiros é invisível até falhar

Empresas sem relação direta com o subsistema de faturação da AWS mesmo assim ficaram inoperacionais, porque a sua própria infraestrutura dependia silenciosamente da mesma camada de armazenamento regional — um lembrete para mapear, e não presumir, o seu raio de impacto real relativamente à região de um único fornecedor.

Perguntas frequentes

Falha do AWS S3, explicada.

Perguntas que surgem ao citar este incidente num caso de dependência da nuvem ou risco de fornecedores.

Isto foi um ataque à AWS? Não — a AWS atribuiu-o a um erro operacional interno durante um procedimento de depuração de rotina, e não a qualquer ataque externo.
Porque é que o valor de 150 milhões de dólares é uma estimativa de terceiros e não um número da própria AWS? A AWS não publica uma estimativa de custo para as suas próprias falhas; o valor de 150 milhões de dólares vem da modelação de risco cibernético da Cyence, conforme reportado pelo The Wall Street Journal, tornando-o indicativo em vez de um total auditado.
O que é que a AWS mudou depois? O resumo público da AWS descreveu alterações às suas ferramentas, incluindo salvaguardas para evitar a remoção de capacidade abaixo de um nível mínimo exigido e melhorias no tempo de reinício dos subsistemas.
Como é que isto se traduz na calculadora? Use a calculadora de tempo de inatividade de TI ou a calculadora de tempo de inatividade do site, consoante esteja a modelar infraestrutura interna ou o impacto voltado para o cliente de uma falha de um fornecedor.
A sua vez

Quanto custaria uma falha de um provedor de nuvem à sua operação?

Modele a sua própria pegada de dependências, receita e tempo de recuperação usando a mesma fórmula.

Abrir a calculadora de tempo de inatividade de TI Todos os estudos de caso

Modo

Cor de destaque