Operações11 min de leitura
Post-mortem em e-commerce: template de 1 página (sem teatro corporativo)
Loja caiu, voltou, todo mundo respirou — e dois meses depois aconteceu o mesmo. O que separa equipes que operam é a prática chata e eficaz do post-mortem. Veja o template de 1 página que funciona.
O que você vai aprender
- O que é (e o que não é) um post-mortem útil — sem teatro corporativo.
- Template de 1 página: 7 seções obrigatórias, nada de "lessons learned" vago.
- A diferença entre causa imediata e causa raiz, com exemplos de e-commerce.
- Como tornar pós-incidente uma rotina sem culpa, com ações que viram código.
Loja caiu, voltou, todo mundo respirou. Dois meses depois, o mesmo incidente — mesmo padrão, mesma causa, mesmas perguntas. Esse loop é o que separa equipes que operam de equipes que reagem. A diferença é uma prática chata, mas eficaz: post-mortem. Curto, escrito, com ações concretas.
62%
de redução em incidentes recorrentes em equipes que adotaram cultura de post-mortem sem culpa
Atlassian Incident Management Report
15 min
é o tempo médio para escrever um post-mortem na ferramenta certa (Notion/Slack/Discord doc)
Observação setorial
3-5
ações concretas é o ideal por post-mortem (mais que isso vira lista que ninguém faz)
Google SRE Book, cap. 15
~30%
das organizações ainda não fazem post-mortem regular após incidentes — perda direta de aprendizado
PagerDuty State of Digital Operations
A medida de quão maduro um time é em gestão de incidente está em onde está o foco: culpar pessoas ou consertar sistemas.— John Allspaw, "Blameless PostMortems and a Just Culture" (Etsy, 2012)
O que é (e o que não é) post-mortem
Post-mortem em e-commerce não é:
- Reunião de duas horas com 12 pessoas.
- Documento de 30 páginas em padrão ISO 27001.
- Espaço pra apontar culpados ("o Pedro deveria ter visto isso").
- "Vamos ser mais cuidadosos" como ação.
Post-mortem útil é:
- Documento de 1 página, escrito por quem viveu o incidente.
- Foco em sistemas, não pessoas ("o alerta não disparou", não "fulano não viu").
- Ações específicas, com dono e prazo — que viram tickets no backlog.
- Compartilhado no canal da equipe, lido por todos.
O template de 1 página
Copie e cole no Notion / Confluence / Google Doc / Discord — onde sua equipe consome documentação:
# Post-mortem: <título curto>
**Data do incidente:** YYYY-MM-DD HH:MM (BRT)
**Duração:** XXmin (de HH:MM a HH:MM)
**Severidade:** [Crítica | Alta | Média | Baixa]
**Autor:** <nome>
**Status:** [Em revisão | Final]
## 1. Resumo (3 linhas)
Em 3 frases: o que aconteceu, qual o impacto, como foi resolvido.
## 2. Impacto
- Receita estimada perdida: R$ XXX
- Pedidos afetados: XX (XX em pending_payment, XX em processing)
- Clientes que tentaram comprar e não conseguiram: ~XXX (estimado)
- Tickets de SAC gerados nas 24h seguintes: XX
## 3. Timeline (UTC-3)
- HH:MM — Cliente reporta erro 502 na home no canal #ops
- HH:MM — On-call confirma incidente em outras regiões
- HH:MM — Identificado: PHP-FPM caído no nó X
- HH:MM — Restart de PHP-FPM, loja volta
- HH:MM — Monitoramento confirma checkout funcionando
## 4. Causa imediata
O que falhou tecnicamente. Exemplo: "PHP-FPM no nó X consumiu 100% da memória
após receber crawler agressivo do Bing, ficou em swap e parou de aceitar conexões."
## 5. Causa raiz
Por que isso foi possível. Exemplo: "Não havia limite de memory_limit por worker,
nem rate-limit por user-agent. Bots agressivos podem derrubar nós individuais."
## 6. O que funcionou bem
- Alerta disparou em 2min (não em 20min como semana passada).
- Plano de incidente foi seguido.
- Cliente foi notificado pela status page automaticamente.
## 7. Ações
| # | Ação | Dono | Prazo |
|---|------|------|-------|
| 1 | Adicionar memory_limit no php-fpm pool | João | YYYY-MM-DD |
| 2 | Configurar rate-limit por UA no Nginx para bots conhecidos | Maria | YYYY-MM-DD |
| 3 | Criar alerta de uso de memória > 85% por > 5min | João | YYYY-MM-DD |📌 Por que 1 página? Documento de 30 páginas não é lido. Equipe lê 1 página. A meta não é ser exaustivo — é ser acionado. Detalhes técnicos exaustivos viram anexo se realmente precisarem existir.
Causa imediata x causa raiz: a parte mais importante
Esse é o ponto onde a maioria dos post-mortems patina. Equipe escreve "PHP-FPM caiu" e fecha o documento. PHP-FPM caiu é a causa imediata, não a raiz.
| Causa imediata | Causa raiz (uma das possibilidades) | Ação |
|---|---|---|
| PHP-FPM caiu | Não havia limite de memória por worker; bot agressivo derrubou nó | Setar memory_limit; rate-limit por UA |
| Cron travado | Cron sem lock; duas instâncias rodando concorrentes | Usar flock ou supervisor com PID |
| Pedido travado em pending_payment | Webhook do gateway falhou e não havia replay automático | Implementar idempotência + replay manual com 1 clique |
| Certificado SSL expirou | Renovação manual; ninguém estava monitorando data de validade | Migrar pra Let's Encrypt com cron + alerta D-30/D-7 |
| "Plugin X quebrou em update" | Sem ambiente de staging; sem CI testando antes do deploy | Subir staging + pipeline de teste sintético no merge |
Note como a causa raiz aponta para uma melhoria de sistema, não para culpar quem fez o deploy ou esqueceu da renovação. Pessoas erram; sistemas precisam tolerar erro.
Pergunte "por quê" cinco vezes seguidas. Onde você parar é a sua causa raiz.
Sakichi Toyoda, criador da metodologia "5 Whys" (Toyota Production System)
Sobre a "reunião de post-mortem"
A reunião é opcional e curta:
- 15–20 minutos, com 3–5 pessoas (não 12).
- Documento já escrito previamente — a reunião é pra discutir, não pra escrever.
- Foco: validar causa raiz + concordar com as ações + atribuir donos.
- Tudo decidido vira ticket no mesmo dia.
Sem culpa não significa sem responsabilidade
"Blameless" não é "ninguém é responsável". Significa:
- Pessoas não são punidas por erros honestos cometidos em sistemas que não toleram erro.
- Ações têm dono. Cada item da lista tem um nome e uma data — isso é responsabilidade, não culpa.
- Aprendizados são compartilhados. O post-mortem vira leitura obrigatória do time, não punição.
⚠ Anti-padrão clássico: "vamos passar a fazer code review mais cuidadoso". Isso não é ação — é desejo. Ação é: "criar checklist de revisão de deploy em produção, com 5 itens obrigatórios, anexado em todo PR de release". Específico, com artefato, com dono.
O que fazer com os post-mortems
- Pasta única — todos os post-mortems no mesmo lugar, busca fácil. Notion, Confluence, GitHub wiki, qualquer coisa pesquisável.
- Indexar por causa raiz — quando aparece o mesmo padrão 3 vezes, é hora de uma melhoria estrutural, não pontual.
- Revisão trimestral — meia hora a cada 3 meses olhando o backlog de ações que vieram de post-mortems. Quantas foram feitas? Quais ficaram para trás?
- Compartilhe além do time — em times maiores, leitura cruzada entre devs e ops. Quem opera produto X aprende com o que aconteceu no produto Y.
Quando fazer post-mortem
- Sempre em incidente de severidade crítica ou alta.
- Sempre em qualquer queda de receita perceptível.
- Sempre em qualquer incidente onde a causa não está óbvia em 5 minutos.
- Em incidentes menores: se for a 2ª ocorrência do mesmo padrão, vale post-mortem.
✓ Próximo passo prático: abra um documento agora chamado "Post-mortems <sua-loja>". No próximo incidente, escreva 1 página nesse formato. Em 3 meses, você terá um histórico que vale mais que qualquer ferramenta de monitoramento.
Veja também os 7 alertas essenciais — alertas bons reduzem a frequência; post-mortems bons reduzem a recorrência. Os dois juntos é o que diferencia operação madura.
Referências
- John Allspaw. Blameless PostMortems and a Just Culture. Etsy Engineering Blog, 2012. etsy.com/codeascraft/blameless-postmortems
- Google SRE Workbook. Postmortem Culture: Learning from Failure, cap. 10. sre.google/workbook/postmortem-culture
- Atlassian. Postmortem Template. atlassian.com/incident-management/postmortem/templates
- PagerDuty. Postmortem Process — Open Source Documentation. postmortems.pagerduty.com
- Toyota Production System / Sakichi Toyoda. The "5 Whys" technique — origem da metodologia de causa raiz iterativa.
- Beyer et al. Site Reliability Engineering — How Google Runs Production Systems. O'Reilly, 2016, cap. 15 (Postmortem Culture).
Perguntas frequentes
- Quando devo fazer post-mortem?
- Sempre em incidente de severidade crítica ou alta. Sempre em qualquer queda de receita perceptível. Sempre quando a causa não estiver óbvia em 5 minutos. Em incidente menor, vale a partir da 2ª ocorrência do mesmo padrão.
- "Sem culpa" significa que ninguém é responsável?
- Não. Significa que pessoas não são punidas por erros honestos cometidos em sistemas que não toleram erro — mas ações têm dono e prazo (isso é responsabilidade). A diferença é o foco: melhorar sistemas em vez de culpar pessoas.
- Quantas ações por post-mortem?
- Idealmente 3-5. Mais que isso vira lista que ninguém executa. Se você está identificando 15 ações, provavelmente está misturando coisas — separe em "agora" e "depois", e foque só nas de impacto imediato.
Continue lendo
Monitore tudo isso automaticamente
A Especialista Loja Virtual roda navegação real no seu site a cada poucos minutos, alerta no Discord, Slack ou e-mail e mostra screenshot do incidente. Comece grátis.