A linha de código que desperdiçou US$ 8.000

• Um bug de atualização automática no Screen Studio, app de gravação de tela para macOS, fez com que um arquivo de 250 MB fosse baixado repetidamente a cada 5 minutos
• Como resultado, em um mês foram gerados 2 PB (2.000.000 GB) de tráfego no Google Cloud, levando a uma conta surpresa de cerca de US$ 8.000
• A causa foi uma simples omissão no código: faltou a lógica para interromper as requisições repetidas após baixar a atualização
• Alguns usuários chegaram a sofrer prejuízos reais, como o cancelamento do serviço de internet, e a equipe de desenvolvimento assumiu total responsabilidade
• O caso reforça lições como configurar alertas de custo na nuvem, revisar código que possa gerar despesas e criar mecanismos de controle no servidor de atualização

---

Visão geral do incidente

• O Screen Studio é um app de gravação de tela para desktop no macOS com recurso de atualização automática
• O arquivo de atualização tem cerca de 250 MB, e o app verifica o servidor a cada 5 minutos
• Por causa do bug, mesmo após detectar a atualização, as requisições em intervalos de 5 minutos não eram interrompidas e o download continuava se repetindo

O início de um refactor trágico

• Antes, o pop-up de atualização atrapalhava durante gravações, causando um problema de UX
• Durante um refactor para melhorar isso, a equipe acabou removendo a lógica que parava o temporizador após a atualização
• Como resultado, o app passou a ter embutida uma lógica que baixava repetidamente o arquivo de atualização

O contexto assustador: execução em segundo plano

• Muitos usuários deixavam o app rodando em segundo plano por semanas
• Nesse estado, milhares de instâncias baixavam automaticamente 250 MB a cada 5 minutos

O desastre em números

• Download a cada 5 minutos = 288 vezes por dia
• Tráfego diário baixado por usuário = 72 GB
• Mantido por cerca de 30 dias, assumindo 1.000 usuários:
  • 250 MB × 288 × 30 × 1.000 = cerca de 2 PB de tráfego
• Custo estimado gerado no Google Cloud: cerca de US$ 8.000

A sequência de erros

• Alertas de custo do Google Cloud não estavam configurados
• Como a conta mensal anterior ficava na faixa de US$ 300, a situação foi subestimada
• No fim, o problema só foi percebido quando as transações passaram a ser bloqueadas por estouro do limite do cartão de crédito

Impacto para os usuários

• Um usuário recebeu da ISP (provedora de internet) um aviso de cancelamento do contrato de serviço por causa desse tráfego
• Não havia fornecedor alternativo na região → grande transtorno no dia a dia
• A equipe reconheceu a responsabilidade e ofereceu compensação pelos custos; felizmente, a situação foi resolvida de forma amigável
• Ainda assim, a experiência de causar prejuízo aos usuários deixou uma reflexão profunda nos desenvolvedores

Resumo das lições

• Alertas de custo na nuvem são indispensáveis
• A lógica de atualização automática deve ser escrita com extremo cuidado
• Todo código com potencial de gerar custos deve passar por revisão especial
• Sinais de controle no servidor (ex.: flag de atualização forçada) devem fazer parte do design
• O uso da nuvem deve ser verificado regularmente

[GN⁺]

Opiniões do Hacker News

• Para quem encontrar este tópico via busca na web no futuro: o screen.studio é um software de gravação de tela para macOS que verifica atualizações a cada 5 minutos. Porém, o bug descrito neste post fazia o download de um arquivo de atualização de 250 MB a cada 5 minutos

  • Os desenvolvedores consideravam tudo isso normal, mas os downloads reais geraram US$ 8.000 em custos de largura de banda
  • Resumo: o software de gravação de tela verifica atualizações a cada 5 minutos. Isso dá 12 vezes por hora
  • Eu escolho software com base no quanto confio no julgamento do desenvolvedor. Vale pensar se esse julgamento parece razoável

