ARQUIVO_DE_PESQUISA
A ciência dos incidentes de engenharia e identidade
"Quem quebrou o prod?"
VER A PRÁTICA
Transforme um pensamento que esta pesquisa explica em um passo claro.
O PENSAMENTO
“Reescrevê-lo corretamente significaria admitir que não consigo apenas consertar o que está lá”
SUA RESPOSTA GRAVADA
“Herdei o código, não o criei. Sou responsável pelo que mudo a partir de agora, não por tudo que veio antes.”
UM PASSO PRIVADO
Pegue uma função pequena do código legado e reescreva-a em um arquivo temporário sem mostrar. Contar quantas linhas poupou e que premissas ficaram claras.
parece a pergunta certa depois de uma interrupção. A pesquisa sobre sistemas dá uma resposta menos satisfatória, mas muito mais útil: sistemas complexos falham pelo alinhamento de muitas condições pequenas, não por um ator imprudente (Reason 1990; Google SRE 2016). Enquanto isso, as pessoas mais responsáveis por manter esses sistemas funcionando — as que fazem trabalho de infraestrutura, plantões e trabalho de cola — são sistematicamente sub-reconhecidas (Champion et al. 2024). E agora uma nova ameaça de identidade se sobrepõe: as ferramentas de IA que prometem substituir engenheiros são confiáveis para uma minoria cada vez menor de desenvolvedores (Stack Overflow 2025). O roteiro antigo — 'alguém aqui é o vilão' — quase sempre está sendo lido errado.
Como a ciência mudou
- 1983
The Managed Heart, de Arlie Hochschild, cunha o conceito de trabalho emocional — trabalho que exige gerenciar os próprios sentimentos como parte do emprego, mas que não é contabilizado em nenhum registro formal. O conceito ancora posteriormente a pesquisa sobre trabalho de cola invisível em equipes de software. ↗
- 1990
James Reason publica Human Error, introduzindo o modelo do queijo suíço da causalidade de acidentes: falhas ocorrem quando buracos em múltiplas camadas defensivas se alinham, não porque uma pessoa cometeu um erro. O modelo se torna fundamental para a aviação, medicina e, posteriormente, para a confiabilidade de software. ↗
- 2006
The Field Guide to Understanding Human Error, de Sidney Dekker, reformula o 'erro humano' como sintoma, não causa — o engenheiro que clicou no botão errado o fez dentro de um sistema que permitia ou encorajava essa ação. A culpa, argumenta Dekker, para as investigações na camada errada. ↗
- 2012
John Allspaw e Jesse Robbins popularizam os post-mortems sem culpa na Etsy, argumentando que engenheiros que temem punição escondem informações — e informações ocultas matam a confiabilidade. Sua abordagem influencia posteriormente a prática de Site Reliability Engineering do Google. ↗
- 2016
O Google publica seu SRE Book, dedicando um capítulo inteiro à cultura de post-mortem. O capítulo codifica a isenção de culpa como política organizacional: 'os objetivos primários de escrever um post-mortem são garantir que o incidente esteja documentado, que todas as causas-raiz contribuintes sejam compreendidas e que ações preventivas eficazes sejam implementadas.' ↗
- 2018
Forsgren, Humble e Kim publicam Accelerate, correlacionando práticas organizacionais com desempenho de entrega de software em milhares de equipes. Seus dados mostram que equipes de alto desempenho se distinguem não por heróis sem culpa, mas por segurança psicológica, ciclos de feedback rápidos e propriedade distribuída da confiabilidade. ↗
- 2024
Champion et al. publicam um estudo empírico de grande escala sobre o trabalho invisível em ecossistemas de software de código aberto: manutenção de infraestrutura, documentação, revisão de código e gerenciamento de comunidade são sistematicamente sub-reconhecidos em comparação com commits de funcionalidades — e a lacuna prejudica engenheiros que se especializam em confiabilidade em vez de novidade. ↗
O que as pessoas acreditam vs. o que os dados mostram
A crença“Quando um incidente de produção acontece, sempre há uma causa raiz e uma pessoa responsável por ela.”
Os dadosO modelo do queijo suíço de Reason e o guia de campo de Dekker mostram que falhas em sistemas complexos exigem que múltiplos buracos em múltiplas camadas defensivas se alinhem simultaneamente. O SRE Book do Google rejeita explicitamente o pensamento de causa raiz única: incidentes são o produto de condições latentes, não de vilões individuais. ↗
A crença“Se você quer responsabilidade após um incidente, alguém precisa ser culpado e punido.”
Os dadosAllspaw e Robbins documentaram o oposto: o medo de punição faz engenheiros reterem informações, o que torna incidentes futuros mais prováveis. O framework de post-mortem sem culpa do Google mostra que a responsabilidade real — causas documentadas, correções de sistema, ações preventivas — é na verdade incompatível com a culpa individual. ↗
A crença“Engenheiros que trabalham em infraestrutura, plantões e documentação estão fazendo trabalho menos valioso do que os que entregam funcionalidades visíveis.”
Os dadosO estudo empírico de Champion et al. de 2024 sobre ecossistemas de código aberto constatou que manutenção de infraestrutura, documentação e revisão de código são sistematicamente sub-reconhecidos, embora sejam a base sobre a qual as funcionalidades visíveis rodam. Os dados do Accelerate de Forsgren et al. mostram que o trabalho de confiabilidade — não apenas a velocidade de funcionalidades — prevê alto desempenho organizacional. ↗
A crença“A resposta correta a um incidente é encontrar a pessoa que estava de plantão e responsabilizá-la.”
Os dadosO framework de post-mortem SRE do Google separa explicitamente a pessoa respondendo das condições que possibilitaram a falha. O engenheiro de plantão é frequentemente quem trouxe o problema à tona, não quem criou as condições. Tratá-lo como a causa desencoraja futuros respondentes de se engajar honestamente. ↗
A crença“Ferramentas de codificação de IA são agora confiáveis o suficiente para que engenheiros que se sentem ansiosos com a IA substituindo-os sejam irracionais.”
Os dadosA Pesquisa de Desenvolvedores do Stack Overflow 2025 constatou que a confiança dos desenvolvedores na saída de IA está em um mínimo histórico — a maioria dos desenvolvedores não confia totalmente em código gerado por IA. A ansiedade com ferramentas de IA é uma resposta profissional bem fundamentada a uma tecnologia imatura sendo comercializada como madura. ↗
TESTE-SE · Quanto você sabe desta ciência?
01 O que o modelo do queijo suíço de James Reason diz sobre como sistemas complexos falham?
O modelo de Reason mostra que falhas em sistemas complexos são multicausais: uma série de buracos em camadas defensivas que de outra forma seriam robustas precisa se alinhar para que um acidente atinja o resultado. Nenhuma pessoa sozinha cria todos os buracos. fonte ↗
02 De acordo com o capítulo do SRE Book do Google sobre cultura de post-mortem, qual é o objetivo principal de um post-mortem sem culpa?
O SRE Book do Google afirma que os objetivos primários de um post-mortem são garantir que o incidente esteja documentado, que todas as causas raiz contribuintes sejam compreendidas e que ações preventivas eficazes sejam implementadas — não atribuir culpa a indivíduos. fonte ↗
03 O que o estudo de Champion et al. de 2024 constatou sobre trabalho de infraestrutura e cola em ecossistemas de software de código aberto?
Champion et al. constataram que manutenção de infraestrutura, documentação, revisão de código e gerenciamento de comunidade são estruturalmente invisíveis na maioria dos sistemas de reconhecimento — apesar de serem essenciais para o funcionamento do ecossistema — enquanto commits de funcionalidades atraem crédito desproporcional. fonte ↗
04 De acordo com a Pesquisa de Desenvolvedores do Stack Overflow 2025, o que está acontecendo com a confiança dos desenvolvedores em código gerado por IA?
A Pesquisa de Desenvolvedores do Stack Overflow 2025 constatou a confiança dos desenvolvedores na saída de IA em um mínimo histórico — a maioria dos desenvolvedores não confia totalmente em código gerado por IA, apesar da rápida proliferação de ferramentas de codificação de IA. fonte ↗
05 O que Allspaw e Robbins descobriram sobre o efeito da cultura de culpa nas investigações de incidentes de engenharia?
Allspaw e Robbins documentaram que o medo de punição faz engenheiros esconderem informações sobre o que aconteceu durante um incidente. Essas informações ocultas impedem a organização de compreender e corrigir as condições reais — tornando o próximo incidente mais provável. fonte ↗