Meu erro de US$ 500 milhões com o rover de Marte

• Em fevereiro de 2003, na sala limpa do JPL, o rover marciano Spirit estava a 2 semanas de ser enviado ao local de lançamento, e um único erro de conexão na break-out-box poderia ter arruinado uma nave espacial de US$ 500 milhões
• Spirit e Opportunity eram uma missão de rovers gêmeos de Marte na qual a NASA investiu quase US$ 1 bilhão, e o cronograma praticamente não deixava margem para recuperar uma grande falha
• Logo após um pulso elétrico entrar na nave em vez de ir para o motor, a telemetria caiu, mas nem o dano nem a causa puderam ser confirmados de imediato
• No dia seguinte, foi confirmado que a perda de telemetria ocorreu por causa da remoção das pontas de prova de um multímetro Fluke 87III, e o surto real permaneceu como objeto de análise no canal do driver de motor H-Bridge
• Depois de algumas semanas de análise, o projeto classificou o hardware como Use As Is, corrigiu o procedimento e continuou o mesmo teste; o motor em questão no Spirit funcionou normalmente em Marte

---

O incidente de teste no Spirit pouco antes do lançamento

• Em fevereiro de 2003, na sala limpa Building 179 High Bay 1 da NASA JPL, o rover marciano Spirit estava a 2 semanas de ser transportado para Cape Canaveral
• Spirit e Opportunity eram uma missão de rovers gêmeos de Marte, naves complexas nas quais a NASA havia investido quase US$ 1 bilhão na época
• Na fase de montagem e testes, era necessário testar rigorosamente todos os sistemas e confirmar o funcionamento normal antes de fechar a nave pela última vez na Terra
• Os dois rovers tinham ao todo 62 motores do tipo brushed
  • tração e esterçamento das rodas
  • controle do braço robótico
  • apontamento das câmeras
  • direcionamento da antena voltada para a Terra
  • ações de abertura e desdobramento após o pouso
• Naquela noite, o alvo do teste era o motor RAT-Revolve dentro da Rock Abrasion Tool (RAT) na ponta do braço robótico do Spirit
  • o motor RAT-Revolve gira a grinder e a brush sobre rochas marcianas

O procedimento para verificar o estado do motor por sinais elétricos

• Não era prático desmontar o motor após cada teste ambiental para inspecionar seu interior
• Em vez disso, o motor era desconectado da nave e ligado a uma fonte de alimentação externa e a um strip chart recorder para verificar o desempenho elétrico
• Um motor normal mostra uma queda suave de corrente em forma exponencial durante o spin-up, e quando há anomalias aparece um blip no sinal
• O teste usava uma break-out-box, e uma ligação errada podia enviar uma corrente alta para o lugar errado e causar danos fatais
• Na checagem prévia, a interface de conexão, a configuração da fonte, a configuração do strip chart e um pulso curto de teste em um motor de referência haviam sido confirmados como normais

O pulso elétrico que entrou na direção errada

• No momento em que a energia foi enviada ao motor RAT-Revolve, surgiu no strip chart um sinal desconhecido, que também não era o sinal típico de um motor com defeito
• Ao seguir a fiação, ficou claro que, por causa de um erro na break-out-box, o pulso elétrico havia ido não para o motor, mas no sentido oposto pela interface do conector, em direção à nave
• O Spirit estava a 2 semanas do transporte para os preparativos de lançamento, então não haveria tempo para recuperação se surgisse um grande problema
• O incidente foi comunicado imediatamente ao condutor de teste, Leo, e ao mesmo tempo veio a resposta de que a telemetria da nave havia caído
• A equipe executou de imediato o procedimento de desligamento de emergência e recebeu ordem para sair da sala limpa enquanto o ocorrido e os danos eram avaliados

A perda de telemetria e a avaliação inicial

• Logo após o incidente, havia dois fatos confirmados
  • um grande pulso elétrico entrou em um lugar diferente do pretendido
  • a telemetria da nave foi interrompida
• A ligação entre os dois eventos não era clara de imediato
• A equipe considerou mais provável que o surto elétrico tivesse entrado no circuito driver de motor H-Bridge
  • o H-Bridge é tratado como um circuito que controla o fluxo de eletricidade
  • era uma das partes projetadas para suportar energia adicional por causa de back-EMF no rover
