Um comando digitado errado tira metade da internet do ar

Impacto: Quase 4 horas de indisponibilidade do S3 em US-EAST-1, derrubando junto uma fração enorme da web que dependia dele.

O que aconteceu

Um engenheiro autorizado executava um procedimento de rotina para investigar uma lentidão no sistema de cobrança do S3. O comando removia um pequeno número de servidores de um subsistema.

Um parâmetro foi digitado errado, e o comando removeu muito mais servidores do que a intenção — incluindo servidores de dois subsistemas essenciais: o de índice, que guarda os metadados e a localização de todos os objetos, e o de posicionamento, que aloca armazenamento novo.

Sem o subsistema de índice, o S3 não conseguia atender requisições de leitura, escrita ou listagem. E aí veio a parte que transformou o erro em desastre: aqueles subsistemas não eram reiniciados por completo havia anos. O processo de partida precisou rodar do zero, validar a integridade dos metadados, e isso levou horas.

O efeito cascateou de um jeito quase cômico: o próprio painel de status da AWS dependia do S3 na mesma região, e por isso não conseguia mostrar que o S3 estava fora.

A linha do tempo

T+0
Comando de manutenção executado com o parâmetro errado.
T+~1min
Servidores demais são removidos; os subsistemas de índice e de posicionamento perdem capacidade abaixo do mínimo.
T+~5min
S3 passa a recusar requisições em US-EAST-1.
T+~30min
Serviços dependentes começam a cair em efeito dominó pela web.
T+2h48
Subsistema de índice volta a operar após reinício completo.
T+3h58
Operação normal restabelecida.

A causa raiz

A causa raiz não é o typo — é que existia um comando capaz de remover capacidade sem limite, num sistema cujo tempo de recuperação ninguém conhecia porque nunca fora exercitado. O erro humano foi o gatilho; o raio de alcance ilimitado e o reinício não testado foram o incidente.

Antes do incidente

O que você colocaria na pilha para conter o estrago?

O que mudou depois

A ferramenta de manutenção passou a impedir que a capacidade caia abaixo de um mínimo de segurança, e a remover servidores mais devagar.
Os subsistemas foram particionados em células menores, para que o tempo de recuperação de qualquer uma seja conhecido e curto.
O painel de status foi movido para não depender da região que ele monitora.

Fonte: AWS — *Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region*, março de 2017