O que se perde exatamente quando uma automação cai (e porque não é «nada»)
A primeira pergunta depois de uma queda costuma ser «já funciona?». A segunda, a que quase ninguém faz, é «o que aconteceu ao que entrou enquanto não funcionava?». E a resposta depende de uma coisa que se decidiu no dia em que o fluxo foi montado: se o que entra tem uma fonte consultável ou se só existiu como um evento de passagem.
Os dois casos comportam-se ao contrário um do outro. Se o teu fluxo lê de um sítio que guarda —as encomendas da loja, os tickets do CRM, os emails de uma caixa—, não perdeste nada: o dado continua lá, à espera de que alguém o processe. Se o teu fluxo depende de alguém te empurrar o dado —um webhook, uma notificação— e o emissor não repete nem conserva histórico, esse evento evaporou-se. Não há registo, não há erro e não há ecrã onde o procurar.
- O consultável recupera-se. Encomendas, registos, documentos: tudo o que persiste na origem pode voltar a pedir-se por intervalo de datas e ser reprocessado.
- O empurrado depende do emissor. A Stripe, o GitHub ou a Shopify repetem os seus webhooks durante horas ou dias; um script interno ou uma integração caseira quase nunca. Antes de confiares num webhook, verifica se o emissor repete e durante quanto tempo.
- O que ficou processado a meio é o pior caso. Um fluxo que criou o registo mas caiu antes de o marcar como enviado deixa o sistema num estado que não está feito nem está pendente. É esse que produz duplicados ao reprocessar.
- O que foi processado mal em silêncio não é uma perda, é uma corrupção. Não é este plano que a resolve; quem a deteta é a vigilância de que fala detetar falhas em automações.
Essa distinção não é teórica: decide o que se pode prometer. Quando alguém pergunta «perdeu-se alguma coisa?», a resposta honesta é «do que entra pela loja, não; do que entra pelo webhook do fornecedor X, depende de ele repetir ou não». E se nunca o verificaste, essa é a primeira tarefa, antes de qualquer reprocessamento.
Idempotência primeiro: o arranjo que duplica faturas
Há uma tentação fortíssima no dia da queda: pegar no lote das horas más e voltar a passá-lo inteiro. É rápido, sabe a resolutivo e é a forma mais comum de transformar um incidente pequeno num incidente caro. Porque parte desse lote foi mesmo processada —a dos primeiros minutos, a que entrou nas brechas em que o serviço respondia— e esse pedaço vai executar-se uma segunda vez.
A peça que o impede chama-se idempotência e significa exatamente isto: executar duas vezes a mesma operação deixa o mesmo resultado que executá-la uma. Não é um ajuste que se ativa; é uma propriedade que se desenha, e assenta em duas decisões concretas.
- Uma chave estável por unidade de trabalho. O número da encomenda, o id da mensagem, o hash do documento. Nunca a marca temporal, nunca um contador da execução, nunca «o registo mais recente»: isso muda entre tentativas e parte a comparação.
- Um passo de escrita que verifica antes de criar. Procurar por essa chave e, se existir, atualizar ou sair sem fazer nada. Muitas APIs já o dão resolvido com um cabeçalho de chave de idempotência ou com um «criar ou atualizar» nativo; quando não há, monta-se à mão com uma tabela própria de chaves já processadas.
Regra prática que poupa discussões: se um fluxo não é idempotente, não tem plano de recuperação, tem um plano de risco. E a ordem importa —torná-lo idempotente vem antes de reprocessar seja o que for, mesmo com o chefe a olhar para o relógio—. Reprocessar um fluxo não idempotente para ganhar vinte minutos e gerar quarenta faturas duplicadas é um mau negócio que ainda por cima é preciso explicar.
Repetições com espera crescente: o que se repete e o que nunca se deve repetir
A maioria das falhas não precisa que ninguém as recupere: resolvem-se sozinhas se o sistema esperar um pouco e tentar outra vez. Um tempo de espera esgotado, um limite de pedidos, um 503 de um fornecedor que está a publicar uma versão nova. A condição é que a repetição esteja bem feita, e «bem feita» tem uma forma concreta.
Espera crescente: não repetir a cada segundo, mas separando as tentativas cada vez mais —uns segundos, depois o dobro, depois o dobro outra vez—, com um pequeno desvio aleatório para que mil execuções que falharam ao mesmo tempo não voltem todas ao mesmo tempo. Repetir em ciclo imediato contra um fornecedor caído não o ajuda a levantar-se: mantém-no no chão e, já agora, gasta-te a quota.
E uma distinção que separa as repetições úteis das nocivas: repete-se o que falhou por causa do ambiente, não o que falhou por causa do dado. Um 500 ou um tempo esgotado são candidatos legítimos. Um 400 porque falta um campo obrigatório, um 401 por credencial caducada ou um 422 porque o valor é negativo não melhoram por se repetirem: isso vai direto para a fila de falhados, porque cada repetição é só ruído e custo. Um fluxo que repete cinco vezes um erro de validação gasta cinco vezes e aprende zero.
Quantas tentativas: entre três e cinco cobre praticamente tudo o que é transitório. A partir daí, a causa já não é um soluço do ambiente, e insistir só atrasa o momento em que uma pessoa fica a saber. Esse momento —a passagem de repetir para desistir— é o que dá sentido à peça seguinte.
A fila de falhados: onde vai parar o que não conseguiu passar e como se relança
Quando as repetições se esgotam, o trabalho tem de aterrar nalgum sítio. Se esse sítio não existe, aterra no log —ou seja, em lado nenhum—. A fila de falhados é esse sítio: uma tabela, uma folha, um canal, o que for, desde que guarde três coisas por cada falha.
- O dado original inteiro, não um resumo nem a mensagem de erro. Sem a carga completa não podes relançar: só podes investigar.
- O motivo da falha e o momento, para poderes agrupar. Duzentas falhas com o mesmo motivo são um problema; duzentas com motivos diferentes são duzentos problemas.
- O estado: pendente, relançado, resolvido ou descartado com razão. Sem estado, a fila transforma-se num cemitério que ninguém se atreve a esvaziar.
O que muda quando a tens é a conversa. Passa-se de «perdeu-se o de ontem» para «há 214 em fila: 190 falharam pelo fornecedor caído e relançam-se tal e qual, 24 falharam por validação e precisam de olho humano». Isso é um incidente gerível. E acrescenta um sinal de saúde que nenhum alerta dá tão bem: uma fila que cresce avisa de um problema sistémico antes de o fazer um cliente.
O relançamento faz-se em lotes pequenos e por ordem, nunca tudo de uma vez. Primeiro um punhado, verifica-se o resultado no destino e só então o resto. Se o primeiro lote falhar na mesma, a causa não estava resolvida e acabaste de te poupar a repetir o erro duzentas vezes. Tudo isto assume o do ponto anterior: sem idempotência, relançar uma fila é apostar.
Reconciliação: como encontras o que nunca chegou a entrar
Repetições e fila cobrem o que falhou. Falta o buraco a sério: o que nunca chegou a ser tentado. O webhook que se perdeu, o acionador que estava desativado, o registo que o filtro descartou por um campo vazio. Aí não há erro, não há falha em fila e não há nada para repetir. Não há sequer rasto de que devia ter acontecido alguma coisa.
A única forma de o encontrar é deixar de olhar para a automação e comparar os dois extremos. Isso é reconciliar: pedir à origem tudo o que mudou numa janela de tempo, pedir ao destino o que foi criado nessa mesma janela, cruzar pela chave estável e ficar com a diferença. O que está na origem e não está no destino é exatamente o que se perdeu.
Três detalhes que decidem se a reconciliação serve ou dá falsos positivos: usa a mesma chave estável da idempotência (se comparares por nome de cliente ou por valor, vais encontrar diferenças que não existem); deixa uma margem de tempo de uns minutos nas bordas da janela, porque o dado de origem e o de destino não se escrevem no mesmo instante; e decide o que fazes com a diferença: o prudente é mandá-la para a fila de falhados e relançá-la pelo caminho normal, não escrevê-la diretamente por uma via paralela que salta as validações do fluxo.
A cadência depende do dano, não do volume. Diária e automática no que mexe com dinheiro ou com compromissos com clientes; semanal no interno de baixo impacto. E sobretudo permanente, não só depois de um susto: a reconciliação vale precisamente porque encontra a encomenda que se perdeu numa terça-feira qualquer sem que nada tivesse caído, essa que hoje se descobre quando o cliente escreve a perguntar. É a mesma disciplina de cuidado contínuo que sustenta a manutenção das automações com IA.
O plano de recuperação: quem o executa, por que ordem e com que verificação final
As quatro peças anteriores são capacidades. O que as transforma em recuperação é um plano escrito de antemão, curto, que alguém consiga executar no dia mau sem improvisar e sem depender de estar disponível a pessoa que montou o fluxo. Cabe em meia página e tem seis passos.
- 1. Parar a entrada. Antes de recuperar, fechar a torneira: se o fluxo continua a engolir enquanto reprocessas, nunca vais saber que lote é qual.
- 2. Fixar a janela. Desde quando até quando esteve mal. Com margem dos dois lados; é melhor sobrar do que faltar.
- 3. Confirmar a idempotência do fluxo. Se não a tiver, resolve-se aqui. Este passo não se salta por pressa.
- 4. Reconciliar a janela. Comparar origem e destino, e mandar a diferença para a fila de falhados.
- 5. Relançar em lotes pequenos, verificando o destino depois do primeiro antes de seguir com o resto.
- 6. Fechar com uma verificação de resultado, não de execução: contar registos no destino e cruzá-los com a origem. Que o reprocessamento «terminou sem erros» não prova nada.
E uma coisa que não é técnica mas decide o resultado: o plano precisa de um dono com nome e apelido, não de um departamento. A mesma regra que governa tudo o resto em governação e controlo da automação: sem nome não há controlo, há só um documento. Se vais montar o conjunto de raiz, o mapa completo está no guia de automatizar com IA.
A conclusão incómoda é que a recuperação não se improvisa: instala-se. Repetições, idempotência, fila e reconciliação montam-se quando está tudo a correr bem, porque no dia em que fazem falta já não há tempo para as construir. Se os teus fluxos críticos não as têm hoje, é exatamente isso que fazemos ao deixar um processo em produção em automação de operações: não só que funcione, mas que se saiba recuperar quando não funcionar.