• A nave já estava desligada, e a equipe decidiu verificar se o problema desapareceria ao reaplicar energia
• Perto da meia-noite, o relato do incidente já havia chegado ao gerente do projeto, Pete, e a possibilidade de replanejar um projeto de cerca de 1.000 pessoas estava em jogo

A falha no reboot e a causa real descoberta no dia seguinte

• O procedimento padrão de energização da nave foi executado novamente, mas, mesmo depois de a eletrônica e o software subirem, a telemetria não voltou
• No rack de equipamentos de apoio em solo, havia uma luz vermelha que acendia ao receber um pulso a cada ciclo de clock, usada como uma espécie de batimento cardíaco do robô 8 vezes por segundo
• A fonte de alimentação mostrava os degraus de tensão e as mudanças de corrente habituais, mas a luz não acendia e a telemetria não aparecia
• No dia seguinte, ao revisar novamente a sequência do evento, um multímetro digital Fluke 87III virou a pista-chave
• Enquanto procuravam um multímetro necessário para o teste do dia anterior, removeram as pontas de prova de um multímetro que parecia estar monitorando a tensão do barramento perto da nave
  • na verdade, esse multímetro estava completando o circuito de alimentação da telemetria de teste em solo da nave
  • no instante em que as pontas foram removidas, a conexão de energia da telemetria foi interrompida

O Spirit estava vivo, e o hardware foi mantido em uso

• A equipe recolocou o multímetro em sua função original e ligou novamente a nave
• A telemetria voltou, e ficou confirmado que o Spirit não havia morrido
• A perda real foi de apenas algumas horas, e o teste foi retomado
• Nas semanas seguintes, o canal H-Bridge do motor RAT-Revolve foi analisado, e houve discussão detalhada sobre a possibilidade de thin-film demetallization
• Ao fim, o projeto classificou aquele hardware como Use As Is
• Os preparativos de lançamento continuaram, e depois que o Spirit chegou a Marte, o motor RAT-Revolve funcionou normalmente

Como lidar com experiências de fracasso

• Esse incidente levou à convicção de que compartilhar experiências de fracasso pode gerar aprendizado tanto para quem conta quanto para quem escuta
• Na Planetary Resources, durante o processo de contratação e na cultura da equipe, pedia-se aos candidatos que compartilhassem sua failure story
• Em meio à crise, Ernie deixou a frase: “Da próxima vez que você tiver de aprovar que algo está ok, lembre-se desta sensação”
• Depois do incidente, alguns defenderam que testes perigosos deveriam ser interrompidos, mas o teste continuou por causa da importância de verificar se o motor funcionaria normalmente em Marte
• O gerente do projeto, Pete, deixou a mesma pessoa continuar liderando o teste e decidiu no espírito de: “Nós pagamos pelo treinamento dele, e ele é a pessoa com menor chance de repetir esse erro”
• Depois, o procedimento foi corrigido para que o mesmo erro não se repetisse, e o mesmo teste foi realizado novamente várias vezes
• Essa experiência se tornou um ponto de referência para recordar o medo e o arrependimento daquele momento ao fazer uma aprovação ou garantia importante

[GN⁺]

Opiniões no Hacker News

