#028 – Qualidade de Software: Bugs que Matam

No segundo episódio da série sobre Qualidade de Software trazemos alguns casos famosos de bugs que causaram grandes prejuízos e até mortes. Buscando extrair dessas experiências trágicas de algumas empresas, ensinamentos sobre como evitar que bugs graves escapem para a produção. Discutimos a importância de analisar os riscos adequadamente quando nosso sistema se integra com outros ou com elementos de hardware.

Continue compartilhando com seus amigos nas redes sociais e deixe o seu comentário aqui no site, no nosso Twitter @podebug, na nossa página do Facebook ou mande um e-mail para [email protected]

Para baixar: Arquivo MP3

Assine o Podcast

Links do Episódio

Artigo: 10 of the most costly software errors in history
Slides: KILLER APPS
Artigo: An Unprecedented Look at Stuxnet, the World’s First Digital Weapon
Dica do Borba: Halt and Catch Fire (Série de TV)
Dicas do Vladimir: Count Down to Zero Day (Livro)
Dicas do Marcelo: The Decline and Fall of IBM: End of an American Icon? (Livro)

Créditos

Música tema e audio clips por Jason Shaw do site audionautix.com
Música de encerramento do site audioblocks.com
Edição e mixagem por Marcelo Lv Cabral

2 Responses to "#028 – Qualidade de Software: Bugs que Matam"

Fred Monteiro disse:

08/08/2016 às 23:22

Minhas contribuições para o mundo dos bugs…

Historinha 1:

Há cerca 15 anos eu participei do desenvolvimento de uma aplicação móvel de vendas. Uma das partes pelas quais eu era responsável era pelo módulo de comunicação, que era o responsável por enumerar os pedidos que foram emitidos no PDA e enviar para o sistema de retaguarda. Pelo fato de eu ter assumido um determinado comportamento vindo do sistema de retaguarda, a implementação do lado do cliente executava operações recursivas desnecessárias e por isso em alguns cenários sofria um estouro de pilha (stack overflow, nada a ver com as baterias). A aplicação caía e isso era o máximo que o usuário notava.

O problema é o que vinha depois… De acordo com a documentação do sistema de retaguarda, pedidos que não fossem efetivados do lado deles (commit) eram descartados, então a aplicação deveria reenviar tudo do zero. O porém é que o código do lado deles fazia commit no banco de dados, independente do resultado da comunicação. Resultado, os pedidos ficavam duplicados. Soube depois que teve gente recebendo 16 fardos de papel higiênico, quando havia encomendado apenas 1… Um produto adequado ao problema, diga-se de passagem.

Mas os problemas não pararam por aí… O código do sistema de retaguarda não estava sob nenhum controle de versão, tudo era copiado/colado e comentado. Os comentários não esclareciam o que foi mudado, nem porque e muito menos quais mudanças estavam relacionadas entre si (todos eram do tipo “comentado por fulano em 30/7/2002”).

Enquanto eu ajudava o desenvolvedor deles a debugar esse problema, ele mexeu em partes do código que não eram relacionadas com a solução (comentou, descomentou, modificou, etc). Isso causou uma regressão em produção (porque, claro, o código era compilado localmente e o .EXE copiado direto nos servidores de produção).

Para resolver a regressão, ele precisou restaurar um backup do .EXE no servidor de produção, porque… não… tinha… backup… do… código… fonte…

Depois de muitas idas e vindas (madrugada adentro), ele finalmente conseguiu aparentemente reverter a regressão no fonte e retestar tudo manualmente (se não tinha backup nem controle de versão, obviamente também não tinha testes automáticos).

O resultado dessa brincadeira foi um prejuízo financeiro para a empresa que era nossa cliente (porque eles tiveram que ressarcir os clientes pelos itens não-solicitados), perda de confiança para os clientes deles e perda das comissões dos vendedores.

A parte em que eu fiquei sequestrado até resolver tudo (eles me pagaram uma passagem só de ida para a sede da empresa, a volta estava condicionada a resolver esse e os demais problemas), fica pra outra ocasião 🙂

Historinha 2:

Outro problema que a gente teve num outro projeto para um cliente grande foi que um dos desenvolvedores mantinha uma cópia em papel do esquema do BD na sua gaveta. Um dia ele precisou fazer uma operação e não teve dúvidas, pegou o papel da gaveta e fez a mudança no código. Quando o código chegou em produção, descobriu-se que a performance do sistema estava horrível, tinha ficado de 10 a 100 vezes mais lento.

Depois de muitas horas de debug, descobrimos que a causa tinha sido que uma das tabelas do banco tinha sido desnormalizada e o modelo em papel não refletia mais isso. Resultado, a consulta que foi escrita considerava o formato original, que causava um custo muito mais alto por conta dos índices terem sido mudados.

Historinha 3:

Pra terminar, essa foi do tempo da faculdade… Nossa professora do curso de Sistemas Operacionais tinha passado como projeto da disciplina escrever um Shell pro Unix. A idéia era muito simples, algo assim:

while (true) {
scanf(&comando);
if (strcmp(comando, “exit”)) { break; }
else if (strcmp(comando, “X”)) { execute(X); }
…
else {
// Caso nao seja um dos comandos pre-definidos, execute o comando como se fosse um programa
pid = fork();
if (pid != 0) { exec(comando); } // O processo pai sempre voltava do fork com o pid zero (acho)
}
}

No laboratório, uma das equipes fez um programa similar a esse e rodou. Tudo funcionava bem até que alguém digitou um backspace (ferrava com o scanf quando o código era mal-escrito como o nosso).

Aí a tela começou a rolar e depois de alguns segundos a mensagem “No more processes” aparecia. O terminal travava. O pessoal foi pedir penico à nossa sysadmin.

Outra equipe logou noutra máquina, modificou umas coisas e rodou. Mesma coisa. Depois de algum tempo, “No more processes” e mais outra turma na fila do penico.

Acho que ainda teve mais uma equipe que tentou e quebrou as máquinas antes que eu decidisse que eu tinha achado a solução e ter quebrado a última máquina restante. Lá vou eu pra a sala da sysadmin…

Chegando lá, estava todo mundo p da vida, porque a gente tinha simplesmente achado uma espécie de bug de configuração no SunOS, onde um usuário individual podia ficar criando processos e mais processos na máquina (fork faz isso) até um ponto em que nem o super-usuário conseguia ter uma entrada na tabela de processos pra rodar um logon.

Resultado, derrubamos praticamente todas as máquinas Unix do departamento, incluindo os servidores de e-mail, web, servidores dos professores e dos laboratórios da pós. Quando voltamos, tinha gente desesperada pelos corredores porque tinham perdido seções inteiras das teses de mestrado e doutorado quando as máquinas travaram e tiveram que ser desligadas “puxando o fio”. Foram horas até o sistema voltar a funcionar…

Responder
1. Luiz Borba disse:
  
  09/08/2016 às 18:13
  
  haahahahaaha… muito bom… mas pelo menos não matou ninguém…
  
  Responder

Deixe um comentário Cancelar resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.