Toda automação falha: rede cai, token expira, dado contradiz regra, destino responde tarde. A pergunta de arquitetura não é se haverá falha, mas qual estado será preservado e o que a pessoa entenderá. Fail-closed significa negar ou interromper quando os requisitos de segurança não podem ser confirmados.
Rollback, porém, não é sempre “desfazer”. Enviar mensagem pode ser irreversível; movimentar carga pode exigir uma operação compensatória. O plano deve classificar efeitos e definir recuperação antes de habilitar a ferramenta.
Em uma frase
Uma automação confiável falha de modo explícito, limita novos efeitos e oferece recuperação compatível com a realidade do processo.
O pior estado: ninguém sabe se aconteceu
Após um timeout, o sistema de origem pode ter concluído a ação. Tentar novamente sem idempotência duplica; desistir sem consultar deixa o operador no escuro. Uma mensagem “ocorreu um erro” transfere a investigação para quem menos possui acesso.
Outro antipadrão é o fallback permissivo: se a autorização não responde, executar “para não parar a operação”. Isso converte indisponibilidade de controle em autorização. Fail-closed protege consequência, mas precisa de contingência manual para não transformar segurança em abandono.
Resiliência exige limite para repetição
A AWS Well-Architected recomenda retries limitados, com backoff exponencial e jitter, e alerta que repetir todos os erros pode sobrecarregar dependências. Antes de repetir, a operação precisa ser idempotente e o cenário deve ser testado.
O livro de SRE do Google separa sintomas de causas e recomenda alertas simples, ligados a problemas reais do usuário. Para automação, “ERP respondeu 500” é causa; “ordens não estão sendo confirmadas” é o sintoma operacional que precisa de ação.
Exemplo composto: liberação durante indisponibilidade
Um agente fictício recebe pedido para liberar veículo. O serviço de permissão está indisponível. Em vez de assumir acesso, recusa a execução, preserva o pedido por prazo curto e orienta a contingência autorizada. Quando o serviço volta, não executa silenciosamente uma solicitação expirada.
Se o ERP aceita a liberação mas a confirmação se perde, a chave idempotente permite reconciliar sem duplicar. A evidência distingue estado desconhecido de falha confirmada. É um cenário de projeto, não um relato de cliente.
Desenhe recuperação por tipo de efeito
Consultas podem ser repetidas com limite. Criações precisam de idempotência. Atualizações podem usar versão ou pré-condição. Ações reversíveis recebem comando de desfazer. Ações irreversíveis exigem confirmação anterior e uma compensação explícita. Processos físicos precisam reconciliar estado digital e realidade no local.
Defina circuit breaker para evitar insistir em serviço degradado, fila com validade, dead letter para investigação e runbook para quem atende. Mensagens devem dizer o que foi recebido, o que não foi confirmado e qual próximo passo é seguro.
Exercícios antes da produção
- Desligue permissão, integração e provedor separadamente e observe o comportamento.
- Simule resposta tardia, duplicada, fora de ordem e parcialmente concluída.
- Confirme que decisões pendentes expiram e não executam após mudança de contexto.
- Pratique contingência e reconciliação com a equipe que estará no turno.
- Registre tempos de detecção, contenção, recuperação e comunicação.
Como a Uiless ajuda
A Uiless aplica permissões e readiness antes de chamar ferramentas, usa idempotência e circuit breaker nas integrações e preserva estados de execução. Se um controle essencial não responde, a ação não recebe autorização implícita.
A pessoa vê uma resposta operacional, não um stack trace. O painel oferece diagnóstico e evidência para reconciliar; a empresa mantém seus caminhos de contingência. Assim, falhar com segurança não significa esconder o problema nem abandonar o usuário.
Complete o desenho com integrações resilientes e mensagens de erro úteis.