• O texto é realmente muito bem escrito.
  Como engenheiro de software, ainda me lembro de algo parecido que aconteceu no começo da minha carreira. Cerca de 10 anos atrás, eu estava prestando consultoria para um cliente; passamos meses criando uma nova versão do serviço web dele e, no dia do lançamento, fiquei responsável pelo deploy. Na época, os processos de desenvolvimento e deploy eram quase todos manuais. Automatizei o que dava com scripts e SQL e, no instante em que apertei Enter para fazer o último teste antes do deploy, percebi que tinha acabado de trocar para as credenciais de produção.
  Quando os erros começaram a se acumular e o serviço parou de responder, tive certeza de que tinha destruído o banco de dados, mas, graças ao fato de alguém ter concluído um backup algumas horas antes em preparação para o lançamento, a maior parte foi restaurada. Depois disso, ao lidar com bancos de dados e sistemas de produção, a palavra cuidado passou a ser pouco para descrever minha postura, e prometi nunca mais fazer aquilo.

  • Nós também temos uma arquitetura de event sourcing, então é raro acessar diretamente o banco de dados de produção. Quando necessário, usamos um shell script para abrir um túnel por um bastion host e expor as variáveis de ambiente padrão para configurar o cliente Postgres.
    A suíte de testes, durante a execução, apaga e recria tabelas ou as esvazia. Um dia, depois de investigar uma correção de bug no banco de produção, o desenvolvedor líder executou make test. O código de teste seguiu as variáveis de ambiente como estavam e se conectou à produção, não ao Docker, e imediatamente passou a apagar e recriar aquelas tabelas de produção dezenas de vezes.
  • Cerca de 10 anos atrás, em uma consultoria onde eu trabalhava, um funcionário interno responsável por outro produto estava logado ao mesmo tempo no banco de desenvolvimento e no banco de produção em janelas diferentes e acabou apagando por engano o banco de dados de produção. Ao tentar restaurar, descobriram que os backups vinham falhando havia meses, e então ficou claro por que tinham contratado consultores para ajudar no novo produto.
    Felizmente, cada site de cliente tinha um banco local sincronizado com o banco central, então o produto continuava funcionando mesmo com a conexão interrompida. Ele passou 3 ou 4 dias em jornadas longas, combinando backups antigos com dados dos clientes para reconstruir o banco mestre.
  • Uma vez rodei uma migração no banco de dados de produção dentro do Visual Studio. Em retrospecto, era algo recuperável, mas, no momento em que todas as tabelas começaram a desaparecer na visualização em árvore do VS, achei que meu coração fosse parar.
    Um segundo depois elas apareceram de novo; era só a view sendo atualizada. Uma UI realmente horrível.
  • Cerca de 15 anos atrás, eu estava me preparando para sair do trabalho antes de um fim de semana prolongado quando uma amiga do marketing pediu uma alteração rápida no site de um cliente. Era uma empresa pequena, de umas 15 pessoas, com clientes em quantidade difícil de dar conta, então eu tinha acesso ao banco de dados de produção, algo que não deveria ter.
    Para mudar o texto de marketing de um produto, escrevi uma consulta UPDATE curta, mas, no instante em que ela não terminou imediatamente, soube que tinha dado ruim: atualizei tudo sem condição e alterei milhares de descrições de produtos. O DBA que tinha acesso aos backups estava em outro fuso horário e já tinha saído; depois de mais de uma hora no telefone, conseguimos restaurar.
    A alteração rápida na hora de ir embora virou algumas horas de contenção, e minha amiga do marketing ficou se desculpando sem parar, mas o erro foi meu. Acho que não ouvimos reclamações dos clientes porque era uma sexta-feira, 17h, de fim de semana de feriado.
  • Em um lugar onde trabalhei cerca de 20 anos atrás, havia uma política segundo a qual, ao executar um comando sudo, outra pessoa precisava conferir o comando antes de você apertar Enter. Uma política ou prática parecida poderia ser aplicada a tudo que é feito em produção.

