Margaret Hamilton projetou o software Apollo para falhar com segurança, não para nunca falhar

Três minutos antes do pouso da Apollo 11, o computador do módulo lunar começou a exibir alarmes de programa.

A pergunta importante de engenharia não era se o computador conseguiria evitar toda e qualquer sobrecarga.

Era se o software conseguiria reconhecer uma sobrecarga, abandonar trabalho de menor prioridade, preservar o essencial e se recuperar rápido o bastante para manter a missão viva.

Essa diferença está no centro do trabalho de Margaret Hamilton no MIT Instrumentation Laboratory.

O software se tornou crítico antes de a profissão amadurecer

Quando a NASA concedeu ao MIT seu primeiro contrato do programa Apollo em 1961, software ainda não era tratado como a disciplina madura de engenharia que se tornaria depois. O Apollo Guidance Computer tinha memória e poder de processamento minúsculos pelos padrões atuais, mas seu software precisava cuidar de navegação, orientação, displays, interação com astronautas e sequências críticas em tempo real.

Hamilton acabou liderando a Software Engineering Division do Instrumentation Laboratory. Sua equipe trabalhou no software de voo dos módulos de comando e lunar. A famosa foto de Hamilton ao lado de enormes pilhas de código impresso é marcante porque torna o software físico: ele não era um acessório invisível da Apollo; fazia parte do sistema operacional da nave.

O desafio não era apenas escrever instruções corretas. O software precisava continuar se comportando de forma sensata quando dados chegassem na hora errada, a carga aumentasse, operadores errassem ou o hardware se comportasse de forma inesperada.

Os alarmes da Apollo 11 testaram recuperação, não perfeição

Durante a descida lunar de 20 de julho de 1969, o computador de orientação gerou os alarmes 1201 e 1202. Relatos históricos da NASA e de engenheiros do sistema descrevem uma sobrecarga do executivo causada por tarefas desnecessárias do radar de rendezvous programadas durante a descida.

O computador não simplesmente travou. O software executivo podia reiniciar e retomar programas selecionados de alta prioridade, descartando trabalho que não era essencial para o pouso. Esse comportamento havia sido projetado e testado antes da missão.

A versão popular da história às vezes vira “Hamilton escreveu o código que salvou a Apollo 11”. A realização técnica foi mais ampla e coletiva. Hamilton liderou uma grande organização de software, enquanto muitos engenheiros projetaram, implementaram, testaram e deram suporte ao sistema. A missão pôde continuar porque a arquitetura e a equipe operacional estavam preparadas para condições anormais.

Sua contribuição é melhor entendida não como um único patch heroico, mas como liderança em um sistema no qual confiabilidade significava também recuperação controlada.

Sistemas confiáveis assumem que algo acabará dando errado

Um sistema frágil funciona perfeitamente enquanto todas as suposições permanecem verdadeiras. Um sistema resiliente parte da expectativa oposta: alguma suposição acabará falhando.

Hamilton posteriormente destacou conceitos como software assíncrono, escalonamento por prioridade, displays prioritários, testes de ponta a ponta e decisão humana no circuito. A NASA reconheceu essas ideias como importantes bases do design moderno de software ultraconfiável.

Essa filosofia aparece claramente no episódio dos alarmes. O computador conseguia distinguir trabalho urgente de trabalho secundário, reiniciar e preservar as tarefas essenciais. O controle da missão conseguia interpretar os alarmes porque o comportamento havia sido testado e compreendido.

Nenhum desses recursos tornava a falha impossível. Eles tornavam a falha sobrevivível.

A lição mais profunda é sobre arquitetura

Equipes frequentemente tratam confiabilidade como um problema de contagem de bugs: remova erros suficientes e o sistema ficará seguro. A Apollo mostra uma verdade mais difícil. Algumas falhas surgem de combinações inesperadas de componentes corretos, timing incomum, recursos saturados ou procedimentos que interagem mal com o software.

Por isso, confiabilidade precisa ser projetada na arquitetura e nas operações, e não adicionada no final por meio de mais testes.

Um bom sistema pergunta antes: qual trabalho é realmente essencial? O que pode ser descartado? Qual estado precisa sobreviver a uma reinicialização? O que o operador deve ver? O que acontece quando a capacidade é excedida? Como a equipe saberá que a recuperação é segura?

Hoje fazemos as mesmas perguntas em sistemas distribuídos, cloud, aviação, dispositivos médicos, cibersegurança e praticamente todo serviço que precisa continuar disponível sob pressão.

Por que a história de Hamilton continua relevante

Em 2016, Hamilton recebeu a Presidential Medal of Freedom por suas contribuições à engenharia de software e às missões Apollo. A essa altura, software já havia se tornado infraestrutura para praticamente todos os setores modernos.

Sua história é útil justamente porque a Apollo teve alarmes. Um sistema que nunca encontra estresse diz pouco sobre sua resiliência.

O teste melhor começa depois que o alarme aparece.

O sistema consegue identificar o que importa, descartar o que não importa, recuperar um estado conhecido, comunicar-se claramente com pessoas e continuar com segurança?

Software perfeito é uma aspiração.

Software recuperável é uma estratégia de engenharia.

Fontes

• NASA — Margaret Hamilton
• NASA Apollo 11 Lunar Surface Journal — Program Alarms
• MIT News — Margaret Hamilton’s Apollo code
• MIT News — Apollo mission at MIT
• MIT News — Presidential Medal of Freedom
• Imagem de capa — Draper Laboratory; restauração de Adam Cuerden / Wikimedia Commons. Domínio público nos Estados Unidos; uso livre confirmado pelo VRT no Commons.