Por que a maioria dos postmortems não identifica o verdadeiro modo de falha

Introdução

Postmortems deveriam extrair verdade das falhas, mas muitos acabam documentando sintomas em vez de mecanismos. Eles identificam um evento desencadeador, listam “causas raiz” e encerram com itens de ação — enquanto o sistema que produziu o incidente permanece praticamente inalterado em suas dinâmicas fundamentais. A discrepância não é primariamente uma questão de diligência; é estrutural. Postmortems frequentemente se apoiam em modelos causais que são lineares demais para sistemas sociotécnicos complexos.

Este ensaio explica por que postmortems frequentemente não identificam o verdadeiro modo de falha e como um enquadramento causal mais rigoroso expõe os mecanismos mais profundos que os incidentes revelam.

1) A confusão entre gatilhos e mecanismos

Em sistemas complexos, o evento que imediatamente precede a falha raramente é o mecanismo que tornou a falha inevitável. Uma mudança de configuração pode ser o gatilho, mas o mecanismo é frequentemente um acoplamento latente, um acúmulo de risco ou um incentivo organizacional que normalizou a fragilidade.

Formalmente, seja $F$ a falha, $T$ um gatilho e $L$ uma condição latente. Postmortems frequentemente modelam a causalidade como $T \rightarrow F$. Mas um modelo mais preciso é:

$$L \land T \rightarrow F.$$

Se $L$ é persistente e $T$ é meramente um entre muitos gatilhos possíveis, então corrigir $T$ não altera a propensão do sistema a falhar. O verdadeiro modo de falha é a estrutura que tornou o gatilho catastrófico.

2) A análise linear de causa raiz falha em sistemas não lineares

Muitos postmortems ainda assumem um modelo linear de cadeia de eventos. Mas sistemas modernos exibem dinâmicas não lineares: loops de retroalimentação, efeitos de limiar e dependências em cascata. Pequenas perturbações podem se amplificar em grandes falhas.

Um modelo estilizado do estado do sistema $s$ sob perturbação $\epsilon$ é:

$$\Delta s_{t+1} = f(\Delta s_t, \epsilon).$$

Quando $f$ é não linear, um $\epsilon$ pequeno pode empurrar o sistema além de um limite de estabilidade. Nesses casos, uma cadeia causal linear é insuficiente; o verdadeiro modo de falha é a perda de estabilidade, não a última perturbação.

3) Postmortems subestimam o acoplamento latente e dependências ocultas

A maioria dos incidentes é emergente: resultam de interações entre componentes que foram projetados e analisados isoladamente. Fronteiras de abstração ocultam essas interações, e postmortems tendem a reforçar essas fronteiras ao atribuir a causa a uma única camada.

Sejam $A$ e $B$ componentes assumidos como independentes. Se seus eventos de falha são na verdade correlacionados, então o risco no nível do sistema é subestimado:

$$P(A \cup B) = P(A) + P(B) - P(A \cap B).$$

Postmortems frequentemente omitem o termo de interseção. O “verdadeiro modo de falha” é geralmente que $P(A \cap B)$ é não desprezível devido a dependências compartilhadas, contenção de recursos ou gatilhos de falha sincronizados.

4) Incentivos distorcem narrativas causais

Postmortems não são artefatos puramente técnicos; são documentos sociais. Incentivos moldam quais causas são aceitáveis de registrar. Causas proximais e localizadas são mais seguras de reconhecer do que causas estruturais que implicam prioridades organizacionais, dimensionamento de equipe ou débito arquitetural.

Isso cria um viés sistemático: o postmortem gravita em direção a causas que são acionáveis dentro do controle de uma equipe, mesmo quando essas causas não são os principais drivers de risco. O verdadeiro modo de falha é assim reformulado em um conjunto de correções convenientes.

5) A metáfora da “causa raiz” frequentemente está errada

A noção de uma única causa raiz é um vestígio de sistemas mais simples. Em sistemas complexos, falhas são sobredeterminadas: múltiplas condições precisam se alinhar, e nenhum fator isolado é suficiente por si só.

A causalidade aqui é melhor representada como um conjunto de fatores contribuintes $\{c_i\}$ onde a falha ocorre se um subconjunto excede um limiar:

$$F \iff \sum_i w_i c_i \ge \tau.$$

Esse modelo implica que postmortems deveriam identificar gradientes de risco em vez de raízes — o quão perto o sistema estava da falha e quais fatores o empurraram além do limiar.

6) Lacunas de observabilidade escondem o verdadeiro mecanismo

Postmortems dependem de sinais observáveis: logs, métricas, traces e relatórios de usuários. Mas o mecanismo da falha frequentemente reside em estados não observados — saturação de recursos, colapso de contrapressão ou interações de filas.

Se o estado do sistema $z$ é oculto, analistas o inferem a partir de uma projeção $x = g(z)$. Este é um problema inverso, e pode ser mal posto. Múltiplos estados ocultos podem mapear para a mesma assinatura observável, levando a conclusões ambíguas. Postmortems então corrigem o sintoma capturado em $x$, não o mecanismo em $z$.

7) Equívocos comuns que distorcem postmortems

Equívoco 1: “Se corrigirmos a última mudança, o sistema está seguro.” Isso confunde correlação com causalidade. A última mudança pode ser incidental em relação às condições que tornaram a falha provável.

Equívoco 2: “Se adicionarmos monitoramento, resolvemos a causa raiz.” Observabilidade reduz incerteza, mas não altera dinâmicas do sistema. É uma ferramenta de diagnóstico, não um mecanismo corretivo.

Equívoco 3: “Erro humano é a causa.” Ações humanas fazem parte do sistema. Rotulá-las como “causa” frequentemente obscurece as restrições, incentivos ou designs de interface que tornaram essas ações racionais ou inevitáveis.

8) Um enquadramento mais rigoroso: falhas como propriedades do sistema

Em vez de buscar raízes, deveríamos modelar falhas como propriedades do design do sistema sob incerteza. Um postmortem rigoroso pergunta:

• Quais invariantes do sistema foram violadas?
• Quais condições latentes tornaram o sistema frágil?
• Como loops de retroalimentação amplificaram a perturbação?
• Quais controles de risco falharam ou estavam ausentes?

Isso desloca a análise de sequências de eventos para estabilidade do sistema e topologia de risco.

9) Paralelos com segurança: exploração vs. exposição

Incidentes de segurança frequentemente exibem o mesmo padrão. O exploit não é o modo de falha; é o vetor que o descobre. O verdadeiro modo de falha é a exposição: a aceitação pelo sistema de entradas inseguras, a falta de defesa em profundidade ou a fronteira de confiança implícita que foi cruzada.

Postmortems que focam no exploit em vez da exposição serão repetidamente surpreendidos por variações do mesmo ataque.

Conclusão

A maioria dos postmortems não identifica o verdadeiro modo de falha porque utiliza modelos causais que são estreitos demais para os sistemas que analisa. Eles focam em gatilhos, tratam a causalidade como linear e produzem narrativas restringidas por incentivos organizacionais e limites de observabilidade.

Uma abordagem mais rigorosa trata a falha como uma propriedade das dinâmicas do sistema sob incerteza. Busca identificar condições latentes, estruturas de retroalimentação e gradientes de risco, não apenas a última mudança. Este é um trabalho mais difícil e menos satisfatório do que uma simples causa raiz — mas é o único caminho para melhorias genuínas em confiabilidade e segurança.