• Lembro da frase: se um estagiário apagou o banco de dados de produção, ele não é um mau estagiário; é um processo ruim.
  É difícil julgar se isso é um problema de processo ou de pessoa, porque se espera mais de funcionários efetivos, mas, ao me colocar no lugar dele, fiquei emocionado ao ler o horror e a dor do momento em que percebeu o que tinha acontecido. Incluindo a sensação de a luz de esperança fracassar e depois voltar à vida. Nunca assumi um projeto do qual tanta gente dependesse.
  Para mim, todos eles são heróis.

  • Em uma grande corretora, um script de teste acabou tocando produção por engano e criou milhões de dólares em operações de câmbio de teste falsas.
    Na call de post-mortem, a primeira fala foi: “Não vamos culpar a pessoa que criou essas operações. Foi um erro honesto. Em vez disso, vamos discutir por que um desenvolvedor conseguia chamar a API de operações de produção sem autenticação”.
  • Não se deve culpar indivíduos por esse tipo de falha organizacional. Vejo dois problemas de processo: se era possível conectar o plugue invertido, isso deveria ter sido tornado impossível desde o início, ou o risco deveria ter sido identificado e duas ou mais pessoas deveriam ter conferido a orientação; e ferramentas como o multímetro em uso nunca deveriam ser desconectadas.
    Se você culpa uma pessoa, essa pessoa é demitida e a organização como um todo fica mais fraca. É como mandar embora a única pessoa que aprendeu uma lição cara. Só se deve responsabilizar individualmente alguém quando houve intenção de causar dano; nesse caso, a lei pode intervir.
  • No meu primeiro emprego de desenvolvimento web depois da escola, derrubei o site de produção logo no primeiro dia. Dezenas de milhares de visitantes foram afetados e todos os leads de vendas pararam, mas o site voltou em poucos minutos, e passei por um momento difícil com a equipe inteira e o CEO da sala ao lado observando.
    Alguns anos depois, quando saí, eu tinha transformado aquele site frágil e instável em um sistema com testes automatizados, várias camadas de backup, failover em múltiplos datacenters, treinamento e onboarding de novos desenvolvedores. Era o começo da AWS, não uma época em que sites de produção eram implantados com um clique.
    Por causa dessa experiência, aprendi controle de versão adequado, ambientes de desenvolvimento, Redis, sharding e clustering, VMs, replicação de Postgres e MySQL, wikis, monit, DNS, load balancers, proxies reversos e assim por diante. Porque eu não queria nunca mais derrubar o site.
    Era uma empresa pequena que colocou o site de produção nas mãos de um desistente do ensino médio com alguma experiência em WordPress, pagando 15 dólares por hora, mas, mesmo depois do erro, não me demitiu; deu-me liberdade e confiança para aprender na prática e melhorar o sistema, e continuo grato por isso.
  • Este caso é diferente. Era um rover único e customizado, o primeiro a levar aquele nome, e já havia todo tipo de processo, mas não dá para prever tudo. Provavelmente corrigiram o processo depois, mas é preciso lembrar que também era a primeira experiência deles.
    Mais regras e processos melhores nem sempre são algo bom. Às vezes, a burocracia torna a NASA, que já é lenta, ainda mais lenta. Em missões inéditas, às vezes é preciso depender das pessoas, não do processo, e assumir riscos.
  • Não consigo deixar de pensar no que teria acontecido se o rover tivesse sido realmente destruído. O que impediu isso parece pura sorte, e imagino que ele poderia ter conectado a outro terminal errado que não tivesse circuito de proteção.
    Ou seja, houve uma parte decidida fora da capacidade do autor, e havia a mesma possibilidade de ele ser lembrado para sempre como a pessoa que arruinou o rover, exatamente como temia.

• Isso também tem muito a ver com a minha experiência. Em uma grande companhia aérea, eu costumava escolher os projetos mais difíceis e arriscados para assumir, e um deles era implementar rapidamente um novo provedor de pagamentos no site. O site vendia milhões de euros em passagens todos os dias.
  Poucos segundos depois do deploy, ficou claro que eu tinha deixado passar uma diferença entre o ambiente de teste e o de produção, e que uma variável essencial estava vazia em produção. Era algo que eu poderia ter previsto se tivesse lido mais a documentação e me preparado melhor, então as vendas pararam completamente e meu coração gelou. Depois de um longo procedimento de rollback, as vendas ficaram interrompidas por várias horas, clientes furiosos se acumularam e houve milhões de euros em prejuízo.
  Encontrei o CEO no elevador e disse que a culpa era inteiramente minha e que aceitaria todas as consequências, inclusive demissão. Ele sorriu e respondeu algo como: “Por que eu mandaria você embora? Acabamos de gastar milhões para treinar você. Agora você faz o trabalho melhor do que ontem.” Essa experiência foi formativa em muitos aspectos, inclusive sobre liderança de verdade, e depois disso concluí muitos projetos de alto risco com sucesso.

  • As frases são genéricas demais, e detalhes como a pessoa ter ido falar diretamente com o CEO, ou a combinação de “profissional de alto desempenho” com “a empresa perdeu milhões”, soam um pouco pouco plausíveis; parece algo escrito por um LLM ou pelo menos inventado.
  • Frequentemente tenho a sensação de que páginas de reserva de passagens aéreas ficam quebradas em algum lugar mais da metade do tempo. Mesmo que não cheguem a ficar totalmente em branco, muitas vezes quebram a ponto de ser impossível reservar uma passagem, e eu até preferiria uma tela em branco. Pelo menos não perderia 30 minutos.
    A internet como um todo também vive quebrada. Durante uma compra na Black Friday, a loja online da Nike dá erro, e a solução do help desk é algo como “use o app”.
  • O prejuízo pode não ter sido tão grande quanto parece. Como ninguém pôde comprar passagens durante algumas horas, em teoria a empresa perdeu milhões em receita naquele período, mas isso pressupõe que as pessoas não tentariam de novo mais tarde.
    Na prática, acho que o tempo de indisponibilidade não se converte diretamente em prejuízo. No começo, o Twitter caía com frequência por causa da popularidade e da arquitetura, mas as pessoas não deixaram de usar o Twitter por isso.
    Em serviços online, uma interrupção não é uma catástrofe nem o fim da empresa. É diferente no caso de equipamentos espaciais ou de software de negociação de alta frequência que pode levar uma empresa à falência; justamente por isso, deveriam existir mecanismos de verificação mais rígidos. Em teoria é assim; na prática, às vezes esses setores são piores do que um serviço web CRUD malfeito criado com base em boas práticas aprendidas com o setor espacial e de negociação de alta frequência.
  • Se eu fosse o responsável pela companhia aérea, teria desejado uma reação mais próxima do espírito de uma análise pós-acidente aéreo. O caminho deveria ser encontrar e corrigir as causas sistêmicas.
    Em deploys de produção, pode ser necessário ter alguém como um copiloto, conferindo junto e com autoridade para interromper o rollout, além das proteções comuns de DevOps.
  • Isso me lembra uma piada antiga que termina com “Por que eu demitiria você? Acabei de gastar milhões treinando você!”.
    Pessoas que assumem projetos de alto risco costumam ser subestimadas. Muitos gestores preferem funcionários que de forma estável não geram valor algum a funcionários com valor esperado positivo, mas com variância.

