Resposta direta
Um incidente se diagnostica reduzindo o escopo antes de procurar culpado: fixar o horário exato do desvio, listar o que mudou nas horas anteriores e testar uma hipótese por vez. A causa raramente está no ponto onde o erro apareceu; costuma estar no dado de entrada, na regra de negócio alterada ou numa permissão concedida antes. O objetivo do diagnóstico não é encontrar quem errou, e sim chegar a uma afirmação verificável, com evidência anexada, que permita decidir entre corrigir, interromper ou conviver com o desvio.
- Objetivo
- Diagnosticar
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata o incidente como apuração de causa, não como registro nem como parada de emergência.
O desvio aparece antes do erro
Boa parte do tempo de apuração se perde olhando o ponto onde a falha ficou visível. Esse ponto costuma ser a última consequência de uma sequência: um cadastro alterado, um campo vazio aceito na origem, uma regra publicada sem revisão. O trabalho é reconstruir a ordem dos fatos, não a ordem das queixas.
Uma linha do tempo útil registra três coisas por evento: horário, quem ou o que mudou, e qual verificação existia naquele momento. Sem isso, a discussão vira opinião sobre qual área errou primeiro.
Testar uma hipótese por vez
Apuar várias causas possíveis em paralelo costuma produzir conclusão frágil. Cada hipótese precisa de um teste que possa derrubá-la, usando o dado exato que estava em execução. Se o teste não distingue uma hipótese da outra, ele não serve para decidir nada.
O resultado esperado do diagnóstico é uma frase verificável, com evidência anexada, e não um relato. Enquanto a conclusão não permitir escolher entre corrigir, interromper ou conviver, a apuração continua aberta.
Quando a apuração não chega a uma causa
Existem incidentes em que a evidência disponível não permite afirmar causa. Isso ocorre quando o registro foi sobrescrito, quando o dado de entrada foi descartado ou quando a falha depende de condição externa que não se repete. Nesses casos, o correto é declarar o limite e registrar a lacuna, não escolher um culpado por conveniência.
Também há incidentes cuja causa é conhecida e cujo custo de corrigir supera o de conviver com o desvio. A apuração deve produzir essa comparação quando possível, ou dizer o que precisaria ser medido para que a decisão fosse tomada.
Recurso prático
Perguntas que separam sintoma de causa
| Pergunta de apuração | O que a resposta indica |
|---|---|
| O desvio começou no mesmo instante em que algo mudou? | Se sim, a mudança recente é o primeiro caminho a testar; se não, a causa é anterior ao sintoma e precisa ser buscada mais atrás. |
| O mesmo erro aparece em outras execuções com o mesmo dado? | Se sim, o problema está no dado ou na regra; se não, o problema está no ambiente daquela execução específica. |
| A execução falhou antes ou depois de gravar o resultado? | Isso define se o trabalho é reconstituir o dado ou repetir a etapa, e muda quem precisa ser acionado. |
O erro mais comum é aceitar a primeira explicação plausível e encerrar a apuração antes de reproduzir o desvio com dado controlado.
Sobre o que está escrito aqui
Conceitos relacionados: linha do tempo do incidente · hipótese de causa · evidência de execução · ponto de mudança · critério de encerramento. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Workshop executivo, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Governança e controle de automação — Página central do tema
- Ações sem aprovação: onde colocar o freio na… — ações sem aprovação
- Automação que continua após erro: como defini… — automação que continua após erro
Páginas relacionadas
O mesmo problema em outro objetivo
- Incidentes parecidos: como decidir qual vem primeiro — Comparar alternativas
- Incidentes de automação: medir sem inflar nem esconder — Explicar medição
- Incidente de automação: como montar a resposta na hora — Orientar implementação
- Incidentes de automação: o que fixar na contratação — Orientar avaliação e contratação
Outras leituras em Governança e controle de automação
- Falha de automação: separar causa de coincidência — Roteiro para conduzir a análise de causa de uma falha de automação: o que coletar, quem decide e onde a investigação para.
- Incidente repetido: como chegar à causa, não ao culpado — Etapas para separar sintoma, gatilho e condição de causa em incidentes de automação, com dono da correção e critério de encerramento.
- Alerta duplicado: consolidar sem perder o aviso — Regra de consolidação de alertas duplicados: chave de agrupamento, dono do registro e critério de encerramento, com o que medir.
- Falha que volta: separar causa de sintoma — Critério para separar contorno de correção em falhas que se repetem, com registro único por causa, responsável definido e peso para priorizar o tratamento.
- Envio indevido de dados: como contratar a resposta — O que avaliar e o que fixar em contrato quando o risco é envio indevido de dados por automação, e o que essa cobertura não alcança.