Feche impacto
Periodo, fluxo afetado, alcance, estado atual e evidencias principais.
Revisao pos-incidente
Depois que o sistema volta, ainda falta transformar o susto em aprendizado.
Use esta revisao para fechar incidentes com impacto real, causa confirmada, acoes preventivas e uma rotina melhor para a proxima publicacao, campanha ou falha tecnica.
Como usar
A revisao boa nao procura culpado. Ela melhora o sistema de trabalho.
O incidente pode nascer de codigo, ambiente, processo, campanha, permissao ou falta de observabilidade. A revisao conecta tudo isso a uma acao preventiva pequena e acompanhavel.
Converta em prevencao
Uma acao com dono, prazo, criterio de pronto e relacao direta com a causa.
Atualize rotina
Checklist, indicador, documento, playbook, alerta ou permissao que precisa mudar.
Roteiro de revisao
Do incidente corrigido ao aprendizado registrado.
Cada etapa ajuda a evitar o encerramento apressado: o sistema voltou, mas a causa, a prevencao e a rotina ainda precisam ficar claras.
Confirmar impacto real
Antes de encerrar o incidente, separe quem foi afetado, por quanto tempo e qual fluxo ficou comprometido.
Perguntas
- Qual pagina, API, formulario, campanha, rotina ou integracao foi afetada?
- O impacto foi indisponibilidade, lentidao, erro, perda de lead, risco de dado ou falha de rastreamento?
- Quando comecou, quando foi percebido e quando foi estabilizado?
- Houve impacto em cliente, receita, operacao interna, SEO ou AdSense?
Saida esperada
Um resumo de impacto com periodo, alcance, fluxo afetado e estado atual.
Fechar a linha do tempo
A linha do tempo evita que a revisao dependa de memoria. Ela mostra o caminho entre mudanca, sintoma, contencao e correcao.
Perguntas
- Qual foi a ultima mudanca antes do sintoma?
- Quais alertas, logs, relatos ou testes indicaram o problema?
- Que acoes foram tomadas e em que ordem?
- O que estabilizou o sistema: rollback, hotfix, configuracao, comunicacao ou contencao operacional?
Saida esperada
Uma sequencia curta com horario, evento, evidencia, acao e resultado.
Validar causa confirmada
A revisao nao deve terminar com "achamos que foi". Ela precisa separar causa provavel, causa confirmada e limites do que ainda nao se sabe.
Perguntas
- A causa confirmada explica sintoma, horario, alcance e impacto?
- Que evidencia descarta hipoteses alternativas?
- A correcao removeu a causa ou apenas reduziu o sintoma?
- Existe risco parecido em outra rota, pagina, campanha, ambiente ou integracao?
Saida esperada
Uma causa confirmada, hipoteses descartadas e lacunas que ainda precisam de acompanhamento.
Definir acoes preventivas pequenas
Boa acao preventiva tem dono, prazo, criterio de pronto e relacao direta com a causa. Ela nao precisa virar um projeto enorme.
Perguntas
- Qual acao teria detectado o problema mais cedo?
- Qual acao reduziria o impacto se o problema voltasse?
- Qual checklist, teste, log, alerta, documento ou permissao precisa mudar?
- Quem fica responsavel e quando a acao sera revisada?
Saida esperada
Uma lista curta de acoes com dono, prazo, motivo e evidencia esperada.
Comunicar o aprendizado sem culpar pessoas
A revisao deve melhorar o sistema de trabalho. Culpa individual costuma esconder causas de processo, ambiente, ferramenta e documentacao.
Perguntas
- Quem precisa saber o que mudou?
- Qual linguagem e adequada para area tecnica, comercial ou gestao?
- O que foi corrigido e o que ainda sera acompanhado?
- O aprendizado precisa virar documento, treinamento, tarefa ou rotina?
Saida esperada
Uma comunicacao objetiva com causa, impacto, correcao, prevencao e proximos passos.
Atualizar a rotina tecnica
Se o incidente nao muda nada na rotina, ele provavelmente vai voltar com outro nome.
Perguntas
- A rotina semanal, mensal, pos-deploy ou pos-incidente precisa mudar?
- Existe novo indicador a acompanhar?
- Alguma pagina, formulario, tag, DNS, backup ou permissao precisa entrar no checklist?
- O que sera revisado no proximo ciclo?
Saida esperada
Uma mudanca explicita na rotina, checklist, indicador, documento ou playbook.
Acoes preventivas
A prevencao precisa tocar o lugar certo.
Nem todo incidente pede mais servidor ou reescrita. Muitas vezes a melhoria certa esta em log, checklist, rollback, permissao, tag, backup ou documentacao.
Observabilidade e alerta
Quando o problema demorou a ser percebido ou os logs nao explicavam a rota, horario, tempo, usuario tecnico ou etapa afetada.
Acoes possiveis
- Adicionar log orientado a investigacao no fluxo afetado
- Registrar indicador simples antes e depois da correcao
- Criar alerta ou verificacao manual na rotina semanal
Evidencias de conclusao
- Log com contexto
- indicador acompanhado
- criterio de alerta
- rota validada
Deploy, validacao e rollback
Quando o incidente surgiu depois de publicacao, troca de configuracao, rota nova, proxy, DNS, build ou migracao.
Acoes possiveis
- Adicionar o cenario ao checklist pos-deploy
- Registrar rollback testavel antes da proxima mudanca parecida
- Validar rotas publicas, arquivos tecnicos, formulario e logs apos publicacao
Evidencias de conclusao
- Checklist atualizado
- rotas testadas
- rollback documentado
- commit publicado
Dados, backup e restauracao
Quando o incidente envolveu banco, migracao, dado historico, exclusao, anexo, integracao ou incerteza sobre restauracao.
Acoes possiveis
- Confirmar escopo real do backup
- Testar restauracao em ambiente controlado quando possivel
- Registrar dados historicos que precisam ser considerados em novas regras
Evidencias de conclusao
- Backup localizado
- restauracao testada
- schema revisado
- dados mascarados usados no teste
Seguranca, acesso e segredo
Quando a causa envolveu senha, token, permissao ampla, usuario compartilhado, dado sensivel, IA ou automacao sem limite claro.
Acoes possiveis
- Rotacionar segredo quando houver exposicao
- Revisar usuarios e permissoes necessarias
- Documentar fonte, permissao e revisao humana em fluxos com IA
Evidencias de conclusao
- Segredo rotacionado
- permissao revisada
- fonte registrada
- teste de acesso
Conteudo, monetizacao e rastreamento
Quando o incidente envolveu formulario, UTM, Google Ads, tag, sitemap, pagina sem indexacao, AdSense ou conteudo publicado sem descoberta.
Acoes possiveis
- Testar formulario com UTM real ou simulada
- Validar Tag Assistant, Search Console, sitemap e busca interna
- Adicionar pagina nova aos caminhos de descoberta antes de pedir revisao
Evidencias de conclusao
- Contato recebido
- UTM preservada
- tag disparada
- rota no sitemap
- link interno validado
Documentacao e continuidade
Quando a solucao dependeu de uma pessoa especifica, memoria informal, conversa antiga ou comando nao documentado.
Acoes possiveis
- Registrar comando, rota, variavel, decisao ou fluxo critico
- Transformar aprendizado em modelo reutilizavel
- Definir onde essa informacao sera atualizada nos proximos ciclos
Evidencias de conclusao
- Documento atualizado
- modelo preenchido
- responsavel definido
- rotina revisada
Perguntas comuns
Encerrar incidente nao e esquecer o incidente.
Uma revisao curta, feita com calma, costuma ser suficiente para melhorar o proximo deploy, a proxima campanha e a proxima investigacao.
Toda falha precisa de revisao pos-incidente?
Nao. Falhas pequenas podem receber uma revisao curta. Incidentes com impacto em usuario, receita, dados, deploy, seguranca ou campanhas merecem registro mais cuidadoso.
A revisao deve acontecer antes ou depois da causa raiz?
Depois da contencao e junto da analise de causa raiz. A revisao usa a causa confirmada para decidir acoes preventivas e atualizar a rotina.
Como evitar que a revisao vire culpa?
Foque em sistema de trabalho: evidencias, processo, validacao, documentacao, permissao, automacao e rotina. O objetivo e melhorar o proximo ciclo.