Por que ordenar assim

Histórias de falha costumam ser arquivadas por setor - medicina, aeroespacial, finanças, redes - que é o arranjo menos útil, porque sugere que as lições ficam no setor delas. Não ficam. Uma máquina de radioterapia de 1985 e uma corretora de 2012 falharam por razões que se transferem diretamente a um parque de rede, e quem quer usar estes casos precisa deles ordenados por onde a falha de fato morava.

É o que esta página faz. Cada entrada nomeia o lugar, e então o caso que o demonstra.

A falha estava numa salvaguarda que alguém removeu

A máquina anterior rodava software comparavelmente defeituoso e não feriu ninguém, porque tinha travas mecânicas que não permitiam um estado inseguro, acreditasse o computador no que acreditasse. Essas travas foram removidas da sucessora, no raciocínio de que o software daria conta. O Therac-25 é o caso, e a pergunta que ele deixa é a que se leva a qualquer revisão de projeto: o que, neste sistema, é capaz de contradizer o software?

A falha estava numa premissa que venceu

O código estava correto. Voara com sucesso por anos no veículo anterior, onde o valor calculado sempre ficava na faixa. No veículo novo não ficou, e uma conversão que ninguém protegera estourou. O Ariane 5 é o caso. A pergunta transferível para qualquer coisa herdada - um modelo, um conjunto de regras, um script - não é isto funciona, e sim o que era verdade quando isto foi escrito, e continua sendo?

A falha estava numa fronteira entre duas organizações

Um programa produzia valores de impulso numa unidade; o que os consumia esperava outra. Os dois estavam internamente corretos, uma especificação de interface nomeava a convenção certa, e nada comparava a especificação com o tráfego. O Mars Climate Orbiter é o caso, e sua lição é que um documento enunciando a convenção correta não a faz cumprir. Toda passagem de bastão carrega significado que não está nos dados - bits ou bytes, local ou , prefixo ou máscara, carga ou quadro.

A falha estava na restauração, não na mudança

Sete de oito servidores receberam o código novo. Quando os engenheiros diagnosticaram corretamente o oitavo, reverteram tudo para a versão anterior para recuperar consistência - e a versão anterior era onde o defeito morava. O Knight Capital é o caso, e ele produz uma regra que vale escrever num runbook: um rollback é uma implantação. Para o que estou voltando, e isso contém a coisa que me machuca?

A falha estava no que foi dito, e quando

Um defeito aritmético menor virou o recall mais famoso da computação porque o fabricante o achou, decidiu que não qualificava como errata, o consertou em silêncio, e então pediu aos clientes afetados que provassem estar afetados. O defeito FDIV do Pentium é o caso. Seu companheiro é RSA e DigiNotar, em que uma empresa deixou os clientes sem saber o que fazer e a outra revogou certificados em silêncio por um mês enquanto os fraudulentos eram usados.

A falha foi ninguém agir sobre o alerta

O produto de detecção funcionou e disparou alarmes durante a intrusão. A Target é o caso em que a tecnologia fez o seu trabalho e a organização não - e o Knight Capital é a mesma falha em miniatura, com noventa e sete avisos automáticos nomeando o componente noventa minutos antes da abertura do mercado. Uma ferramenta de detecção sem resposta para e aí o que acontece é um sistema de registro com orçamento de marketing.

A falha foi a correção existir e não ser aplicada

Nove anos de surtos, cada um com correção publicada antes - um mês, seis meses, quatro semanas, e num caso um aviso escrito explícito do fabricante de que a falha era propagável. A era dos worms é o caso, e o EternalBlue, WannaCry e NotPetya é sua sequência, com a mesma aritmética e números maiores.

A falha foi não haver nada a consertar

Nenhuma vulnerabilidade, nenhuma correção, nada quebrado. Aparelhos funcionando exatamente como projetados, alcançáveis pela internet com as credenciais impressas nos manuais. O Mirai é o caso, e é a externalidade mais clara do catálogo: quem podia consertar não era quem pagava, e é por isso que o remédio acabou sendo uma lei, e não uma correção.

A falha estava numa funcionalidade funcionando corretamente

Um componente recebeu uma cadeia de caracteres e a interpretou exatamente como documentado, e a interpretação era execução de código. Shellshock e Log4Shell é o caso, e é a classe a que o teste automatizado é estruturalmente cego, porque nada trava: o software se comporta corretamente, e o comportamento correto é o exploit.

O que o conjunto diz junto

Lidas isoladamente, são histórias. Lidas como conjunto, fazem um argumento, e é o que o artigo de que não existe código perfeito enuncia diretamente: defeitos não são a variável interessante. Todas as organizações aqui os tinham. O que diferiu foi se algo podia contradizer o software, se uma premissa foi alguma vez reconferida, se uma fronteira foi verificada, se o caminho de volta foi raciocinado, se um alerta chegou a alguém, e o que foi dito.

Nada disso é questão de engenharia no sentido estrito. Tudo isso são decisões que podem ser tomadas antes do incidente, e nenhuma delas pode ser tomada durante.

Dois destes casos têm peça companheira sobre a outra metade do problema - não como a falha aconteceu, mas o que se passou entre achá-la e contar a alguém. É o assunto do registro da divulgação.

E as práticas que este conjunto inteiro defende, cada uma emparelhada com o caso que demonstra sua ausência, estão reunidas em decidido de antemão.