Como saber se uma automação parou de rodar?

Com monitoramento de ausência, também chamado de dead man's switch. A automação avisa a cada execução bem-sucedida e um vigia externo alerta quando o aviso não chega no prazo esperado. Sem isso, ausência de erro é confundida com sucesso.

O que é idempotência e por que ela importa na retentativa?

É a propriedade de executar a mesma operação várias vezes com o mesmo resultado final. Ela importa porque toda retentativa corre o risco de duplicar o efeito, pagar duas vezes, criar dois pedidos, enviar dois e-mails.

Quantas vezes uma automação deve tentar de novo antes de desistir?

Poucas vezes, com intervalos crescentes, e só para erros temporários como timeout e indisponibilidade. Erro de dado inválido não melhora com repetição e deve ir direto para a fila de revisão humana.

A automação que quebra em silêncio: como evitar

A automação que dá erro é o problema fácil: alguém vê a mensagem vermelha e conserta. A cara é a que para de rodar sem avisar, ou pior, a que continua rodando e grava dado errado sem lançar exceção nenhuma. Ninguém percebe por semanas, até a conciliação não fechar, o cliente reclamar ou o relatório mostrar um número impossível. A defesa tem três camadas: detectar ausência, validar resultado e tornar a falha visível.

As quatro formas de quebrar em silêncio

1. Parou de executar. O agendador morreu, o servidor reiniciou, a credencial expirou, o certificado venceu. Não há erro porque não há execução. Do lado de fora, tudo parece normal.

2. Executou vazio. A rotina rodou, buscou registros, encontrou zero e terminou com sucesso. Zero pode ser legítimo ou pode significar que o filtro quebrou. Sem verificação, os dois casos são idênticos no log.

3. Gravou errado sem reclamar. Muito comum em robô de interface e em integração com mapeamento de campos. O dado foi para o campo vizinho, o valor entrou com escala errada, o centro de custo caiu no padrão. Tudo "com sucesso".

4. Processou parcialmente. De 500 registros, 480 passaram e 20 falharam. Se o log só reporta o fim do lote, os 20 desaparecem. É a falha mais frequente e a mais subestimada.

Camada 1: monitorar ausência, não só erro

Monitorar erro é fácil e insuficiente. É preciso monitorar o que não aconteceu.

O mecanismo é simples: cada execução bem-sucedida registra um "estou vivo", um ping para um serviço externo, um registro em tabela, uma marcação de timestamp. Um vigia independente checa esse sinal e alerta quando ele não chega no prazo. É o que se chama de dead man's switch.

O ponto essencial: o vigia precisa ser externo à automação. Se ele roda no mesmo processo, morre junto e não avisa nada.

Além do sinal de vida, monitore expectativas de volume:

Verificação	Alerta quando
Última execução bem-sucedida	Passou do prazo esperado
Quantidade processada	Zero, ou fora da faixa histórica
Duração da execução	Muito acima ou muito abaixo da média
Idade do item mais antigo na fila	Passou do limite aceitável
Taxa de falha por lote	Acima de um percentual

A duração muito abaixo da média é um sinal traiçoeiro e valioso: rotina que costuma levar 8 minutos e terminou em 12 segundos quase certamente não fez o trabalho.

Camada 2: validar depois de gravar

Confiar que a gravação deu certo porque não deu erro é otimismo. Em operações que importam, leia de volta e confira.

Padrões de validação que funcionam:

Leitura de conferência. Depois de gravar, buscar o registro e comparar os campos-chave.
Soma de controle. O total gravado bate com o total enviado? Diferença de um centavo denuncia arredondamento errado.
Contagem cruzada. 500 saíram da origem, 500 chegaram no destino?
Sanidade do valor. Data futura demais, valor negativo onde não pode, CNPJ malformado, campo obrigatório vazio.
Detecção de duplicidade. Antes de gravar, checar se já existe registro equivalente.

Essas verificações custam pouco tempo de execução e evitam o cenário mais caro: descobrir na auditoria que três meses de dados estão errados.

Camada 3: retentativa que não duplica

Retentativa é necessária, redes falham, APIs ficam indisponíveis. Mas retentativa sem cuidado cria o problema oposto: pagar duas vezes, criar dois pedidos, mandar dois e-mails de cobrança.

Idempotência é a proteção. Cada operação carrega uma chave única; o destino registra a chave e recusa a segunda gravação com o mesmo identificador, devolvendo o resultado original. Sem isso, nenhuma retentativa é segura.

Além disso, separe os tipos de erro:

Tipo de erro	Exemplo	Conduta
Temporário	Timeout, 503, limite de requisição	Tentar de novo com intervalo crescente
Permanente de dado	CNPJ inválido, campo faltando	Não repetir, fila de revisão humana
Permanente de acesso	Credencial expirada, 401	Alertar imediatamente, não repetir
Desconhecido	Resposta inesperada	Uma tentativa, depois revisão

Repetir um erro de dado inválido cem vezes só enche o log e mascara o problema real.

E use intervalos crescentes com variação aleatória. Se cem execuções falharem juntas e repetirem exatamente no mesmo instante, elas derrubam o serviço que estava só lento.

A fila de falha precisa ter dono

Todo item que falhou em definitivo precisa ir para uma fila visível, dead letter queue, com quatro informações: o que era, quando falhou, por quê e como reprocessar.

O que costuma dar errado nessa parte:

A fila existe mas ninguém olha. Defina um responsável e uma revisão diária.
O item vai para a fila sem o dado original. Guarde a carga completa, senão não dá para reprocessar.
Reprocessar duplica o efeito. Só reprocessar operação idempotente.
A fila cresce indefinidamente. Alerte no tamanho, não só na entrada de item novo.

Um número de itens em fila crescendo devagar é o alerta precoce mais confiável que existe: significa que algo está falhando sistematicamente e ainda não incomodou ninguém.

Onde mandar o alerta

Alerta que ninguém lê não é alerta. Três regras:

Canal que a pessoa já usa. E-mail vira ruído. Grupo de mensagem que o time acompanha funciona melhor.

Alerta acionável. Deve dizer qual automação, o que aconteceu, qual o impacto e o que fazer. "Erro na integração" não é alerta, é angústia.

Sem fadiga. Se o time recebe 40 alertas por dia, ignora os 40. Agrupe, silencie ruído conhecido e reserve o alerta para o que exige ação. Um alerta ignorado é pior que nenhum, porque cria a ilusão de que existe monitoramento.

O checklist mínimo antes de colocar em produção

A automação registra sinal de vida a cada execução
Existe vigia externo alertando por ausência
Volume processado é comparado com a faixa esperada
Resultado é validado depois de gravado
Toda operação de escrita é idempotente
Retentativa distingue erro temporário de permanente
Existe fila de falha com carga completa e reprocessamento seguro
Alguém é responsável por olhar essa fila, com frequência definida
O alerta vai para um canal lido e diz o que fazer
Existe um jeito de desligar a automação rápido, sem apagar código

O item 10 fecha o conjunto. Quando algo dá errado de verdade, a primeira ação é parar a automação sem perder o que está na fila, e essa chave precisa existir antes de ser necessária.