São duas da manhã. Seu telefone toca com um alerta: o sistema principal está fora do ar. Usuários estão reclamando no Twitter. O CEO mandou mensagem no grupo perguntando o que está acontecendo. Depois de duas horas de investigação frentica, você descobre que uma migração de banco de dados rodou com um parâmetro errado. O serviço e restaurado. Todos vao dormir exaustos.
E agora? O que acontece na segunda-feira de manhã? Em muitas organizações, a resposta e uma caça às bruxas: "Quem fez isso? Por que não testaram melhor? Como isso foi aprovado?" Essa abordagem não apenas e injusta, como e contraproducente. Ela garante que o próximo incidente será pior, porque as pessoas vao esconder erros em vez de reporta-los.
A alternativa e o post-mortem blameless: uma análise estruturada do incidente focada em entender o que aconteceu, por que aconteceu e como evitar que aconteça novamente, sem buscar culpados. Este artigo e um guia completo para conduzir post-mortems que geram aprendizado real e fortalecem a resiliência dos seus sistemas e do seu time.
Por que blameless? A ciencia por tras da abordagem
A abordagem blameless não e sobre ser "bonzinho" ou "politicamente correto". Ela e fundamentada em décadas de pesquisa em segurança e confiabilidade de sistemas complexos, originada em indústrias como aviação, saude e energia nuclear.
Sistemas complexos falham de formas complexas
Em sistemas de software modernos, incidentes raramente tem uma única causa raiz. Eles são o resultado de uma combinação de fatores: uma mudança de código que interagiu inesperadamente com uma configuração, em um horario de pico de trafego, enquanto o sistema de monitoramento estava com um gap de cobertura. Culpar a pessoa que fez a mudança de código ignora todos os outros fatores que contribuiram.
O erro humano e sintoma, não causa
Quando alguém comete um erro que leva a um incidente, a pergunta não deveria ser "por que essa pessoa errou?" mas sim "por que o sistema permitiu que esse erro causasse esse impacto?" Se um único parâmetro errado em uma migração pode derrubar todo o sistema, o problema não e o humano que digitou errado; e o sistema que não tinha validações, rollback automático ou ambiente de teste adequado.
"Em um sistema blameless, a pergunta muda de 'quem causou o incidente?' para 'o que no nosso sistema permitiu que esse incidente acontecesse, e como podemos torna-lo mais resiliente?'"
Culpa inibe aprendizado
Quando as pessoas sabem que serão culpadas por incidentes, elas fazem duas coisas: escondem informações e evitam riscos. Ambas são terriveis para uma organização de engenharia. Esconder informações significa que incidentes menores não são reportados, e problemas sistemicos ficam invisíveis até que causem uma catastrofe. Evitar riscos significa que ninguém quer fazer deploy na sexta-feira, ninguém quer ser o primeiro a usar uma nova ferramenta, ninguém quer experimentar.
Quando conduzir um post-mortem
Nem todo incidente precisa de um post-mortem formal. Defina critérios claros para quando um post-mortem é necessário:
- Qualquer incidente que afetou usuários em produção por mais de X minutos
- Qualquer incidente que violou um SLO definido
- Qualquer incidente que exigiu intervenção manual de emergencia
- Qualquer incidente que revelou uma falha sistemica desconhecida
- Qualquer "quase-incidente" (near miss) que poderia ter sido grave
Os near misses são especialmente valiosos. Eles oferecem a oportunidade de aprender sem o custo do impacto real. Organizações que investigam near misses com a mesma seriedade que investigam incidentes reais são mais resilientes.
O processo passo a passo do post-mortem blameless
Fase 1: Coleta de dados (primeiras 24-48 horas)
Imediatamente após a resolução do incidente, comece a coletar dados enquanto as memórias estão frescas:
- Timeline detalhada: Reconstrua a sequência exata de eventos, com timestamps. Use logs, gráficos de métricas, histórico do Slack e registros de deploys para criar uma timeline factual e objetiva.
- Impacto: Quantifique o impacto do incidente. Quantos usuários foram afetados? Por quanto tempo? Qual foi o impacto financeiro estimado? Quais SLOs foram violados?
- Ações tomadas: Documente todas as ações de mitigação e resolução, na ordem em que aconteceram. Inclua tentativas que não funcionaram: elas revelam gaps de conhecimento ou ferramentas.
- Contexto técnico: Colete informações sobre o estado do sistema antes, durante e após o incidente. Mudanças recentes, métricas relevantes, configurações pertinentes.
Fase 2: A reunião de post-mortem (2-5 dias após o incidente)
Agende uma reunião de 60-90 minutos com todas as pessoas envolvidas no incidente, além de quem quiser participar como observador. O fácilitador (que não deve ser alguém diretamente envolvido no incidente) conduz a reunião seguindo uma estrutura definida.
Abertura (5 minutos): O fácilitador relembra os princípios blameless. Nenhuma pessoa será culpada. O objetivo e aprender é melhorar, não punir. Se alguém perceber linguagem de culpa durante a sessao, deve sinalizar.
Revisão da timeline (20 minutos): Revise a timeline coletada, pedindo que os participantes adicionem detalhes, corrijam imprecisoes e compartilhem seu ponto de vista. Perguntas como "O que você estava pensando nesse momento?" e "Que informação você tinha disponível quando tomou essa decisão?" ajudam a entender o contexto humano sem julgar.
Análise dos fatores contribuintes (30 minutos): Identifique todos os fatores que contribuiram para o incidente. Use a técnica dos "5 porques" para ir além dos sintomas e chegar as causas sistemicas. Não pare na primeira resposta: continue perguntando "por que?" até chegar a fatores que o time pode realmente mudar.
Exemplo de 5 porques:
- Por que o sistema ficou fora do ar? Porque a migração de banco corrompeu dados críticos.
- Por que a migração corrompeu dados? Porque o script tinha um bug no tratamento de campos nulos.
- Por que o bug não foi detectado? Porque os testes automatizados não cobriam o cenário de campos nulos.
- Por que os testes não cobriam esse cenário? Porque os dados de teste não refletiam os dados reais de produção.
- Por que não temos dados de teste realistas? Porque nunca priorizamos a criação de um ambiente de staging com dados anonimizados de produção.
Note como a análise migrou de "alguém escreveu um script bugado" para "nosso processo de teste não e adequado". A segunda conclusão é muito mais útil e não aponta dedos.
Definição de ações (20 minutos): Com base nos fatores contribuintes identificados, defina ações concretas para prevenir incidentes semelhantes no futuro. Cada ação deve ter um responsável e um prazo.
Encerramento (5 minutos): Resuma as principais conclusões e ações. Agradeca a participação de todos.
Fase 3: Documentação e acompanhamento
Após a reunião, o fácilitador escreve o documento de post-mortem e o compartilha com toda a organização. A transparência é fundamental: todos devem poder aprender com o incidente, não apenas os envolvidos.
As ações definidas devem ser rastreadas no sistema de gestão de projetos do time. No GalagoWork, você pode criar tarefas específicas vinculadas ao post-mortem, com prazos e responsáveis claros. Acompanhe o progresso nas reuniões regulares do time e garanta que as ações sejam concluídas.
Template de documento de post-mortem
Um bom documento de post-mortem segue uma estrutura padrão que fácilita a leitura e a comparação entre incidentes ao longo do tempo:
- Título e data: Nome descritivo do incidente e data da ocorrência.
- Resumo executivo: 2-3 frases que descrevem o que aconteceu e o impacto. Qualquer pessoa deve conseguir entender o incidente lendo apenas este parágrafo.
- Impacto: Métricas quantitativas do impacto (duração, usuários afetados, receita perdida, SLOs violados).
- Timeline: Sequência cronológica de eventos com timestamps.
- Fatores contribuintes: Lista dos fatores que contribuiram para o incidente, com análise dos 5 porques.
- O que funcionou bem: Aspectos da resposta ao incidente que funcionaram como esperado. E importante reconhecer o positivo.
- O que pode ser melhorado: Aspectos da resposta que poderiam ter sido melhores.
- Ações: Lista de ações com responsáveis e prazos, categorizadas por prioridade.
- Lições aprendidas: Insights gerais que podem beneficiar outros times ou projetos.
Tipos de ações pos-incidente
As ações definidas em um post-mortem geralmente se encaixam em algumas categorias:
Prevenção
Ações que evitam que a mesma classe de incidente aconteça novamente. Exemplos: adicionar validações ao pipeline de migração, implementar circuit breakers, melhorar a cobertura de testes para cenários edge case.
Detecção
Ações que permitem detectar o problema mais rapidamente na próxima vez. Exemplos: adicionar alertas para métricas que poderiam ter indicado o problema antes, melhorar dashboards, adicionar health checks.
Mitigação
Ações que reduzem o impacto quando o problema acontecer novamente. Exemplos: implementar rollback automático, adicionar feature flags para desativar funcionalidades problematicas, melhorar runbooks de resposta.
Processo
Ações que melhoram o processo de resposta a incidentes. Exemplos: atualizar o processo de on-call, melhorar a comúnicação durante incidentes, revisar critérios de escalação.
Erros comuns em post-mortems
Buscar a "causa raiz única"
Incidentes em sistemas complexos raramente tem uma única causa raiz. Buscar uma única causa simplifica demais a análise e geralmente leva a conclusões superficiais. Prefira falar em "fatores contribuintes" e reconheca que múltiplos fatores se combinaram para criar o incidente.
Ações genericas
"Melhorar o monitoramento" não e uma ação: e um desejo. Ações devem ser específicas, mensuráveis é realizaveis. "Adicionar alerta para quando a latencia do endpoint /checkout exceder 500ms" e uma ação.
Post-mortem sem follow-up
O post-mortem mais bem conduzido do mundo é inútil se as ações definidas nunca são executadas. Rastreie as ações no seu sistema de gestão, inclua-as na próxima sprint e revise o progresso regularmente.
Post-mortem como tribunal
Se a reunião se transforma em uma sessao de julgamento, você perdeu. O fácilitador deve intervir imediatamente quando linguagem de culpa aparece. Frases como "você deveria ter..." ou "por que você não..." devem ser redirecionadas para "o que podemos mudar no sistema para que..."
Limitar a participação
Post-mortems devem ser abertos. Quanto mais perspectivas, mais rico o aprendizado. Pessoas de outros times podem trazer insights valiosos que os diretamente envolvidos não percebem.
Construindo uma cultura de aprendizado com incidentes
Post-mortems individuais são valiosos, mas o verdadeiro poder aparece quando eles se tornam parte de uma cultura sistemática de aprendizado:
- Repositorio de post-mortems: Mantenha todos os post-mortems em um local centralizado e pesquisavel. Novos membros do time podem aprender com incidentes passados, e padrões recorrentes podem ser identificados.
- Revisão periodica: Trimestralmente, revise os post-mortems do período. Existem padrões? Os mesmos tipos de incidentes estão se repetindo? As ações definidas estão sendo eficazes?
- Sharing sessions: Apresente post-mortems interessantes para toda a organização. Isso normaliza falhas, democratiza aprendizados e incentiva outras equipes a conduzir seus próprios post-mortems.
- Game days: Simule incidentes intencionalmente para treinar a resposta do time e testar a resiliência dos sistemas. Chaos engineering levada a prática.
- Métricas de melhoria: Rastreie métricas como MTTR (Mean Time to Recover), frequência de incidentes por categoria e taxa de conclusão de ações de post-mortem. Use essas métricas para demonstrar o valor do processo.
Post-mortems e gestão de projetos
Post-mortems geram trabalho que precisa ser rastreado e priorizado junto com o restante do backlog do time. Ferramentas de gestão como o GalagoWork permitem:
- Criar tarefas diretamente a partir das ações do post-mortem, com labels e prioridades específicas
- Vincular tarefas de remediação aos commits e pull requests correspondentes via integração GitHub
- Visualizar o progresso das ações no board Kanban do time
- Gerar relatórios sobre o investimento em resiliência versus features novas
Conclusão: incidentes são oportunidades
Incidentes são inevitáveis em sistemas complexos. A questão não e se eles vao acontecer, mas como sua organização responde quando acontecem. Post-mortems blameless transformam incidentes de eventos traumaticos em oportunidades de aprendizado que fortalecem tanto os sistemas quanto as pessoas.
A chave e a consistencia: conduzir post-mortems para todo incidente significativo, documentar as conclusões, executar as ações e revisar periodicamente o progresso. Com o tempo, o número de incidentes diminui, o tempo de recuperação encurta e, mais importante, o time desenvolve confiança na sua capacidade de lidar com o inesperado.
Lembre-se: a meta não e zero incidentes (isso é impossível). A meta e zero incidentes repetidos pelo mesmo motivo. E isso só se alcança quando as pessoas se sentem seguras para falar a verdade sobre o que aconteceu, sem medo de represalias.