• O Screen Studio é um gravador de tela para macOS. É um aplicativo desktop. Eles afirmam que precisam de atualização automática para facilitar a instalação da versão mais recente

  • Porém, a atualização automática traz várias consequências negativas
  • Baixa atualizações sem o consentimento do usuário, gerando tráfego no cliente
  • O download continua repetidamente a cada 5 minutos. Fico na dúvida se detectaram quando o usuário está em uma conexão medida
  • Há um bug em que o pop-up de atualização interrompe o fluxo de trabalho
  • O próprio pop-up já oferece uma experiência ruim ao usuário. Seria melhor permitir quando o app fosse fechado e processar o resto em segundo plano
  • Alguns usuários observam com atenção as conexões de saída do app, e verificar atualização a cada 5 minutos é exagerado. Não há necessidade de fazer isso enquanto o app está em execução. Melhor verificar na inicialização e perguntar ao encerrar
  • A complexidade adicional no app que causou todos os problemas acima. Isso gera custo para o desenvolvedor
  • A App Store pode ser a forma perfeita de lidar com atualizações neste caso

• É absurdo que o desenvolvedor de um app não essencial, como um gravador de tela, ache que precisa verificar atualizações a cada 5 minutos

  • Uma vez por dia seria suficiente

• Fico me perguntando se realmente é necessário verificar atualizações a cada 5 minutos. Uma vez na inicialização já basta, e mesmo se o usuário deixar o app aberto por dias, dá para verificar uma vez por dia ou até menos

• Eu sempre sou rigoroso com code review. Uma vez, quando um gerente disse para deixar mais isso com o QA, respondi: "Todos nós podemos perder o emprego. Sempre podemos perder o emprego por causa de uma única linha de código ruim"

  • Muitas vezes um desenvolvedor júnior ou experiente acaba escrevendo algo que pode vazar PII. Em muitos sistemas, isso tem grande potencial de causar problemas legais

• A questão da largura de banda desperdiçada desnecessariamente por milhares de usuários em seus planos de dados

  • Erros descuidados como esse podem causar congestionamento para todos os usuários da internet
  • Se esse erro tivesse sido resolvido não com um custo de US$ 8.000, mas com o plano gratuito do Google Cloud ou outro plano, fico na dúvida se ainda assim teria sido considerado um bug grave e corrigido rapidamente
  • Quantos designs equivocados estão gerando tráfego e consumindo recursos compartilhados

• Quando eu distribuía um aplicativo desktop para Mac:

  • Usávamos Sparkle para lidar com atualizações. Escolher o atualizador próprio deles foi uma decisão ruim
  • Nosso aplicativo era muito complexo e vinha empacotado com Mono. Mesmo assim, tinha cerca de 10 MB. A versão para Windows tinha 2 MB e incluía binários de 32 e 64 bits. Fico pensando por que eles estão distribuindo um gravador de tela de 250 MB
  • Parece que eles não aprenderam a lição. O artigo inteiro faz com que pareçam tolos

• Surpreende que "testes melhores" não tenham sido mencionados no resumo

  • A sugestão de "escrever o código com cuidado" parece um erro de principiante
  • É muito frustrante quando desenvolvedores usam os dispositivos dos usuários como ambiente de testes

• Sou conservador quanto à adoção de bibliotecas de terceiros (porque cada biblioteca pode causar problemas no longo prazo), mas atualização de app vale a pena

  • Isso é basicamente um grande edge case e é uma parte importante do plano de recuperação caso o app tenha um bug sério
  • Esse bug não é o único problema do atualizador próprio deles. Verificar a cada 5 minutos é coisa de louco. Mostra que eles não pensaram nisso a fundo

• Eu opero um serviço de proxy anticensura que usa arquivos Proxy Auto-Configuration (PAC)

  • Se o arquivo contiver JavaScript incorreto ou tiver mais de 1 MB, ocorre um problema em que todos os apps continuam enviando requisições ao servidor quando ele está configurado para o sistema inteiro
  • Isso acabou fazendo um DDoS no meu servidor e levando ao bloqueio do IP em nível de BGP
  • Mais de 500.000 usuários usam isso diariamente. Meu servidor web roda em um VPS de US$ 20 por mês com tráfego ilimitado. Graças a isso, não passei por uma situação como a do OP