- Um novo proprietário de um Pontiac reclamou à General Motors Pontiac Division que, todas as noites, depois de comprar sorvete, o carro só não dava partida quando ele escolhia baunilha
- O presidente da Pontiac desconfiou da carta, mas enviou um engenheiro, e no local foi de fato reproduzida a falha na partida após comprar baunilha
- Nos dias em que comprou chocolate e morango, o carro ligou, mas no dia em que comprou baunilha falhou de novo, confirmando repetidamente uma condição que parecia absurda
- O engenheiro registrou horário, tipo de combustível, tempo de ida e volta e tempo de compra, até descobrir uma diferença no trajeto dentro da loja: só a baunilha podia ser comprada rapidamente em um freezer separado na frente da loja
- A causa não era o sabor do sorvete, mas sim o vapor lock, provocado pelo curto tempo de compra, que não deixava o motor esfriar o suficiente; mesmo relatos estranhos precisam ser verificados com observação e reprodução
O estranho problema de partida do Pontiac
- Um proprietário de Pontiac enviou uma segunda carta à Pontiac Division da General Motors
- A família decidia por votação qual sabor de sorvete comer de sobremesa todas as noites após o jantar, e ele sempre ia de carro até a loja para comprar o sorvete
- Depois de comprar um Pontiac novo, o problema se repetia apenas em uma condição específica
- Se comprasse sorvete de baunilha, não conseguia dar partida no carro ao voltar da loja
- Se comprasse outros sabores, o carro ligava normalmente
- Ele reconhecia que a pergunta podia soar tola, mas queria saber por que o Pontiac só não ligava quando ele comprava baunilha
Verificação no local e reprodução repetida
- O presidente da Pontiac viu a carta com ceticismo, mas mandou um engenheiro para verificar pessoalmente
- O engenheiro encontrou o dono do carro logo após o jantar e foi com ele até a sorveteria
- Naquele dia era dia de comprar baunilha e, quando os dois voltaram ao carro, de fato ele não deu partida
- Nos três dias seguintes, ao variar as condições, o resultado foi claro
- No primeiro dia, quando comprou chocolate, o carro ligou
- No segundo dia, quando comprou morango, o carro também ligou
- No terceiro dia, quando comprou baunilha, voltou a falhar na partida
A pista encontrada no registro de observações
- O engenheiro não aceitou a interpretação de que o carro era alérgico a sorvete de baunilha
- Decidiu continuar visitando o local até resolver o problema e passou a registrar vários dados
- horário
- tipo de combustível usado
- tempo de ida e volta até a loja
- tempo gasto na compra
- A pista decisiva era que o tempo de compra da baunilha era menor do que o dos outros sabores
- A disposição da loja estava criando essa diferença de tempo
- A baunilha, por ser o sabor mais popular, ficava em um freezer separado na frente da loja para poder ser pega rapidamente
- Os outros sabores ficavam em outro balcão, no fundo da loja, e levavam muito mais tempo para serem encontrados e pagos
A causa real: vapor lock
- O ponto central do problema não era o sabor do sorvete, mas sim o curto tempo de espera
- Depois de perceber que o fator determinante era o tempo, o engenheiro identificou o vapor lock como a causa
- O vapor lock acontecia todos os dias, mas, quando ele comprava outros sabores, o tempo de compra era maior, o motor esfriava o suficiente e o carro podia dar partida
- Quando comprava baunilha, o tempo de compra era curto demais, o motor ainda estava quente e o vapor lock não desaparecia, impedindo a partida
Lição
- Mesmo um problema que parece não fazer sentido pode estar baseado em fatos observáveis
- Ainda que pareça um sintoma absurdo, repetir as condições e coletar dados pode levar à descoberta da causa real
1 comentários
Comentários do Hacker News
Aconteceu algo parecido no trabalho no fim dos anos 90. O mouse de um funcionário só travava em determinados horários do dia; de manhã funcionava bem, perto do almoço parava e depois voltava a funcionar
A pista decisiva foi que, em dias nublados, ele funcionava perfeitamente o dia inteiro, mas, em dias ensolarados, o mesmo comportamento estranho se repetia. No fim, a carcaça plástica de um mouse de esfera barato era fina demais, então, nos dias ensolarados, a luz do sol sobrepujava o LED nos sensores dos eixos X/Y, e ele só voltava a funcionar normalmente depois que o sol se movia e uma sombra se formava. No começo parecia absurdo, mas a causa era totalmente lógica
Algumas versões do jailbreak Pangu para iOS 7.1.x aparentemente travavam durante a inicialização quando o valor do sensor de luz ambiente ficava abaixo de um certo limiar. Ainda não se sabe a causa exata, mas parece que havia no Pangu um código desnecessário que mexia no sensor de luz [1]
[1] https://www.reddit.com/r/jailbreak/comments/294wob/jailbreak...
[2] https://www.reddit.com/294wob/
Depois de verificar todo tipo de problema, descobri que isso acontecia não quando chovia, mas quando havia neblina densa ou garoa. A inspeção do técnico da operadora de cabo mostrou que dentro de casa estava tudo em ordem, mas havia um corte minúsculo no cabo que vinha da linha principal até a casa, por onde a umidade do ambiente entrava e estragava a conexão
Quando o reservatório de gelo enche, um feixe infravermelho deveria ser bloqueado e parar a produção, mas, em dias ensolarados, a luz forte da cozinha engana o sensor e faz a máquina continuar produzindo gelo. Por isso deixamos uma revista qualquer em cima dela para que funcione corretamente
Um dia, do nada, testes relacionados a um aplicativo cliente gráfico X começaram a falhar de forma intermitente, mas não era possível reproduzir em outras condições. No fim, as tarefas de CI estavam rodando em desktops deixados em algum lugar dentro da empresa, e alguém havia conectado um mouse a uma máquina e o deixado em uma prateleira. Quando a carga da máquina aumentava, a ventoinha acelerava e a vibração crescia, fazendo o mouse se mover um pouquinho; por algum motivo desconhecido, isso causava efeitos colaterais nos testes. Fiquei bem orgulhoso de ter diagnosticado por SSH uma máquina que eu nem tinha diante de mim
No fim, painéis solares, ou otimizadores, ou inversores estavam emitindo uma radiofrequência que interferia no controle remoto da porta da garagem. Quando havia luz do sol e eles geravam energia, a interferência ficava mais forte que o abridor de garagem homelink. Alguns anos atrás, o abridor da garagem de repente começou a funcionar bem, e alguns dias depois descobri que era porque o inversor tinha queimado. Pelas regras da FCC, talvez a instaladora tivesse que consertar, mas a relação azedou na instalação, então achei melhor abrir mão do controle remoto do que lidar com eles em um reparo de garantia
Uma história engraçada que ouvi de segunda mão, da época em que havia sala de servidores. O servidor da empresa de um amigo reiniciava todos os dias por volta das 17h e, mesmo verificando tudo o que era possível no lado do sistema operacional, não encontravam a causa
No fim, decidiram ficar em pé diante do servidor naquele horário e viram a pessoa da limpeza entrar na sala, tirar da tomada a alimentação do rack de servidores, plugar o aspirador de pó, limpar a sala e depois ligar o rack de servidores de novo
Uma das câmeras reiniciava todos os dias quase no mesmo horário; não era exatamente no mesmo segundo, mas havia um padrão claro: em um dia às 19:12:10, no dia seguinte 2 segundos depois, no outro dia mais 2 segundos depois, e assim por diante. Descobriu-se que, ao pôr do sol, a sombra de uma instalação urbana caía na frente da câmera, e o software a interpretava erroneamente como um veículo e começava a coletar informações de classificação. Como a sombra se movia muito mais devagar do que um veículo real, a memória se esgotava antes que ela saísse do quadro; o sistema travava e então o watchdog o reiniciava. O padrão de horário existia porque o ângulo do sol mudava a cada dia, fazendo a sombra enganar o algoritmo um pouco mais tarde
[0] https://old.reddit.com/r/talesfromtechsupport/comments/5yrs1...
[1] https://www.goodreads.com/book/show/3227607-the-devouring-fu...
Depois de ficar sentado lá durante uma semana nesse horário, vi as luzes diminuírem e o reboot acontecer. O advogado do escritório ao lado chegava ao trabalho e ligava, ao mesmo tempo, o PC, a impressora e a cafeteira na mesma régua de tomadas; por causa da corrente de partida, a tensão do circuito ao qual o servidor estava conectado caía. Havia um UPS, mas os UPSs de consumo da época só lidavam com quedas de energia; medi a tensão caindo até 85V, e de fato ele costumava reiniciar quando ficava abaixo de 95V
Era uma sexta-feira no começo da tarde, o tempo estava quente e úmido e uma tempestade se aproximava; por volta das 16h, o responsável veio dizer que às 17h cortariam a energia de todo o prédio, então eu precisava me apressar. Toda sexta-feira eles desligavam a energia para economizar, e justamente às 16h30 de toda sexta estava agendada uma limpeza do banco de dados. Então, na hora que restava, corrigi o problema, cancelei a tarefa daquela semana e desliguei manualmente o servidor de banco de dados. Ao cortar a energia à força toda semana, eles causavam indisponibilidade de produção no servidor Netware e no servidor de banco de dados do software de arrecadação, e, pelo contrato de manutenção, nós tínhamos que consertar toda vez. No fim, só cerca de um mês depois eles adiaram o corte forçado de energia para sábado de manhã, permitindo que, após a conclusão do backup, o servidor pudesse ser desligado corretamente
Isso me lembra a minivan da GM que meu cunhado dirigia nos anos 80. Era um carro que meu sogro, engenheiro automotivo da GM, tinha dado a ele; de vez em quando, aleatoriamente, ela não dava partida e todo o sistema elétrico parecia morto
Como meu cunhado era visto como alguém que não entendia de carros, meu sogro não levava a reclamação a sério. No fim, eles trocaram de carro por um mês; o problema se reproduziu no estacionamento do GM Technical Center, e nem os engenheiros da GM que se juntaram em volta conseguiram descobrir por que o sistema elétrico parecia morto, então meu cunhado pôde tirar o peso de ter sido injustiçado
Algumas horas depois, ele ligava como se nada tivesse acontecido, então a concessionária também não conseguia diagnosticar. Mais tarde, começou a afetar minha vida, inclusive ficando sem dar partida durante acampamentos off-road; por fim, quando ele não ligou na entrada da minha casa, mandei rebocar para uma oficina independente, e lá o problema também se reproduziu. O mecânico sugeriu trocar o módulo da ECU ou trocar a própria caixa de fusíveis; a ECU custava milhares de dólares, mas a troca da caixa de fusíveis, incluindo mão de obra, ficava abaixo de 200 dólares, então escolhi a segunda opção. Seis ou sete anos depois, esse carro ainda é meu único carro principal, e desde então ele nunca teve nenhum problema mecânico
É perfeitamente plausível que veículos da GM de uma época notória sofressem problemas elétricos misteriosos de enlouquecer qualquer um
Acho que algum relé em algum lugar superaquecia e ficava preso na posição fechada, mas eu mesmo não consegui depurar, e meu primo, que era mecânico, também não encontrou. Não me esforcei muito; quando isso acontecia, eu tirava o fusível e o colocava de volta na manhã seguinte
Muitas vezes o motor de arranque girava bem, mas os eletrônicos ficavam presos em um estado estranho, e só saíam disso depois de desconectar a bateria para fazer um hard reset
Em uma casa antiga, passei por um fenômeno estranho e recorrente envolvendo aparelhos eletrônicos. À meia-noite de um determinado dia da semana, saía bem baixinho, de aparelhos eletrônicos fixos, um som que parecia uma gravação de discurso político da Segunda Guerra Mundial
O som era tão fraco que era difícil identificar um ponto específico, e não dava para entender as palavras, então parecia que uma gravação antiga estava vindo de todos os lados ao mesmo tempo. Continuava mesmo tirando tudo da tomada, e até quando faltava luz na casa. Achei que eu estava enlouquecendo ou que a casa era assombrada pelo fantasma de Hitler, mas depois ouvi algo parecido no rádio do carro e entendi. Uma estação de rádio AM católica começava a transmissão no mesmo dia e no mesmo horário com canto gregoriano e sermões, e a fiação da casa, de algum modo, estava funcionando como um receptor de rádio AM, fazendo alguns componentes vibrarem com o áudio carregado no sinal de rádio
Sempre que meu filho jogava American Truck Simulator, a tela do notebook apagava e, enquanto ficava preta, o caminhão saía da estrada
Quando eu jogava no mesmo notebook, isso não acontecia, então meu filho tinha certeza de que estava amaldiçoado. Depois de vários dias disso se repetir, fiquei ao lado dele observando enquanto jogava e percebi que a pulseira do relógio dele era uma pulseira metálica com fecho magnético. A posição do pulso estava acionando o sensor Hall do notebook, fazendo-o achar que a tampa tinha sido fechada. Meu filho, eu e minha esposa ficamos aliviados ao saber que ele não estava amaldiçoado
https://www.ifixit.com/News/33952/apple-put-a-hinge-sensor-i...
Histórias assim eram o que tornavam Car Talk tão divertido. Não era simplesmente sobre mecânicos consertando carros; as situações eram tão bizarras e peculiares que ficavam interessantes
Também era muito divertido ouvir mecânicos experientes tratando essas situações estranhas como algo comum, de tanto que já tinham visto; além disso, eles eram ótimos contadores de histórias
Para mim, a lição não é tanto “problemas que parecem absurdos às vezes são reais”, mas sim o problema do usuário geralmente existe de verdade, mas não confie na capacidade dele de diagnosticar a causa
A carta não afirmava que o sorvete era a causa raiz; deixava muito claro que era a causa imediata. O presidente da Pontiac e a pessoa que escreveu aquela “lição” podem ter confundido as duas coisas, mas o engenheiro que investigou não confundiu
Pela minha experiência fazendo também help desk durante o trabalho de desenvolvimento, usuários facilmente apontam fatos arbitrários como causa do problema. Heurísticas como “correlação é causalidade” ou post hoc ergo propter hoc podem ajudar, mas são ruins quando substituem a inferência. Como os usuários não conhecem o funcionamento das coisas que usam, é difícil diagnosticarem corretamente; e usuários que acham que “entendem um pouco disso” tendem, na verdade, a ser os mais difíceis de lidar
O carro da minha esposa está com pouco fluido do limpador agora, mas o alerta só aparece em um ponto específico durante a condução. Não é uma certa distância de casa; é uma localização exata
No início, pensei que pudesse ser por causa do tempo de ir a algum lugar e voltar, mas, até aquele ponto, não importa se ela dirigiu por 5 minutos, 5 milhas, 1 hora ou 60 milhas: o alerta visual e sonoro sempre aparece naquele local. A única pista adicional é que aquele ponto é uma área sem sinal para a maioria dos celulares e operadoras. Ao completar o fluido do limpador, o mistério entrou em hibernação, mas fico curioso se todos os alertas aparecem ali. Parece até que a telemetria do carro é cutucada naquele ponto, acorda e diz alguma coisa
Isso poderia causar uma interferência estranha o suficiente para empurrar o sensor de “fluido suficiente” para “baixo”
É simplesmente o líquido se movendo dentro do reservatório. Hoje limpei um pouco o para-brisa para fazer o carro manter acesa a luz de nível baixo
Numa noite em que eu fazia um trabalho de Java no laboratório de ciência da computação, o professor responsável passou por ali e disse: “Ah, nessa máquina aí você vai precisar de sorte”
Aquela máquina, em certo momento, morria espetacularmente ao tentar executar qualquer programa Java, mas rodava C++ e Python sem problemas. Até o programa do professor, que eu inicialmente não acreditei, fez a máquina travar. Depois de cerca de duas semanas de investigação por um técnico e pelo professor, descobriram que, toda vez que a JVM iniciava, ela alocava o inteiro 12 no mesmo endereço de RAM, e o chip de RAM que continha aquele endereço físico estava com defeito. Sempre que tentava alocar naquele endereço, ocorria um crash; ao trocar o pente de RAM ruim, o problema foi resolvido imediatamente
https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
Não vou dar spoiler da conclusão. É uma jornada de depuração longa e cheia de reviravoltas, vale a leitura. Discussão no HN:
https://news.ycombinator.com/item?id=15845118
Esta história é um exemplo divertido de variável de confusão
Em inferência causal, uma variável de confusão é uma variável que afeta tanto a variável dependente quanto a independente, criando uma associação espúria. É um conceito causal que não pode ser explicado apenas por correlação, e é uma das razões quantitativas importantes por trás de “correlação não implica causalidade”
https://en.wikipedia.org/wiki/Confounding
Escrevendo como um modelo estatístico, dá para vê-lo como
S = f(H, I, T).Sé se o carro dá partida ou não,Hé a temperatura do motor,Ié o tipo de sorvete escolhido, eTé o tempo gasto para comprar o sorvete. QuandoTé curto, o motor fica mais quente e mais suscetível ao vapor lock, afetandoS; e a localização do sorvete de baunilha permite comprá-lo mais rapidamente, ligando isso também aI. Assim surge uma relação falsa entreIeSIafetarT, e não deTafetarI? Afinal, o tipo de sorvete determina o tempo gasto dentro da loja