Automação não é fazer um robô funcionar — é fazer ele sobreviver à produção

No começo, o objetivo costuma parecer simples: fazer a automação funcionar.

Você desenvolve o fluxo, testa alguns cenários, executa novamente e tudo acontece como esperado. O sistema abre, os dados são processados, a informação chega ao destino e a execução termina sem erro.

Nesse momento, é fácil pensar que a maior parte do trabalho está pronta.

Mas colocar uma automação em produção muda completamente o problema.

Depois de algum tempo trabalhando com automações reais, percebi que existe uma diferença muito grande entre uma automação que funciona e uma automação que está realmente preparada para produção.

Fazer o processo executar é apenas a primeira etapa.

O cenário perfeito quase nunca existe em produção

Durante o desenvolvimento, normalmente trabalhamos com um conjunto relativamente controlado de situações.

A planilha está no lugar esperado.

A API responde.

O sistema está disponível.

Os campos possuem os valores previstos.

A tela continua exatamente como estava quando a automação foi criada.

Em produção, essas premissas começam a falhar.

Um arquivo pode estar bloqueado por outro usuário.

Uma requisição pode retornar timeout.

Uma aplicação pode carregar mais lentamente do que o normal.

Um dado obrigatório pode chegar vazio.

Uma página pode mudar.

Uma credencial pode expirar.

Um registro pode já ter sido processado anteriormente.

Nenhuma dessas situações significa necessariamente que a automação foi mal desenvolvida.

O problema começa quando ela não sabe o que fazer quando algo assim acontece.

É nesse ponto que o desenvolvimento deixa de ser apenas sobre o caminho feliz.

Uma boa automação precisa saber falhar

Uma das maiores mudanças na minha forma de desenvolver automações foi começar a pensar no erro como parte do fluxo.

Não como uma exceção improvável.

Como parte normal do sistema.

Se uma automação processa centenas de registros, eventualmente algum deles terá um problema.

A pergunta não deveria ser apenas:

Como evitar que aconteça um erro?

A pergunta mais importante é:

O que a automação deve fazer quando o erro acontecer?

Em alguns casos, a resposta pode ser tentar novamente.

Em outros, registrar a ocorrência e seguir para o próximo item.

Em determinadas situações, a execução inteira precisa ser interrompida.

E existem erros que nem deveriam ser considerados falhas técnicas.

Erro de negócio não é a mesma coisa que erro de aplicação

Essa distinção é especialmente importante em automações transacionais.

Imagine que um processo recebe um registro que não atende a uma regra obrigatória.

Tecnicamente, a automação pode estar funcionando perfeitamente.

A aplicação está disponível.

A conexão está funcionando.

O código não lançou nenhuma exceção.

Mas aquele item específico não pode ser processado.

Esse é um problema diferente de uma indisponibilidade de sistema, timeout ou falha de autenticação.

Quando todos os erros são tratados da mesma maneira, a sustentação fica muito mais difícil.

Uma automação madura precisa conseguir diferenciar, por exemplo:

• problemas nos dados;
• regras de negócio não atendidas;
• falhas temporárias;
• indisponibilidade externa;
• erros inesperados da aplicação;
• problemas internos da própria automação.

Essa classificação melhora o tratamento, os logs e principalmente a capacidade de entender o que realmente aconteceu.

Retry não é solução para tudo

Quando ocorre uma falha, uma das primeiras soluções que costuma aparecer é:

“Tenta de novo.”

E em muitos casos isso faz sentido.

Timeouts, falhas temporárias de rede e indisponibilidades momentâneas podem desaparecer em uma nova tentativa.

Mas retry também pode mascarar problemas.

Se um campo obrigatório está vazio, repetir a operação cinco vezes não vai fazer o valor aparecer.

Se uma regra de negócio impede o processamento, dez novas tentativas continuarão produzindo o mesmo resultado.

Se a automação está enviando uma requisição que pode gerar duplicidade, repetir sem nenhum controle pode até piorar a situação.

Por isso, retry precisa ter contexto.

Antes de repetir uma operação, é importante entender:

• a falha é temporária?
• a operação pode ser repetida com segurança?
• existe risco de duplicidade?
• há um limite de tentativas?
• o intervalo entre as tentativas faz sentido?
• o erro deveria ser tratado de outra maneira?

Retry é uma ferramenta de resiliência.

Não deveria ser um substituto para entendimento do problema.

Logs não servem apenas para dizer que deu erro

