No último texto, falamos sobre como as crises têm o estranho hábito de aparecer no fim da tarde de uma sexta-feira, e como, muitas vezes, elas são tratadas como eventos isolados. Ignoramos suas causas profundas, apagamos o incêndio, respiramos aliviados... até que tudo se repete.
Essa repetição constante de falhas nos leva a viver o que pode ser chamado do "dia da marmota", um ciclo vicioso onde sempre voltamos ao mesmo ponto. Como quebrar esse padrão?
Vamos começar com uma analogia poderosa.
Acidentes de carro acontecem todos os dias. E, geralmente, pelas mesmas razões: distração, imprudência, falta de manutenção.
Pouco se investiga, pouco se documenta, e quase nada muda. Já os acidentes aéreos são raros, mas quando ocorrem, são profundamente analisados. Cada detalhe é estudado, discutido e documentado. As lições aprendidas são transformadas em normas, manuais e treinamentos. O resultado é uma indústria que evolui com cada falha e torna o próximo voo ainda mais seguro.
No mundo da tecnologia, deveríamos fazer o mesmo. Incidentes acontecem, mas repetir os mesmos erros não pode ser parte do nosso processo.
Uma ferramenta poderosa para essa transformação é o post mortem: uma análise estruturada, empática e colaborativa dos eventos que levaram à crise, com foco em aprendizado, não em punição.
A seguir, compartilho 10 passos práticos para conduzir um post mortem que vá além do superficial, e que realmente gere evolução contínua.
1. Escolha o Momento Certo
Assim como não se investiga um acidente no meio do resgate, não se deve fazer um post mortem no calor do momento.
Evite realizar a análise logo após o incidente. Nesse momento, as emoções ainda estão à flor da pele, e pode faltar clareza. Por outro lado, esperar demais pode causar esquecimento de detalhes importantes.
📌 Recomendo: agendar o post mortem entre 2 a 5 dias úteis após a crise, garantindo tempo para análise e preparação, sem deixar o caso esfriar.
2. Construa uma Linha do Tempo Clara
Uma das primeiras etapas é reconstituir a sequência de eventos, como se estivéssemos narrando uma história real, com começo, meio e fim.
Inclua:
- Quando e como o problema foi detectado?
- Quais alertas foram gerados?
- Quem foi acionado?
- Quais decisões foram tomadas?
- Quando e como o sistema foi estabilizado?
📌 Ferramenta útil: crie uma linha do tempo visual e colaborativa. Isso ajuda todos os envolvidos a terem uma compreensão comum dos fatos.
3. Envolva as Pessoas Certas
Não é uma reunião aberta. O post mortem deve contar com quem tem contexto e pode contribuir com informações valiosas.
Inclua:
- As pessoas que atuaram na crise;
- Representantes de áreas impactadas;
- Especialistas que possam propor melhorias reais.
📌 Evite excesso de participantes. Muita gente na sala pode inibir o debate e tornar a reunião improdutiva.
4. Crie um Ambiente Seguro
Erros acontecem. Mas quando o ambiente é punitivo ou competitivo, as pessoas se calam. E onde não há transparência, não há aprendizado.
📌 Crie um espaço de confiança:
- Reforce que o objetivo não é apontar culpados, mas entender causas e contextos;
- Valorize a coragem de quem compartilha falhas;
- Adote o modelo de blameless post mortem, que foca no sistema, e não na pessoa.
5. Garanta Entendimento para Todos
Nem todos na sala falam o mesmo idioma técnico. E mesmo entre técnicos, há níveis e especialidades diferentes.
📌 Evite jargões ou explicações incompletas;
📌 Esclareça siglas, processos ou termos;
📌 Lembre-se: a responsabilidade por uma comunicação clara é sempre de quem fala.
Isso fortalece o entendimento e a colaboração, evitando mal-entendidos que poderiam se tornar novas crises.
6. Identifique os Fatores Contribuintes
É tentador buscar uma causa única, mas a verdade é que crises são multifatoriais. Pequenas falhas, decisões, suposições ou silêncios se somam até algo quebrar.
Uma forma eficiente de encontrar essas causas é a técnica dos 5 Porquês.
📌 A ideia é simples: pergunte “por quê?” pelo menos cinco vezes a partir do problema identificado, até chegar à origem mais profunda e mapear os fatores contribuintes.
👉 Exemplo prático:
Problema: O site ficou fora do ar por 30 minutos.
1️⃣ Por que o site saiu do ar? → Porque o servidor principal travou.
2️⃣ Por que o servidor travou? → Porque a CPU estava em 100%.
3️⃣ Por que a CPU estava em 100%? → Porque houve um pico de tráfego não esperado.
4️⃣ Por que não esperávamos esse tráfego? → Porque o time de marketing lançou uma campanha sem avisar o time de infraestrutura.
5️⃣ Por que não houve comunicação entre os times? → Porque não existe um processo formal de integração entre marketing e tecnologia.
Fatores Contribuintes Identificados
- Comunicação insuficiente: Não há canais ou rituais definidos para alinhar lançamentos de marketing e infraestrutura.
- Monitoramento reativo: Falta de alertas pró‑ativos para variações acima de certo limiar de CPU ou tráfego.
- Autoscaling não configurado (HPA): O Horizontal Pod Autoscaler estava ausente ou com thresholds muito altos, impedindo o escalonamento automático dos recursos.
- Ausência de testes de carga: Possivelmente, nunca foi executado um teste de stress ou carga para validar a capacidade em cenários de pico.
- Processo de resposta a incidentes frágil: Não há runbooks claros nem papéis definidos para acionamento rápido em crise.
- Suposições não documentadas: Ficou implícito que “se todo mundo for avisado no Slack, já basta”, mas sem garantia de visibilidade ou confirmação.
7. Avalie a Resposta à Crise
Mais do que entender o problema, é essencial analisar como a equipe reagiu.
Divida a avaliação em três partes:
- O que funcionou bem e deve ser repetido?
- O que não funcionou e precisa ser eliminado ou ajustado?
- O que poderia ter sido feito de forma diferente?
📌 Perguntas úteis:
- As pessoas sabiam o que fazer?
- Havia documentação clara?
- A comunicação entre times foi fluida?
- Houve decisões acertadas que aceleraram a resolução?
👉 Valorize o que deu certo. Celebrar os acertos cria confiança e constrói maturidade organizacional.
8. Crie um Plano de Ação Concreto
Um post mortem sem ações claras é como um relatório ignorado numa gaveta.
Para cada fator identificado, defina:
- Uma ação preventiva ou corretiva;
- Um responsável claro;
- Um prazo realista;
- Um critério de conclusão.
Para ilustrar de forma mais enxuta, vamos focar nos 3 fatores principais identificados:
-
Comunicação insuficiente
- Ação: Estabelecer um “Release Alignment” quinzenal entre marketing e infraestrutura.
- Responsável: Líder de Infraestrutura.
- Prazo: 2 semanas.
- Critério de conclusão: Primeira reunião realizada e ata validada por ambos os times.
-
Monitoramento reativo
- Ação: Configurar alertas proativos em Prometheus/Grafana para CPU > 70% e tráfego > 80% da capacidade.
- Responsável: Engenheiro de Observabilidade.
- Prazo: 1 semana.
- Critério de conclusão: Alertas testados com simulação de pico e aprovados em staging.
-
Autoscaling não configurado (HPA)
- Ação: Implementar HPA no cluster Kubernetes com thresholds para escalar automaticamente.
- Responsável: DevOps.
- Prazo: 10 dias.
- Critério de conclusão: Teste de carga demonstra escalonamento sem degradação de performance.
Com este plano reduzido, cada ação tem clareza de “o quê”, “quem”, “quando” e “como” medir, garantindo que o “dia da marmota” não se repita.
📌 E o mais importante: acompanhe a execução. O aprendizado só vira prática se for implementado.
9. Documente Tudo com Clareza e Intenção
O que nos torna uma espécie avançada não é apenas a linguagem, é a capacidade de registrar e transmitir conhecimento de forma assíncrona ao longo dos séculos.
A documentação de uma crise serve para que outras pessoas, em outros contextos, possam entender, aprender e evitar os mesmos erros.
📌 Inclua:
- A linha do tempo;
- Os fatores identificados;
- As ações tomadas;
- As lições aprendidas;
- Recomendações e observações úteis.
Assim como os manuais da aviação são atualizados após cada acidente, devemos usar nossos incidentes para revisar nossos processos e padrões. A documentação é onde esse aprendizado se materializa.
10. Compartilhe com as Lições Apreendidas (Sempre que Possível)
Aprendizado que fica preso em um time é conhecimento desperdiçado. Sempre que possível, compartilhe o post mortem (ou pelo menos suas lições principais) com outras áreas da organização.
📌 Isso:
- Evita que outros repitam os mesmos erros;
- Gera cultura de melhoria contínua;
- Cria visibilidade para o esforço e evolução da equipe. Pode ser em forma de:
- Newsletter interna;
- Apresentação no all hands;
- Canal de incidentes em ferramentas como Slack ou Confluence.
👉 E se o incidente for relevante para o mercado, considere compartilhar publicamente, como fazem grandes empresas de tecnologia, contribuindo para toda a comunidade.
✈️ Conclusão: A Crise Como Alicerce da Evolução
Crises são inevitáveis. Repeti-las, não.
Quando você trata cada incidente como uma oportunidade real de aprendizado, e estrutura esse aprendizado com empatia, clareza e disciplina, sua equipe cresce. Sua cultura amadurece. E sua organização se fortalece.
O post mortem é a ponte entre o que falhou e o que pode ser melhor.
Use-o como uma ferramenta de transformação.
Faça como a aviação: aprenda com cada queda para voar ainda melhor.
E quem sabe, um dia, as sextas-feiras voltem a ser só... sextas-feiras. 😄
Top comments (0)