• Trabalho no setor de TV. No meu primeiro emprego, há 30 anos, em uma pequena emissora regional, fui treinado como operador de fitas do telejornal. As fitas de transmissão ficavam empilhadas em grandes montes, e havia quatro VTRs de reprodução. Meu trabalho era inserir cada fita e deixá-la posicionada no ponto de pré-roll de 1 segundo.
  Quando a reprodução de uma fita terminava e chegava a hora de ejetá-la, era muito fácil apertar o botão de ejeção do VTR que estava no ar naquele momento, em vez do VTR que tinha acabado de terminar. A pessoa que me treinava fazia um grande som de alerta, rangendo os dentes e puxando o ar, toda vez que eu estendia a mão para o botão de ejeção; aquele som me fazia parar, conferir duas ou três vezes e só então tirar a fita.
  Era realmente irritante, mas foi eficaz para me condicionar a tomar cuidado. A política da emissora era: na primeira vez que alguém ejetasse uma fita durante uma transmissão ao vivo, receberia um dia de folga sem remuneração; na segunda, ficaria em período probatório; na terceira, seria demitido. Alguns colegas perderam o emprego e estragaram telejornais por descuido crônico. Graças àquele treinador irritante, aprendi o hábito de conferir e conferir de novo, e nunca ejetei uma fita que estava no ar.

  • Isso explica por que aquelas antigas coletâneas de erros de transmissão populares na TV no começo dos anos 80 eram daquele jeito. O repórter dizia alguma coisa, mas a imagem de fundo mostrava uma cena completamente errada.

