Resposta direta
A resposta é comparar dois estados: o que foi aprovado e o que está rodando. A diferença entre eles é o objeto do diagnóstico. Isso exige três registros mínimos: a versão aprovada do fluxo ou da configuração, o artefato que está em produção e o horário em que foi publicado. Sem a versão aprovada guardada, a comparação não tem referência e a investigação vira reconstrução de memória. Com o horário da publicação e a credencial usada, o conjunto de pessoas que podiam alterar naquela janela fica restrito o suficiente para ser verificado.
- Objetivo
- Diagnosticar
- Formato indicado
- Workshop executivo
- Atualizado em
O que esta página acrescenta: Trata a divergência entre o que foi aprovado e o que está rodando como objeto de diagnóstico, com o que comparar em cada sinal e onde a alteração deixa rastro.
O que forma a linha de base
O diagnóstico começa por um registro que quase nunca existe: a versão que foi aprovada, com data e responsável. Esse registro pode estar no sistema de chamados, no repositório de configuração ou em um documento de controle, desde que seja o mesmo usado na publicação. O que importa é que a versão aprovada seja identificável e recuperável depois.
Com a linha de base definida, a comparação deixa de ser opinião. Compara-se o artefato em produção com o aprovado, a configuração vigente com a registrada e o horário da publicação com a janela autorizada. Cada divergência encontrada aponta para um ponto do processo: aprovação, publicação ou permissão de edição.
Onde a alteração costuma deixar rastro
Toda alteração deixa algum registro, mesmo quando feita fora do processo. O rastro pode estar no log de publicação do próprio ambiente, na fila de chamados do período, na credencial que executou a mudança ou na janela em que o ambiente estava liberado. Procurar o rastro é mais produtivo do que procurar culpado.
A ausência de rastro também é resultado. Se uma alteração ocorreu e não há log, chamado nem credencial identificável, o problema está no controle de acesso e não apenas na mudança. Esse achado é o que separa um incidente isolado de uma falha de governança.
O que a comparação não resolve
Comparar estados mostra o que mudou, não por que mudou. A intenção por trás da alteração, se houve erro ou decisão, não está na diferença entre os dois estados. O método também não distingue mudança feita por uma pessoa de alteração automática da própria plataforma, quando o registro das duas usa o mesmo canal.
Em ambientes sem linha de base, o método não se aplica: sem versão aprovada guardada, não há o que comparar. Nesse caso, o trabalho é montar o registro antes de investigar. A comparação também não substitui o processo de mudança nem estabelece responsabilidade; ela apenas reduz o intervalo de onde a resposta pode estar.
Recurso prático
Sinais de alteração e o que comparar
| Sinal observado | O que comparar para localizar a mudança |
|---|---|
| Comportamento diferente no mesmo fluxo | Versão do artefato em produção contra a última versão aprovada, com data e responsável pela publicação |
| Parâmetro que ninguém lembra de ter alterado | Configuração vigente contra o registro da última mudança aprovada, incluindo quem tinha permissão de editar |
| Alteração aplicada direto no ambiente | Horário da publicação contra a janela de mudança autorizada e contra a fila de chamados do período |
O erro mais comum é partir para a identificação de autoria antes de fechar a linha de base. Sem saber o que estava aprovado, toda diferença vira suspeita e o diagnóstico não chega a uma conclusão.
Sobre o que está escrito aqui
Conceitos relacionados: versão aprovada · configuração em produção · trilha de alteração · janela de mudança · comparação de estado. 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
- Logs de automação: o mínimo necessário para r… — ausência de registros
- Acessos excessivos: como reduzir sem travar o… — acessos excessivos
Páginas relacionadas
O mesmo problema em outro objetivo
- Mudança em produção fora do processo: onde ela nasce — Organizar um processo
- Mudança em produção sem aviso: como comparar o que mudou — Comparar alternativas
- Mudança em produção sem aviso: como medir a alteração — Explicar medição
- Mudança em produção sem aviso: tornar a alteração visível — Orientar implementação
- Mudança em produção sem aviso: o que definir no contrato — Orientar avaliação e contratação
Outras leituras em Governança e controle de automação
- Correção aplicada sem registro: como medir o que mudou — Critério para medir correção aplicada sem registro do que mudou: o que comparar, o que reconstituir e o que a medição não alcança.
- Leitura usada para escrita: comparar arranjos e seus limites — Compara quatro arranjos de credencial para escrita, com custo de manutenção, latência, rastreabilidade e o que cada um deixa em aberto.
- Fluxo sem responsável: onde registrar a manutenção — Descreve onde registrar o responsável pela manutenção de cada automação, o que essa pessoa decide e o que fazer quando ela sai da equipe.
- Fornecedor em operação: como integrar sem perder controle — O que definir para um fornecedor de automação entrar em operação: acessos, responsabilidade, limites de atuação, registro e critérios de revisão.
- Automação sem código-fonte: o que dá para controlar — Descreve como registrar comportamento, dependências e responsáveis de uma automação sem código acessível, e onde esse arranjo deixa de servir.