Engenharia para decisões que não podem falhar

Quase todo software é desenhado sob uma suposição tácita: se der errado, tenta de novo. A suposição é razoável para a maior parte do que se constrói e é o que permite iterar rápido sem pensar muito no assunto.

Existe uma classe de decisões em que ela é falsa. Sistemas que despacham recursos físicos, que concedem ou negam crédito, que revogam acesso, que interrompem uma linha de produção, que classificam um caso como prioritário, que autorizam um pagamento. Nesses, errar não custa uma repetição: custa dinheiro que saiu, tempo que não volta, uma pessoa afetada por uma decisão que ninguém revisou. O desenho muda em quatro pontos, e nenhum deles é sobre acertar mais.

Reversibilidade raramente pode ser acrescentada a uma ação. Ela vem da forma como a ação foi expressa. Um sistema que escreve o efeito diretamente não tem para onde voltar; um sistema que emite uma intenção e a aplica num segundo passo tem, no mínimo, um lugar onde parar. A diferença é pequena no código e enorme no dia ruim.

Onde o efeito é irreversível no mundo, a reversibilidade se desloca no tempo em vez de desaparecer. Uma janela curta entre decidir e efetivar converte o irreversível em cancelável, e frequentemente basta que ela dure segundos. Onde nem isso é possível, resta a compensação — uma reversão aproximada, que precisa ser tratada como tal. Uma compensação que ninguém executou nunca é uma hipótese, não um plano.

Todo sistema de decisão automatizada tem um domínio em que foi validado e um comportamento fora dele. O segundo quase nunca é projetado. A propriedade perigosa não é errar: é errar com a mesma confiança dentro e fora da faixa onde alguém já verificou que o sistema funciona. Um modelo estatístico não avisa que saiu da distribuição; um conjunto de regras não avisa que o caso à frente não estava previsto quando as regras foram escritas.

Isso torna a recusa uma saída legítima, que precisa ser desenhada como as outras: uma condição que a dispara, um destino para o caso recusado e alguém que sabe o que fazer com ele. Sem esse destino, a recusa vira uma fila que ninguém olha, o que é pior do que decidir errado, porque parece prudência.

Um sistema que nunca se recusa a decidir não é mais confiável. Ele apenas não avisa quando está fora do que conhece.

Automação não elimina o decisor; muda o endereço dele. Quem definiu o limiar decidiu — para todos os casos futuros, de uma vez, sem ver nenhum deles. Isso não é um problema, desde que esteja escrito. O problema é a decisão ficar sem dono, e a forma mais comum disso é embaralhar quatro papéis num só:

• —Quem decide a regra: define o limiar e responde por ele quando o limiar for revisto.
• —Quem aprova o caso: confirma antes do efeito, nas classes de ação que param e esperam.
• —Quem pode sobrepor: age contra a recomendação do sistema — e cuja sobreposição precisa ser registrada, porque sobreposição não registrada é um segundo sistema, invisível e sem manutenção.
• —Quem é informado: não decide nada, mas precisa saber a tempo de reagir. Essa lista envelhece mais rápido do que qualquer outra parte do desenho.

Nenhum desses papéis é preenchido por uma equipe. São preenchidos por uma função com nome, porque uma equipe não pode ser acordada de madrugada nem responder a uma pergunta de auditoria. Onde a organização se recusa a nomear, o sistema nomeia por ela: o dono efetivo passa a ser quem tiver acesso e coragem no momento.

O mesmo defeito custa coisas diferentes conforme o momento em que aparece. Descoberto no desenho, é uma conversa. Em teste, é um dia. Em produção com detecção rápida, é um incidente contido. Em produção sem detecção, é um número desconhecido de decisões erradas já aplicadas, que continuam produzindo efeito enquanto ninguém olha — e que, quando finalmente aparecem, aparecem pelo pior canal possível: um cliente, um regulador, um repórter.

Por isso, em decisões de consequência material, detecção é parte do desenho e não do plano de operação. Conciliação contra uma fonte independente, porque um sistema não pode ser a testemunha do próprio acerto. Invariantes verificadas continuamente, e não apenas testadas uma vez. Revisão humana por amostragem mesmo quando nada parece errado, porque a única maneira de conhecer a taxa de erro de um sistema que ninguém revisa é esperar por uma reclamação. E operação em paralelo antes do corte, quando possível: deixar o sistema novo decidir sem efeito enquanto o antigo ainda decide de verdade é a forma mais barata de descobrir cedo.

A objeção previsível é que tudo isso atrasa. Na prática, o que atrasa é fazer depois: acrescentar reversibilidade a uma operação que já escreve direto no estado, instalar uma fronteira de recusa num sistema que já foi apresentado internamente como infalível, ou descobrir a taxa de erro pela reclamação e ter de responder por todo o período anterior. Cada um desses é um projeto. Nenhum deles era, no desenho, mais do que uma decisão.

Há um efeito de segunda ordem que importa mais do que a economia direta. Quando o custo de errar é limitado por construção, uma organização pode se mover rápido, porque a velocidade deixa de ser uma aposta. Quando não é, ela se protege da única maneira que resta — comitês, aprovações genéricas, lentidão distribuída em toda parte menos onde o risco realmente está.

Não se projeta para nunca errar. Projeta-se para que errar continue sendo uma informação, e não um dano permanente.

Nenhuma dessas propriedades exige tecnologia rara. Exigem que alguém, antes da primeira linha, faça quatro perguntas em voz alta e escreva as respostas: isto pode ser desfeito, e como; onde fica a borda do que este sistema sabe; quem responde por esta decisão quando ela for questionada; e por qual canal vamos descobrir que ela estava errada. Sistemas que não conseguem responder às quatro não são necessariamente inseguros. São apenas sistemas cuja segurança depende de nada de excepcional acontecer.