• Concordo que quem comete esse tipo de erro não volta a cometer o mesmo erro. Por isso, em geral, demitir alguém que errou tecnicamente e está claramente sofrendo com isso é uma má escolha.
  Mas não acho que essa seja a lição “de verdade”. Considerando custo e risco, a lição é que componentes testados com grandes surtos de energia deveriam ter conectores de teste dedicados, incompatíveis com componentes que têm facilidade de soltar fumaça.
  Não é um projetinho pequeno em breadboard, mas um projeto gigantesco feito por inúmeras pessoas de uma agência governamental, onde procedimentos formais custam muito tempo e dinheiro e às vezes até viram motivo de deboche. A lógica de “vamos entregar a um jovem de 28 anos um robô de US$ 500 milhões que pode explodir se ele escorregar” soa muito estranha.

  • É verdade que deveria ser projetado de modo que não desse para conectar errado. Na prática, imagino que a maior parte tenha sido projetada assim, mas configurações incorretas não previstas na fase de projeto ainda podem acontecer.
    Especialmente durante testes, muitas vezes se lida com cabos, conectores e circuitos personalizados que diferem da “configuração normal”. Para mim, a lição é realizar tarefas importantes, sempre que possível, pelo princípio dos 4 olhos. O modelo em que uma pessoa executa o trabalho e outra verifica cada etapa antes de prosseguir é muito eficaz para pegar “erros absurdos” como o do artigo.
    Só que, por pressão de cronograma e afins, nem sempre dá para ter duas pessoas acompanhando um único teste; então, na prática, esse tipo de erro acontece. É preciso tornar o sistema inteiro robusto.
  • Eu também pensei assim no começo. Mas, se for um equipamento descartável que passa por um único ciclo de teste, esse julgamento fica difícil.
    Em computação também há muitas tarefas semelhantes, feitas uma única vez como parte de um upgrade ou migração em um banco de dados de produção ou na configuração de um roteador. Às vezes, o custo de criar proteções é maior do que simplesmente tomar cuidado desde o início. Nós nem sempre conseguimos ter cuidado perfeito, mas também nem sempre conseguimos criar proteções perfeitas, e às vezes cometemos erros parecidos por confiar em proteções defeituosas.
    Na situação da história, talvez devesse haver um parceiro no estilo pair programming de hardware, dedicado apenas a verificar se tudo o que a pessoa estava fazendo estava correto. Não um assistente que divide funções e ajuda, como a Mary, mas alguém cuja única missão fosse acompanhar e conferir.
  • Lendo com atenção, a energia entrou pelos terminais de saída de potência da ponte H, e a ponte H é um circuito eletrônico robusto, então no fim nada foi danificado. O desligamento não teve relação.
    Se tivesse entrado nas linhas de dados do controlador do motor, é bem provável que algo tivesse queimado. Não dá para descartar que os tipos de conectores fossem diferentes, mas os dois conectores ligados incorretamente de fato estavam atribuídos ao mesmo tipo.
  • Quando a humanidade pousou na Lua pela primeira vez, a idade média dos engenheiros do Mission Control era de 28 anos.
  • Trabalho nesse setor, então posso explicar como coisas assim acontecem. Mesmo em projetos caros, não dá para impor conectores exclusivos em todos os lugares. Os requisitos competem entre si.
    Em conectores, especialmente, há muitos requisitos conservadores: produtos já certificados, certos deratings, espaçamento entre pinos, backshell aterrado etc. No fim, há apenas algumas séries de conectores usadas e mantidas em estoque, e não é realista torná-las totalmente não sobrepostas, custe o que custar. Em geral, tenta-se padronizar os mesmos sinais ou torná-los únicos para que não se sobreponham.
    Por exemplo, conectores externos de uma espaçonave precisam ser do tipo soquete para evitar curto-circuitos durante o manuseio, enquanto um chicote intermediário nunca é removido e pode ter conectores do tipo pino presos de forma simétrica. Aí, quando surge a necessidade de uma caixa de breakout para testes, aparece a chance de conectar a caixa ao contrário.
    Ou um lado da caixa de breakout pode ter um conector de 100 pinos e o outro precisar se conectar a 25 equipamentos de teste. Não existem 25 conectores diferentes para escolher, e também não dá para impor requisitos personalizados a todos os equipamentos de teste.
    Espaçonaves estão migrando cada vez mais para microcontroladores locais e diagnósticos locais, então esse tipo de equipamento de teste para todos os sinais analógicos está diminuindo. Hoje, o motor provavelmente também seria brushless, e em vez de uma caixa de breakout dessas, o teste e a operação em voo dependeriam da telemetria do driver do motor.
    Conectores aeroespaciais também estão ficando mais configuráveis no momento do pedido, como em outros setores, e é possível adicionar chaves para que, mesmo havendo 10 conectores “iguais”, cada um só encaixe em seu lugar. Ainda assim, exigir que todo equipamento de teste seja configurado assim continua sendo irrealista.

