6 histórias assustadoras de falhas

1. Charity Majors, CTO da Honeycomb

• Notificações push não chegavam a usuários de uma região específica (Leste Europeu)

• Começou a acontecer logo após uma mudança no tamanho do ASG

• Ocorreu porque o registro DNS Round Robin ultrapassou o tamanho do pacote UDP

2. Matthew Fornaciari, CTO da Gremlin

• A falha aconteceu porque o disco ficou cheio e não foi possível gravar logs

• Desenvolvimento de funcionalidade de rotação de logs

• Configuração de alerta de uso de disco

• Adicionado para que fosse possível testar via Gremlin (engenharia do caos)

3. Lirran Haimovitch, CTO da Rookout

"A lenda urbana de que o servidor caía todos os dias em um horário específico,

após semanas de investigação, a causa foi encontrada em uma câmera de segurança,

o funcionário da limpeza desconectava o servidor para ligar o aspirador de pó"

4. Daniel "Spoons" Spoonhower, CTO da Lightstep

• O app não carregava

• Não houve deploy nem mudança de infraestrutura naquele dia

• Foi confirmado que apenas usuários internos eram afetados

• Ao verificar a API de carregamento do app, foi identificado que no caso de usuários internos havia uma parte que retornava dados adicionais

• Ao longo das semanas anteriores, o payload foi crescendo lentamente, e naquela tarde ultrapassou o tamanho máximo de payload, fazendo o carregamento do app falhar

5. Lee liu, CTO da LogDNA

6. Ting Huang, CTO da Transpoit

• Não podia ser lido no Twitter mobile

• Foi descoberto um problema na nova biblioteca que não conseguia fazer o parsing do cookie de sessão

[kunggom]

Nos cinco casos em que o conteúdo não foi resumido, o assunto parece ser expiração de certificado.

Achava-se que não haveria problema mesmo que os certificados expirassem conforme o previsto, mas isso só valia para os sistemas desenvolvidos mais recentemente; nos sistemas legados que ainda estavam em uso, acabaram surgindo problemas. Para piorar, o mesmo problema também aconteceu na solução de CI/CD que estavam usando, o que tornou tudo ainda mais complicado.

[kbumsik]

"O faxineiro desligou a conexão do servidor para conectar o aspirador de pó"

Nossa...

[kunggom]

Lendo o texto original, parece que esse conteúdo era só uma introdução, e que a falha real foi que uma consulta usada ocasionalmente pelo administrador do cliente durante reuniões bloqueava a tabela inteira, fazendo com que a latência do serviço de backend aumentasse sem limite toda vez que isso acontecia. Eles otimizaram a consulta suspeita, mas era um falso positivo, então o mesmo problema continuava ocorrendo sempre que o cliente achava a página lenta demais e ficava apertando atualizar repetidamente.

[kunggom]

Uma experiência pessoal parecida, se é que pode ser chamada assim. Foi quando assumi às pressas, como freelancer, um trabalho relacionado a um shopping online.

De madrugada, foi feita uma grande intervenção no shopping online (um upgrade amplo da versão da solução) e, depois de confirmar que não havia problemas nas funções principais, como pagamento de produtos, ele foi reaberto. Mas, à tarde, de repente o site do shopping online ficou muito lento e acabou chegando perto de parar quase completamente. Descobrimos que a causa era uma página separada para vendedores que estava conectada ao shopping. Eles operavam com uma página de administração para vendedores desenvolvida sob medida e integrada à solução do shopping, e, ao acessá-la, era executada uma consulta extremamente pesada. Depois da reabertura do shopping, cada vez que vendedores individuais acessavam para ver o status das vendas, a carga no MySQL aumentava, e isso acabou deixando o próprio shopping lento. Ao verificar, vimos que, por algum motivo, os índices da tabela relacionada não estavam configurados corretamente. No fim, foi possível resolver a lentidão do próprio shopping configurando corretamente os índices e ajustando alguns parâmetros.

[kbumsik]

Oh, obrigado por compartilhar a experiência.

De fato, como materiais para admin ou para tomada de decisão de negócios usam aggregation, isso deve gerar bastante carga. Não sou desenvolvedor web, então não sei muito bem, mas parece que hoje em dia fazem esse tipo de coisa chamando de engenharia de dados e reunindo os dados separadamente.

[kunggom]

Como você disse, o correto seria separar esses dados e processá-los à parte, mas o shopping online em que trabalhei era um sistema legado com vários pontos bem pouco razoáveis, então esse tipo de consideração arquitetural simplesmente não existia. Uma versão bem antiga do MySQL — da época em que o mecanismo padrão ainda era o MyISAM, e não o InnoDB — rodava dentro da mesma instância de VM junto com uma versão igualmente antiga do servidor web Apache. A solução usada para operar o shopping também já era classificada como legado e estava em uma situação em que só recebia patches. Pelo que senti durante o trabalho, os problemas estruturais da solução aparentemente foram resolvidos em uma nova versão reescrita do zero, mas isso não teve impacto nenhum para mim, que estava lidando com a versão legada. E isso já foi no ano passado.