MECANISMOS_NOMEADOS
A ciência dos incidentes de engenharia e identidade: por que quase nunca é culpa do vilão
3 mecanismos nomeados — "Quem quebrou o prod?" parece a pergunta certa depois de uma interrupção. A pesquisa sobre sistemas dá uma resposta menos satisfatória, mas muito mais
Cultura de post-mortem sem culpa é a prática organizacional de investigar falhas focando nas condições e fatores sistêmicos que as possibilitaram, em vez de em qual indivíduo as causou. Codificada pelo SRE Book do Google e pioneira em escala por Allspaw e Robbins na Etsy, a abordagem sustenta que a punição desincentiva o compartilhamento honesto de informações necessário para compreender e prevenir falhas futuras.
Como soa na sua cabeçaO roteiro interno depois de um incidente: 'Fiz o deploy e o site caiu — vou ser demitido.' A cultura de post-mortem sem culpa reformula a pergunta: quais condições permitiram que esse deploy chegasse à produção, quais lacunas de monitoramento deixaram a falha se propagar, e quais mudanças de sistema previnem isso na próxima vez — não quem pressionou qual botão.
Trabalho de infraestrutura invisível descreve o trabalho de engenharia — plantões, manutenção de sistemas, atualizações de dependências, documentação, revisão de código, gerenciamento de comunidade — que mantém os sistemas de software funcionando, mas não gera nenhuma saída visível nos sistemas convencionais de rastreamento de contribuições. O estudo empírico de Champion et al. de 2024 constata que esse trabalho é sistematicamente sub-creditado em relação ao desenvolvimento de funcionalidades, criando uma lacuna de reconhecimento que molda trajetórias de carreira e autopercepção dos engenheiros que o fazem.
Como soa na sua cabeçaO roteiro interno: 'Passei três meses migrando nosso driver de banco de dados depreciado e ninguém percebeu — talvez eu deva me concentrar em funcionalidades que as pessoas possam ver.' A pesquisa nomeia isso como um problema de reconhecimento estrutural, não uma falha individual em comunicar valor: os sistemas de rastreamento de contribuições não contam o trabalho de migração, então ele desaparece.
O modelo de falha do queijo suíço, introduzido por James Reason em 1990, representa as defesas de sistemas complexos como fatias de queijo suíço — cada uma com buracos representando fraquezas individuais. Uma falha não ocorre quando uma única camada falha, mas quando buracos em múltiplas camadas se alinham, permitindo que uma trajetória de acidente passe por todas elas. O modelo desloca fundamentalmente a causalidade de incidentes de 'quem fez a coisa errada' para 'que condições convergiram'.
Como soa na sua cabeçaO roteiro interno depois de um incidente de deploy: 'Eu deveria ter pego isso — claramente não sou bom o suficiente para esse papel.' O modelo do queijo suíço relê a situação: o deploy passou por revisão de código, CI, staging e feature flags antes de chegar à produção. O incidente precisou que todas essas camadas fossem porosas simultaneamente — o indivíduo que clicou em deploy herdou um sistema com muitos buracos já abertos.