• Só para deixar registrado, acrescento minha história também. Meu primeiro emprego depois da faculdade foi em uma startup de marketing de conteúdo que usava PHP e PerconaDB (MySQL). Eu não tinha muita experiência com PHP, mas tinha aquela confiança infundada de recém-formado. Também estava havia seis meses sem conseguir emprego depois de me formar, então queria muito causar uma boa impressão.
  Fui encarregado de atualizar uma feature flag para ativar um novo recurso para todos os clientes, exceto os que explicitamente quisessem desativá-lo. A flag estava armazenada no banco de dados como uma matriz de strings com os inteiros 4 e 5.
  Para fazer o que precisava, usei a função PHP array_reverse, mas, por não ler a documentação, não sabia que, sem o segundo argumento, ela inverte os valores, não as chaves. Como resultado, o banco de dados ficou corrompido exatamente no sentido oposto ao necessário e, de alguma forma, isso passou pelo QA.
  Descobri algumas horas depois e, como na época eu levava quase 3 horas só de ida no trajeto até o trabalho, a essa altura até a diretoria já estava envolvida. Dava para corrigir facilmente com um script reverso, mas isso expôs vários problemas, como QA e falha no backup do DB.
  No dia seguinte, o arquiteto líder veio falar comigo e disse que era um erro quase como um rito de passagem ao trabalhar com PHP, e que ele mesmo tinha feito algo parecido no início da carreira; ainda lembro disso e sou grato. Acabei sendo demitido e, embora tenha ajudado no meu crescimento como engenheiro, aquele momento e as semanas seguintes certamente me desanimaram.

  • Demitiram você por causa desse erro com array_reverse?

• A história foi escrita de um jeito envolvente, mas também ficou confusa
  Parece que essa equipe não cometeu um único erro, e sim vários. Também não fica claro se o resultado poderia ter causado dano real à espaçonave ou se apenas desperdiçou tempo e gerou confusão sobre o motivo de a espaçonave não ligar
  O primeiro erro foi não perceber que o multímetro não estava apenas medindo, mas fechando o circuito. Isso soa como um projeto realmente ruim e, se tinha mesmo de ser assim, aquele multímetro jamais deveria ter sido tocado. Não é erro de uma única pessoa: envolve pelo menos duas pessoas, quem as gerenciava e o responsável por permitir um sistema desses
  O segundo erro foi no lado da breakout box. Eles acharam que tinham enviado energia por engano para a espaçonave e, quando ela não ligou, concluíram que um surto de energia a havia danificado; mas não tinham certeza de para onde a corrente de fato tinha ido nem do que havia sido danificado, e no fim estavam errados
  O motivo de a espaçonave não ligar foi que, antes do acidente, o multímetro havia sido removido do circuito. Ainda é confuso se a frase sobre semanas de análise do canal da ponte H do motor RAT-Revolve e de discussões sobre possível desmetalização de filme fino quer dizer que eles julgaram que o surto de energia indevido poderia ter passado por esse canal e o danificado

  • Também faltou o ponto de que o responsável pela telemetria, Leo, não avisou sobre a perda de telemetria até dizer ao narrador que ele tinha cometido um erro. Não deveriam ter cancelado todos os testes até a telemetria voltar?
  • A espaçonave em si ligou normalmente. Como o multímetro estava conectando o circuito de telemetria, eles simplesmente não receberam informações até restaurarem esse circuito
    A energia de fato entrou por esse circuito, e eles estavam tentando determinar se ele tinha sido danificado. Só que o driver do motor precisa ser capaz de suportar energia retornando do motor, então provavelmente concluíram que ele não tinha sido danificado

