Por que sistemas críticos falham antes do incidente

Um relatório de incidente quase sempre nomeia o último evento: o certificado que expirou, a fila que encheu, a migração que rodou duas vezes. É verdade e é inútil. O último evento é apenas o único que teve testemunhas.

A cadeia que interessa é anterior e não tem hora marcada. Ela é feita de escolhas que pareciam razoáveis quando foram feitas, tomadas por pessoas competentes, sob prazos reais. Quatro mecanismos aparecem com frequência suficiente para serem tratados como estrutura, e não como azar: a fronteira não declarada, a dependência assumida, o estado que ninguém consegue ler e a decisão sem registro. Nenhum deles é uma falha de tecnologia. Todos são falhas de descrição.

A fronteira não declarada

Uma fronteira é o ponto onde a responsabilidade muda de dono. Deste lado, valida-se o formato; do outro, confia-se nele. A dificuldade é que a fronteira existe no código muito antes de existir na cabeça de alguém. Duas equipes integram dois serviços, cada uma pressupondo que a outra é a mais rígida, e o pressuposto nunca é escrito porque nunca é contestado.

O comportamento resultante é específico: o sistema aceita uma entrada que qualquer pessoa envolvida teria chamado de impossível. Não houve invasão nem defeito de lógica — houve um campo que ninguém achou que precisava checar porque presumiu que já chegava checado. Fronteiras não declaradas também são o que transforma um erro pequeno em um erro que atravessa domínios: sem contrato explícito, não existe lugar natural onde interromper a propagação.

A dependência assumida

Toda integração é verificada uma vez, no dia em que é construída. Depois disso, a verificação vira crença. A distância entre as duas cresce em silêncio, porque nada no sistema mede o envelhecimento de um pressuposto.

O detalhe que gera a falha é quase sempre este: o contrato do qual você realmente depende é maior do que o contrato que foi escrito. Você depende da ordem em que os registros voltam, da latência habitual, do fato de que o campo opcional sempre vem preenchido, do jeito como o fornecedor se comporta sob erro. Nada disso foi prometido. Quando o fornecedor muda algo bem dentro do que prometeu, ele não quebrou o contrato — quebrou o seu sistema. E a conversa que se segue é sobre culpa, quando deveria ser sobre qual metade do acoplamento nunca foi declarada.

Um pressuposto não verificado não é uma hipótese. É uma dívida que vence sem aviso.

O estado que ninguém consegue ler

Um sistema em produção carrega estado que não aparece em lugar nenhum: filas parcialmente drenadas, caches com entradas de gerações diferentes, contadores de retentativa, escritas concluídas pela metade, combinações de chaves de funcionalidade que nunca foram enumeradas. Métricas de infraestrutura mostram consumo, não significado. É perfeitamente possível ter uma parede de painéis verdes e nenhuma resposta para a pergunta que importa durante o incidente: o que este sistema está fazendo agora?

Esse é o mecanismo que governa a duração, e duração é o que transforma incidente em prejuízo. A primeira hora de quase todo incidente é gasta estabelecendo o que é verdade, e essa hora é longa na exata proporção em que o estado é inferido em vez de consultado. Observabilidade, nesse sentido, não é um produto que se compra: é a decisão de desenho de manter o estado interno legível de fora, tomada enquanto ele ainda é pequeno o bastante para caber numa resposta.

A decisão sem registro

Todo sistema é uma pilha de decisões: este tempo limite, esta política de retentativa, esta profundidade de fila, esta exceção silenciada, este campo que continua sendo escrito e não é mais lido por ninguém. Cada uma foi razoável sob um pressuposto — o volume da época, o comportamento de um fornecedor, uma regra de negócio que existia. Quase nenhuma foi registrada ao lado do pressuposto que a justificava.

O efeito prático é que o sistema perde a capacidade de ser revisto. Revisão de código guarda o que mudou, raramente por quê. Anos depois, alguém competente olha uma proteção que parece redundante e a remove — corretamente, dado tudo o que essa pessoa consegue saber. Não havia como saber. A informação que teria mudado a decisão saiu da empresa junto com quem a tomou. Essa é a forma mais comum de regressão em sistemas maduros, e ela não aparece em nenhuma métrica de qualidade de código.

Como os quatro se combinam

Isolado, cada mecanismo é sobrevivível. Sistemas convivem por anos com fronteiras vagas e dependências não auditadas sem que nada aconteça. O incidente é a interseção: a fronteira não declarada deixa entrar o que não deveria; a dependência assumida muda de forma no mesmo período; o estado ilegível esconde o efeito por horas; e a decisão sem registro faz com que quem está de plantão não consiga distinguir uma proteção deliberada de um resíduo. Nenhuma dessas quatro coisas é o incidente. Juntas, são.

Todos os quatro emitem sinal antes de falhar, e o sinal é organizacional antes de ser técnico:

• —Fronteira: duas equipes descrevem a mesma integração de maneiras diferentes e ninguém trata isso como defeito.
• —Dependência: a pergunta sobre o que acontece se aquele serviço mudar é respondida com um nome, e não com um comportamento.
• —Estado: perguntas sobre produção são respondidas por inferência, e as respostas divergem entre pessoas.
• —Decisão: o motivo de um parâmetro ter o valor que tem depende de alguém específico estar disponível para explicar.

Nenhum desses sinais exige ferramenta para ser notado. Exigem que alguém tenha mandato para tratá-los como defeito enquanto ainda são baratos, e é aqui que a cadeia é de fato organizacional: numa empresa comum, ninguém é promovido por eliminar um incidente que não aconteceu.

A engenharia que evita o incidente é, por fora, indistinguível da engenharia que não fez nada.

Não escrevemos isto como prescrição de boas práticas. Uma prática é boa quando muda o comportamento do sistema sob pressão; o resto é vocabulário. A afirmação estreita que este texto sustenta é outra: quando um sistema crítico falha, a data útil da falha é anterior ao incidente — é o dia em que uma fronteira deixou de ser escrita, um pressuposto deixou de ser verificado, um estado deixou de ser legível ou uma decisão deixou de ser registrada. Esses dias têm dono e cabem numa agenda. O incidente não.