Resposta direta
A resposta é separar contenção de explicação. Nas primeiras horas, o objetivo não é descobrir a causa, e sim reduzir o alcance do incidente e registrar o que se sabe com data e responsável. Isso exige três decisões: parar ou restringir a automação, delimitar quais registros e áreas foram afetados e nomear quem responde por cada frente. A causa pode ficar para depois. Sem essa separação, a equipe discute hipóteses enquanto o efeito continua se espalhando, e o registro do incidente nasce contaminado por conclusões prematuras.
- Objetivo
- Diagnosticar
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata o intervalo entre o incidente e a análise de causa, com critérios de contenção e escopo em vez de investigação causal.
Contenção e explicação são decisões diferentes
Contenção é reduzir o alcance do efeito. Explicação é entender o mecanismo que o produziu. As duas usam os mesmos fatos, mas têm prazos e responsáveis distintos. Misturar as duas faz a equipe esperar pela causa para agir, e a causa raramente chega no tempo da operação.
Na prática, a primeira decisão é se a automação para, se continua restrita a um subconjunto ou se segue com acompanhamento. Quem autoriza precisa estar nomeado antes do incidente, não durante. Sem nome definido, a decisão fica com quem estiver disponível, e o critério vira opinião.
Escopo a partir do que já está registrado
O escopo do incidente se delimita com o que existe de registro: execuções, horários, dados alterados, mensagens enviadas, acessos usados. Quando o registro é insuficiente, o escopo fica maior por precaução, e essa escolha precisa ficar declarada.
A linha do tempo separa três momentos: quando o efeito começou, quando foi percebido e quando houve decisão. Essa separação mostra onde o tempo foi gasto. Em muitos casos a causa segue desconhecida, mas o intervalo entre percepção e decisão já explica parte do dano.
O que essa abordagem não resolve
Conter sem causa não substitui a análise de causa. Ela continua necessária para verificar se o mesmo mecanismo pode voltar. Sem essa etapa, o incidente fica tratado apenas no efeito e permanece disponível para repetir.
Também não se aplica quando há risco a pessoas, ao ambiente ou obrigação regulatória com prazo definido, situações em que a escala de decisão é outra. E não serve para incidentes provocados por terceiro fora do controle da operação, em que a contenção depende de quem opera o sistema.
Recurso prático
Contenção antes da causa
- Fechar o alcance: listar o que a automação tocou desde a última execução considerada correta até o momento em que o efeito foi percebido.
- Decidir a interrupção: parar, restringir a um subconjunto ou manter com acompanhamento, com o nome de quem autoriza cada opção.
- Fixar a linha do tempo: horário do efeito, da detecção e da decisão, sem atribuir motivo a nenhum deles.
- Delimitar o que não se sabe: registrar as hipóteses descartadas e o que falta verificar, com quem verifica.
- Abrir a análise de causa somente depois da contenção, com escopo definido pelo que a contenção revelou.
O erro mais comum é tratar a primeira hipótese plausível como causa e aliviar a contenção cedo. Hipótese não delimita alcance: o escopo sai de registros e execuções, não de uma explicação ainda não verificada.
Conceitos usados nesta página
- Registro de decisão — Registro de decisão é o registro mínimo do que foi decidido, por quem, com qual premissa e a partir de quando — o que permite reconstruir a escolha depois, sem depender da memória de quem estava na sala.
Sobre o que está escrito aqui
Conceitos relacionados: contenção · escopo do incidente · linha do tempo · registro de decisão · responsável pela interrupção. 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
- Privilégios de automação: como medir o excess… — acessos excessivos
- Acesso excessivo de fornecedor: como avaliar… — acessos excessivos
Páginas relacionadas
O mesmo problema em outro objetivo
- Incidente sem causa identificada: o que decidir mesmo assim — Organizar um processo
- Incidente sem causa apurada: comparar respostas possíveis — Comparar alternativas
- Incidente sem causa raiz: como medir mesmo assim — Explicar medição
- Incidente sem análise de causa: o que decidir e registrar — Orientar implementação
- Incidente sem causa: o que exigir antes de contratar — Orientar avaliação e contratação
Outras leituras em Governança e controle de automação
- Aprovações que viram carimbo: como diagnosticar — O que uma aprovação de automação deveria registrar para ser decisão, e os sinais de que o processo apenas formaliza o que já está em produção.
- Falha que segue rodando: o que medir na automação — Como separar execução normal de execução que seguiu após um erro: o que medir, quem interrompeu, com que critério e o que isso não resolve.
- Liberação por mensagem: como registrar sem travar a operação — Como definir quem pode liberar, o que exatamente fica autorizado, por quanto tempo e onde a decisão é registrada, incluindo os limites do registro.
- Falha recorrente sem causa tratada: comparar respostas — Compara três caminhos para falha recorrente sem causa tratada: conter de novo, isolar a causa ou redesenhar o controle. Mostra custo e limite de cada um.
- Aprovações paradas: o que medir na fila da automação — O que medir para acompanhar aprovações na automação: espera, volume represado, aprovador, decisão e o que cada registro permite comparar.