Uma automação pode ter dezenas de logs e ainda assim ser difícil de sustentar.

Mensagens como:

Erro no processamento

ou:

Falha inesperada

informam muito pouco.

Quando algo falha em produção, quem está analisando precisa conseguir reconstruir o que aconteceu.

Um log útil deve responder perguntas como:

• qual execução estava ocorrendo?
• qual item estava sendo processado?
• em qual etapa aconteceu o problema?
• qual sistema estava envolvido?
• qual foi a resposta recebida?
• houve tentativa anterior?
• o item poderá ser reprocessado?

Isso muda completamente a investigação.

Em vez de tentar reproduzir o erro sem contexto, é possível começar a análise com informações concretas.

Para mim, observabilidade deixou de ser algo adicional e passou a fazer parte do próprio desenho da automação.

O identificador da transação é mais importante do que parece

Em processos com muitos itens, saber apenas que uma execução falhou não é suficiente.

É necessário saber qual transação falhou.

Por isso, sempre que possível, é importante trabalhar com algum identificador que permita rastrear o item durante todo o processo.

Pode ser:

• um ID do sistema de origem;
• número de solicitação;
• identificador interno;
• chave de uma fila;
• outro valor que represente aquela transação de forma consistente.

Esse identificador pode aparecer nos logs, no monitoramento e nos registros de erro.

Quando um usuário informa que determinada solicitação não foi processada, fica muito mais fácil localizar exatamente o que aconteceu.

Configuração não deveria estar espalhada pelo código

Outro aprendizado que aparece rapidamente em produção é o custo de deixar configurações fixas dentro da automação.

URLs.

Caminhos de arquivos.

E-mails.

Timeouts.

Nomes de filas.

Parâmetros de ambiente.

Esses valores mudam.

E quando estão espalhados pelo código, qualquer alteração pode exigir uma nova versão da automação.

Separar configuração de lógica torna a solução mais fácil de manter.

O mesmo vale para credenciais.

Senha não deveria estar dentro de código, planilha de configuração ou arquivo versionado.

Ferramentas de orquestração, cofres de credenciais e mecanismos próprios para armazenamento seguro existem justamente para resolver esse tipo de problema.

Filas mudam a forma de pensar o processo

Quando uma automação começa a lidar com volume, filas se tornam muito úteis.

Em vez de pensar:

Tenho uma execução que precisa processar 500 registros.

Passamos a pensar:

Tenho 500 transações independentes que precisam ser processadas.

Essa diferença é importante.

Com transações separadas, fica mais fácil:

• acompanhar status individual;
• reprocessar somente o que falhou;
• distribuir carga;
• identificar gargalos;
• medir quantidade processada;
• separar erros de negócio de erros técnicos.

Também reduz aquela situação clássica em que 499 itens são processados corretamente, o último falha e alguém precisa descobrir o que aconteceu com a execução inteira.

Interface é uma dependência frágil

Automação de interface continua sendo extremamente útil.

Existem muitos sistemas sem API ou sem qualquer alternativa de integração.

Mas interface muda.

Botões mudam de posição.

Campos são renomeados.

Elementos recebem novos identificadores.

Modalidades de autenticação evoluem.

O tempo de carregamento varia.

Por isso, quando existe uma API adequada para a necessidade, eu normalmente considero essa possibilidade antes de depender exclusivamente da interface.

Não porque API seja automaticamente melhor em todos os cenários.

Mas porque ela muda a natureza da integração.

Em vez de simular ações de um usuário, a automação passa a conversar diretamente com um serviço.

Isso tende a reduzir algumas dependências visuais e pode tornar o processo mais previsível.

Ainda assim, APIs também falham.

Elas possuem autenticação, limites, contratos, códigos de resposta, indisponibilidades e mudanças de versão.

A diferença é que os problemas são outros.

Idempotência deveria fazer parte da conversa

Imagine que uma automação envie uma operação para um sistema e a conexão caia antes de receber a resposta.

A operação foi realizada?

Ou não?

Se executarmos novamente, podemos criar uma duplicidade?

Esse tipo de situação é um bom exemplo de por que produção exige pensar além do fluxo principal.

Uma operação idempotente pode ser repetida sem alterar o resultado final além da primeira execução.

Nem todo sistema oferece isso nativamente.

Mas a automação pode adotar estratégias para reduzir riscos, como:

