Gravar post-mortems de incidentes: transformar falhas em conhecimento de equipe

Toda equipe escreve um documento de post-mortem depois de uma queda. Bem menos equipes leem esse documento. Uma linha do tempo bem redigida, cheia de links de dashboards e trechos de log, pede que quem lê reconstrua o incidente na própria cabeça — e a maioria passa os olhos, concorda e segue em frente.

Uma gravação de tela curta muda isso. Em vez de descrever como estava o gráfico de erros às 02:14, você mostra. Em vez de explicar qual consulta revelou a causa raiz, você executa. Neste guia você vai aprender a gravar post-mortems que as pessoas de fato assistem e a mantê-los úteis meses depois.

Por que gravar um post-mortem

• Evidência supera descrição: gráficos, traces e logs são visuais por natureza — capturas de tela perdem o movimento antes/depois que torna um pico óbvio
• Mais rápido de produzir: narrar o que já está aberto na sua tela leva menos tempo do que escrever um texto caprichado
• Melhor para quem acabou de chegar: seis minutos de retrospectiva ensinam os modos de falha do sistema muito mais rápido que uma página de wiki
• Preserva o raciocínio: documentos registram o que aconteceu; gravações capturam por que quem respondeu pensou daquele jeito em cada etapa
• Funciona no assíncrono: equipes distribuídas absorvem a revisão sem marcar mais uma reunião entre fusos

O que gravar — e o que deixar de fora

Um post-mortem gravado não é o replay do incidente inteiro. Fique nas partes em que ver vale mais do que ler:

Grave isto:

• O momento da detecção — o alerta, o dashboard, o primeiro relato de usuário
• O gráfico principal mostrando o impacto ao longo da janela do incidente
• Os passos de investigação que estreitaram o cerco (inclusive os becos sem saída)
• O código, a configuração ou a consulta exata que causou a falha
• A aplicação da correção e a recuperação das métricas

Pule isto:

• Longos trechos esperando deploys ou dados carregarem
• Conversas internas sem relação com o diagnóstico
• Qualquer coisa que caiba em uma frase de narração

Preparação antes de apertar Gravar

Ferramentas de incidente exibem muita coisa que você não quer em um vídeo compartilhado. Reserve cinco minutos:

1. Abra todas as abas antes: dashboards no intervalo de tempo certo, a consulta de log relevante, o pull request, o alerta
2. Fixe os intervalos de tempo: trave os dashboards na janela do incidente para que todos vejam o mesmo que você
3. Feche telas sensíveis: registros de clientes, tickets internos com dados pessoais, mensagens privadas, gerenciadores de credenciais
4. Silencie notificações: nada derruba um post-mortem sério como um lembrete de almoço no meio da narração
5. Escreva um roteiro de três linhas: impacto, causa raiz, prevenção. Todo o resto se apoia nesses três pontos

Use captura de janela em vez de tela cheia quando o dashboard estiver em uma única janela do navegador — é a forma mais simples de garantir que nada mais apareça no quadro.

Uma estrutura que funciona

Mantenha a gravação entre cinco e dez minutos. Uma estrutura confiável:

1. Impacto primeiro (30 segundos): quem foi afetado, por quanto tempo e com que gravidade. Comece por aqui — é o que a maioria veio saber
2. Percurso da linha do tempo (2–3 minutos): detecção, escalonamento, mitigação e resolução, mostrados no dashboard real
3. Causa raiz (2–3 minutos): mostre o caminho de código, a mudança de configuração ou a consulta reais. Dê zoom nas linhas específicas
4. O que dificultou (1 minuto): alertas ausentes, logs confusos, responsabilidades indefinidas — justamente o que o documento costuma achatar
5. Itens de ação (1 minuto): diga cada um em voz alta com o responsável e depois linke na descrição

Use o editor para deixar legível

Material bruto de incidente é denso. O editor do Recorded transforma isso em algo fácil de acompanhar:

• Efeitos de zoom: dashboards e linhas de log são pequenos. Amplie o pico, a mensagem de erro, o diff problemático — ninguém deveria apertar os olhos
• Regiões de velocidade: acelere pipelines de deploy e execução de consultas e volte à velocidade normal quando a causa raiz aparecer
• Sobreposições de texto: carimbe horários (02:14 UTC — primeiro alerta) para que o vídeo converse com o documento
• Corte: remova a largada falsa em que você percebeu que o dashboard estava no intervalo errado
• Efeitos de cursor: destaque os cliques ao demonstrar o caminho exato de reprodução

Use a webcam só na abertura e no encerramento. Um rosto ajuda no tom ao falar de impacto e ações; durante a análise de logs, ele só cobre o terminal.

Manter o tom sem culpados diante da câmera

Vídeo carrega tom de um jeito que o texto não carrega. A mesma frase soa como análise ou como acusação dependendo da entrega.

• Diga “o deploy introduziu” em vez de apontar quem publicou
• Narre decisões no contexto disponível na hora: “neste ponto ainda não tínhamos a métrica de profundidade da fila”
• Mostre os becos sem saída sem pedir desculpas — eles provam que o sistema era difícil de diagnosticar, e isso já é um item de ação
• Regrave a introdução se a primeira tomada soar irritada. São dois minutos e definem o tom para todo mundo que assistir

Combinando vídeo e documento

A gravação complementa o documento de post-mortem, não o substitui. Documentos são pesquisáveis, linkáveis e fáceis de escanear; vídeo não é.

Uma boa combinação:

• O documento continua sendo a fonte de verdade para linha do tempo, ações e responsáveis
• A gravação fica incorporada no topo, com uma linha resumindo o que ela cobre
• Marcações de capítulo na descrição levam direto à seção de causa raiz
• Itens de ação moram no seu rastreador, não só no vídeo

Construindo uma biblioteca de incidentes

Gravações isoladas são úteis. Uma coleção vale muito mais.

• Nomeie de forma consistente: 2026-09-28-checkout-latency-postmortem ordena e busca sem dor de cabeça
• Marque por sistema: agrupe pelo serviço envolvido para entregar de uma vez tudo sobre um componente a quem entra de plantão
• Revise trimestralmente: assistir às gravações do trimestre de uma vez faz os padrões de falha recorrentes saltarem aos olhos
• Use no onboarding: três ou quatro incidentes selecionados são o caminho mais rápido para ensinar como o sistema realmente quebra

Erros comuns

• Gravar durante o incidente: foque primeiro na mitigação. A revisão se grava depois, quando dá para narrar com calma
• Compartilhar material bruto: 40 minutos de tela compartilhada sem edição não é um post-mortem — ninguém assiste
• Vazar dados de clientes: assista à gravação inteira antes de compartilhar, procurando dados pessoais em logs e dashboards
• Pular o resumo de impacto: quem assiste só ao primeiro minuto ainda precisa sair sabendo o essencial
• Deixar substituir o documento: daqui a seis meses, quando um incidente parecido começar, não dá para pesquisar dentro de um vídeo

Conclusão

Post-mortems falham quando são escritos para serem arquivados, não compreendidos. Uma gravação de tela focada — impacto na frente, evidência real na tela, narração sem culpados e ações claras — transforma cada queda em algo que a equipe inteira aprende em dez minutos.

Grave o próximo post-mortem em vez de apenas escrevê-lo e veja quantas pessoas a mais se envolvem.