• Como engenheiro mecânico e aeroespacial, eu gostaria que minhas histórias mais assustadoras fossem só sobre quase transformar o computador principal de um rover não tripulado de US$ 500 milhões em um tijolo
  Eu era o sênior que dava aprovações críticas de segurança para coisas que carregam vidas humanas. Depois de acidentes com queda, vendo fotos de peças quebradas, eu precisava lidar com aquela sensação de “e se aquilo foi um erro no meu cálculo?”, “e se minha junta escorregou?”, “e se foi por causa de um procedimento de teste inadequado para previsão de vida em fadiga acelerada ou trincas por corrosão sob tensão?”, “e se foi algo que não pegamos antes do envio porque nos apressamos para colocar em produção?”
  É interessante ler relatos de falhas em áreas parecidas, mas as histórias compartilhadas publicamente no HN me fazem pensar que PTSD causado pelo trabalho não é uma competição. Para algumas pessoas, só custa mais em terapia

  • Isso me lembrou um trecho de um romance de uma autora de que gosto. É algo que um instrutor de soldagem diz depois de contar uma anedota de análise pós-fato bastante literal relacionada a inspeções de segurança falsificadas

    He gathered his breath. “This is the most important thing I will ever say to you. The human mind is the ultimate testing device. You can take all the notes you want on the technical data, anything you forget you can look up again, but this must be engraved on your hearts in letters of fire.

    “There is nothing, nothing, nothing more important to me in the men and women I train than their absolute personal integrity. Whether you function as welders or inspectors, the laws of physics are implacable lie-detectors. You may fool men. You will never fool the metal. That’s all.”

    He let his breath out, and regained his good humor, looking around. The quaddie students were taking it with proper seriousness, good, no class cut-ups making sick jokes in the back row. In fact, they were looking rather shocked, staring at him with terrified awe.
    -- Lois McMaster Bujold, Falling Free

  • Eu pensei o mesmo sobre o último parágrafo. O trecho em que o texto original diz “volto imediatamente àquele momento — a sala, a iluminação, a cadeira em que eu estava sentado, a mesa, a sensação de o estômago afundar…” soou como uma resposta traumática
    Que bom que ele conseguiu usar essa energia para melhorar, mas nem todo mundo reage a trauma da mesma forma, e comparar essas reações também não é simples. Por exemplo, sinto que há variáveis sociais demais para usar isso como pergunta de entrevista
  • Fico pensando se a parte de “ter de sentir, ao ver fotos de peças quebradas depois de um acidente, ‘e se aquilo foi um erro no meu cálculo?’” é algo que inevitavelmente acaba recaindo sobre alguém
    Mesmo que tenha sido um detalhe que o procedimento não conseguiu detectar, ainda existe alguém responsável por criar bons procedimentos. Pode haver vários fatores, mas no fim parece que alguém acaba ficando responsável de uma forma bastante direta
    É interessante pensar nisso em contextos em que erros individuais são atribuídos ao coletivo, como engenharia de software ou a sociedade em geral
  • Torço sinceramente para que haja mais gente como você na indústria aeroespacial, e menos pessoas como as que conceberam, implementaram e aprovaram o MCAS do Boeing 737 MAX
  • É surpreendente que não exista aconselhamento em grupo para engenheiros — ou, se existe, é difícil de encontrar. Eu não trabalho em uma área de alto risco, mas muitas vezes acabei ouvindo relatos de pessoas da aviação ou das ferrovias
    Acho que pode ser bem pesado se você tem empatia e não adota a atitude de “depois que o foguete sobe, onde ele cai não é problema do meu departamento”. Seria bom haver grupos de apoio entre pares para pessoas que constroem sistemas essenciais à segurança ou lidam com as consequências deles. As empresas nem sempre oferecem um bom aconselhamento
    Associações de engenharia ou entidades de engenheiros credenciados talvez pudessem oferecer esse serviço com as anuidades, mas também é possível que as pessoas hesitem em usá-lo por medo de perder a licença ou a certificação profissional. Antigamente talvez se desabafasse ficando bêbado no bar com colegas, mas dependência de álcool ou prejuízo ao trabalho no dia seguinte não são bons, e a cultura de bar também já não é a mesma

• Isso me lembra o caso do satélite NOAA-N Prime, que tombou porque não havia parafusos suficientes prendendo-o à bancada de testes.
  A causa raiz — corrijam-me se eu não estiver sendo preciso — foi que os parafusos de inspeção por raios X usados para prender o satélite eram tão caros que foram “emprestados” para outro projeto e não foram colocados de volta. Quando o satélite foi virado para a posição horizontal, caiu no chão, e o custo do reparo foi de US$ 135 milhões.
  https://en.m.wikipedia.org/wiki/NOAA-19

  • Se uma errata ou um adendo ao procedimento de virada acrescentasse “verificar os parafusos”, seria permitido um pouco de sarcasmo?

• É interessante notar que uma ordenação cronológica melhor desde o início poderia ter evitado a preocupação. Se tivessem comparado o timestamp da leitura do teste com o último timestamp do sistema de telemetria, teriam percebido que a telemetria já havia falhado antes da execução do teste.
  O uso de uma formulação imprecisa como “parece que toda a telemetria da espaçonave caiu há pouco” em vez de timestamps exatos também fez parte da causa. A lição é que é preciso verificar corretamente como os eventos durante um incidente estão de fato conectados. É fácil ver dois sinais diferentes e presumir causalidade em uma direção específica, mas, na realidade, pode ser o contrário.