• consultar o estado antes de executar novamente;
• utilizar identificadores únicos;
• verificar registros já processados;
• registrar o resultado de cada transação;
• evitar reprocessamento cego.

Quanto mais crítica a operação, mais importante é saber responder:

O que acontece se esse passo for executado duas vezes?

Monitoramento começa depois do deploy

Existe uma sensação de conclusão quando uma automação finalmente entra em produção.

Mas o deploy não encerra o trabalho.

Ele muda o tipo de trabalho.

A partir daquele momento, começam a importar outras perguntas:

• quantos itens estão sendo processados?
• quantos estão falhando?
• quais erros aparecem com maior frequência?
• quanto tempo a execução está levando?
• existe crescimento de fila?
• uma dependência ficou indisponível?
• o processo parou de executar?

Sem monitoramento, muitos problemas acabam sendo descobertos pelo usuário.

E esse é provavelmente o pior mecanismo de observabilidade possível.

O ideal é conseguir detectar comportamentos anormais antes que alguém precise avisar que a automação parou.

Performance também muda em escala

Uma ação que leva um segundo parece irrelevante.

Até ser executada dez mil vezes.

É comum encontrar operações pequenas que não chamam atenção durante o desenvolvimento, mas passam a representar uma parcela significativa do tempo total quando o volume aumenta.

Por isso, performance em automação também precisa ser analisada considerando escala.

Algumas perguntas simples ajudam:

• essa consulta está sendo repetida sem necessidade?
• posso carregar os dados uma vez?
• estou fazendo chamadas individuais quando poderia trabalhar em lote?
• a automação está esperando tempos fixos desnecessários?
• estou usando interface para algo que poderia ser resolvido diretamente?
• existe processamento que pode ser evitado?

O objetivo não é otimizar cada milissegundo.

É entender onde o tempo realmente está sendo gasto.

Uma automação precisa ser sustentável por outras pessoas

Talvez esse seja um dos pontos menos discutidos.

Uma solução pode funcionar perfeitamente e ainda ser ruim de manter.

Variáveis sem significado.

Fluxos gigantes.

Código duplicado.

Configurações espalhadas.

Exceções silenciosas.

Dependências sem documentação.

Tudo isso aumenta o custo da sustentação.

Quando desenvolvemos algo para produção, precisamos considerar que outra pessoa poderá precisar entender aquilo meses depois.

Às vezes, essa pessoa somos nós mesmos.

E depois de alguns meses, nós também somos praticamente outra pessoa olhando aquele código.

Organização, nomes claros, separação de responsabilidades e documentação mínima fazem diferença.

O que mudou na minha forma de desenvolver automações

No início, eu olhava principalmente para a execução.

A pergunta era:

Como faço esse processo funcionar?

Hoje, tento pensar em um conjunto maior de perguntas.

Como ele falha?

Como eu descubro que falhou?

Consigo saber qual item teve problema?

Posso executar novamente com segurança?

Uma indisponibilidade temporária derruba todo o processo?

As configurações podem mudar sem alterar o código?

Outra pessoa consegue entender a automação?

Existe alguma forma de acompanhar o comportamento em produção?

O que acontece quando o volume aumentar?

Essas perguntas mudam bastante a arquitetura de uma solução.

Fazer funcionar continua sendo importante

Nada disso significa que devemos transformar toda automação em um projeto extremamente complexo.

Existe também o risco oposto: criar uma arquitetura enorme para resolver um problema pequeno.

O nível de robustez precisa acompanhar o risco e a importância do processo.

Uma automação simples, de baixo volume e baixo impacto, não precisa necessariamente da mesma infraestrutura de um processo crítico que movimenta centenas ou milhares de transações.

O importante é tomar essa decisão conscientemente.

Não adicionar complexidade por padrão.

Mas também não ignorar produção como se ela fosse apenas uma versão maior do ambiente de desenvolvimento.

Conclusão

Hoje, quando penso em qualidade de automação, não penso apenas em velocidade ou em quantidade de etapas automatizadas.

Penso principalmente em previsibilidade.

Uma boa automação precisa executar corretamente quando tudo está funcionando.

Mas também precisa conseguir reagir quando alguma coisa deixa de funcionar.

Precisa produzir informações suficientes para investigação.

Precisa permitir recuperação.

Precisa evitar duplicidades.

Precisa ser monitorável.

E precisa continuar compreensível depois que o desenvolvimento termina.

Fazer um robô funcionar é importante.

Fazer ele sobreviver à produção é onde começa a engenharia.