Operação segura: executar, diagnosticar e recuperar

Uma operação confiável exige conhecer o contexto autorizado, a versão executada e o estado real das dependências. Esta guia organiza a preparação do intento, a investigação de falhas, a migração de referências e a retirada de um worker. Uma ação administrativa deve ser feita com o papel adequado e evidência suficiente para distinguir solicitação aceita de alteração confirmada.

Identidade, tenant e permissões

Confira o tenant e o papel ativos antes de editar ou executar. A mesma conta pode enxergar objetos diferentes ao trocar de contexto. Separe laboratório e produção e escolha nomes reconhecíveis; nomes parecidos não comprovam que identificador e versão sejam os mesmos.

Em Roles and permissions, atribua apenas as capacidades necessárias. Leitura do Monitor, edição de definições, publicação, execução e administração de infraestrutura são responsabilidades distintas. Se uma opção não aparecer, confira permissões, contexto e estado do objeto. Não tente contornar uma rejeição chamando um endpoint administrativo diretamente.

Mantenha conexões e API keys nos mecanismos próprios. Não coloque credenciais em variáveis de exemplo, arquivos, capturas ou incidentes. Uma chave pessoal identifica uma automação, mas não concede poderes administrativos adicionais. Revogue chaves temporárias quando não forem mais necessárias em Developer Tools.

Preparar uma execução observável

Confira Mapping, Session e Workflow publicados, suas versões e os bindings. Verifique destinos, worker, capacidades e slots. Determine o efeito de enviar os mesmos dados novamente antes de gravar em um destino externo. Uma operação de infraestrutura idempotente não torna automaticamente idempotente a carga de dados.

Registre o identificador do intento e acompanhe Monitor. Distinga fila, atividade e estado terminal. Guarde overrides não sensíveis e os registros necessários. Compare o arquivo ou a tabela com uma regra independente: sucesso técnico não substitui aceitação do esquema, quantidade, valores e regras de negócio.

Diagnosticar antes de recuperar

Localize a primeira tarefa com erro, sua mensagem e o último estado confirmado. Classifique a causa: desenho inválido, entrada indisponível, autorização, credencial, capacidade, dependência ou provedor. Repetir não corrige um caminho incorreto ou uma permissão ausente.

As ações disponíveis dependem do estado e da autorização:

• Cancel: solicita cancelamento de um Workflow em fila.
• Terminate: solicita o encerramento de uma execução ativa; confira o resultado posterior e os efeitos parciais.
• Re-run: inicia outro intento desde o começo com a entrada armazenada e a definição fixada.
• Recover: retoma tarefas falhas ou canceladas a partir do ponto de recuperação disponível; confira a política e o checkpoint real.

Essas ações não são sinônimos. Um timeout do navegador ou cliente não comprova cancelamento no servidor. Antes de repetir, confira arquivos, transações já confirmadas e risco de duplicidade. Um checkpoint não desfaz automaticamente todas as gravações externas anteriores. Se houver ambiguidade, preserve o identificador e esclareça o estado do destino antes do próximo intento.

Migrar referências de um worker

Em Cloud workers, diferencie a política de agendamento do runtime e o estado da VM. Pause scheduling interrompe novas atribuições conforme o fluxo disponível; não equivale a desligar a VM. Confira trabalhos ativos e dependências. Drain permite terminar trabalho ativo sem aceitar novas atribuições quando essa opção estiver disponível.

Use Reassign references para selecionar origem, destino e referências, revisar o plano e aplicar somente uma migração válida. Backups de dependências ajudam a revisar ou restaurar referências pelos controles disponíveis. A operação altera metadados de afinidade e dependências; não copia arquivos, discos, bancos nem credenciais externas. O destino precisa conseguir acessar os recursos das tarefas migradas.

Prepare replacement abre o fluxo de preparação de outro worker. O anterior permanece até sua retirada explícita. Antes de transferir trabalho, confirme compatibilidade, permissões, rede e capacidade do novo runtime. Criar infraestrutura e reatribuir referências são etapas distintas.

Retirar sem perder o controle do recurso

Abra o diálogo de deprovision e revise recursos cloud, referências Dova, execuções e bloqueios. Refresh impact consulta o estado atualizado. Unavailable no provedor não comprova que a VM tenha sido removida; investigue o acesso antes de limpar o registro.

Quando permitido, Stop and deprovision exige uma confirmação explícita das duas ações. O fluxo solicita a parada e consulta novamente o impacto; só pede a exclusão se o servidor a permitir. O provedor pode continuar em estado de parada pendente. Nesse caso, consulte novamente mais tarde, sem presumir conclusão.

Se o provedor falhar, o registro fica disponível para investigação e nova tentativa. Quando a ausência da VM estiver confirmada, Clean up Dova record informa que apenas o registro ativo será limpo. Confira inventário e Audit. Registre o que foi confirmado, o que continua pendente e quem deve resolver. Uma solicitação enviada não é uma retirada concluída.