Os dois tipos de falha: a que te avisa e a que te deixa acreditar que está tudo bem
Quando alguém pergunta como saber se uma automação falhou, quase sempre está a pensar na falha ruidosa: o fluxo pára, a ferramenta manda um email, alguém arranja. Essa é a falha boa. É visível, é limitada e o seu custo é proporcional ao tempo que alguém demora a olhar para o telemóvel.
O problema é a outra. A falha silenciosa não pára: termina. Marca a execução a verde, não parte nada e continua a correr amanhã igual de mal. E não dispara alarme nenhum porque, tecnicamente, não há nada para alertar: cada passo fez o que lhe competia e devolveu sem erro. A ferramenta está a dizer-te a verdade —«todos os passos se executaram»— e tu estás a ler outra coisa —«o trabalho ficou feito»—. Não é a mesma coisa.
A diferença importa porque o custo não se parece. A falha ruidosa custa horas. A silenciosa custa semanas, e quando se descobre já é preciso reconstruir para trás: que encomendas não entraram, que clientes não receberam resposta, que faturas não ficaram registadas. Este guia pendura-se do manutenção das automações com IA, que explica porque se partem. Aqui vamos ao resto: como dás por ela.
As quatro caras da falha silenciosa
Em produção repetem-se quatro, e nenhuma dispara um erro. Reconhecê-las é metade do trabalho.
1. O sucesso vazio
A chamada devolve um 200 e o corpo vem vazio, ou com uma lista de zero elementos. Para o fluxo isso é um sucesso perfeito: pediu dados, recebeu resposta, seguiu em frente. O ciclo que vinha a seguir não deu uma volta sequer, logo não criou nada, logo não falhou. É o padrão número um e o mais difícil de ver, porque no painel parece idêntico a um dia bom.
2. O filtro que engole tudo
Alguém mudou um nome de campo no CRM, ou o formato de uma data, e a condição que deixava passar os registos já não é cumprida por nenhum. O fluxo executa-se, filtra, e do filtro não sai nada. Execução correta, zero trabalho feito. Distingue-se do anterior num detalhe: aqui sim entraram dados, simplesmente nenhum passou a porta.
3. A resposta inútil que ninguém valida
É a falha própria de automatizar com IA. Pedes ao modelo que devolva uma categoria ou um JSON, e ele devolve um pedido de desculpas, um texto a explicar porque não pode, ou o JSON envolto em três frases de cortesia. O passo seguinte aceita-o porque é uma cadeia de texto e ele esperava uma cadeia de texto. A partir daí, todo o fluxo trabalha em cima de lixo, com toda a normalidade. Cobre-se com uma validação de forma antes de seguir em frente: se não cumpre o formato esperado, para e escala. O guia do humano no ciclo desenvolve onde pôr essa rede consoante o custo do erro.
4. O fluxo que deixou de correr
O mais tolo e o mais frequente. Ninguém o partiu: desativou-se ao mudar de plano, caducou uma credencial OAuth, alguém pô-lo em pausa para testar uma quinta-feira e não voltou a ativá-lo. Não há execução, logo não há erro, logo não há nada para alertar. Este não se deteta olhando para o que acontece. Deteta-se dando por falta do que não acontece.
O que alertar e o que calar: um alarme que toca sempre não o ouve ninguém
O erro contrário a não ter alertas é tê-los todos. Um canal que recebe quarenta avisos por dia deixa de ser um canal de alertas à segunda semana: silencia-se, arquiva-se ou ignora-se, e o dia em que chega o aviso que importava está entre outros trinta e nove. A fadiga de alertas não é um problema das pessoas; é um problema de desenho.
A regra que aguenta em produção é de uma linha: alerta só o que vai fazer alguém largar o que está a fazer. Tudo o resto não desaparece, vai para um painel que se revê uma vez por dia com o café.
- Alerta a uma pessoa: o fluxo crítico falhou mesmo; o fluxo crítico leva mais tempo do que o normal sem correr; a fila de exceções cresce dois dias seguidos; a despesa do dia sai do intervalo esperado.
- Ao painel diário: erros pontuais que se resolveram ao repetir, casos escalados para revisão humana, execuções mais lentas do que o habitual, avisos de limite de plano que ainda não apertam.
- Nem para um sítio nem para o outro: tudo o que ninguém vai olhar nunca. Se um aviso não tem um dono e uma ação possível, não é um alerta: é um log. Deixa-o nos logs.
Começa curto. Dois alertas por fluxo crítico —falhou, e deixou de correr— e só acrescentas um terceiro quando um incidente real demonstrar que faltava. Os alertas ganham o lugar; não se distribuem por precaução.
O batimento: como apanhar o fluxo que deixou de correr
Esta é a peça que quase ninguém tem e a que mais vezes salva. Um batimento é um alerta que toca quando NÃO acontece algo. O fluxo manda um sinal cada vez que termina bem; um serviço externo espera-o; se não chegar dentro da janela esperada, avisa.
Dois pormenores que decidem se funciona. O primeiro: o batimento tem de viver fora da ferramenta que estás a vigiar. Se o vigilante e o vigiado são o mesmo sistema, no dia em que o sistema cair não te avisa ninguém —e esse é justamente o dia em que precisas dele—. O segundo: a janela calibra-se com o ritmo real do fluxo, não com o ideal. Um fluxo que corre a cada quinze minutos pode dar-se ao luxo de uma hora de margem; um diário não devia avisar por chegar vinte minutos atrasado. Janelas mal postas produzem alarmes falsos, e os alarmes falsos produzem alertas silenciados.
Confirmação de fecho: que o último passo prove que o trabalho chegou
O batimento diz-te que o fluxo correu. Não te diz que fez algo útil. Para isso está a confirmação de fecho: o último passo de cada fluxo crítico não é a ação, é a verificação da ação.
- Conta o que entrou e o que saiu. Se entraram catorze registos e se criaram zero, não é um dia calmo: é uma falha. Um fluxo que processa zero elementos vários dias seguidos merece um olhar, não um aval.
- Confirma no destino, não na resposta. A API ter dito que sim não prova que o registo existe. Uma leitura de volta —pedir ao sistema de destino o registo que acabaste de criar— transforma uma suposição num facto.
- Reconcilia com cadência. Uma vez por dia, compara a origem com o destino e procura o que falta. É a única coisa que deteta o evento que nunca chegou, porque um webhook perdido não gera erro nenhum: gera uma ausência.
- Deixa o rasto. Cada execução com o seu identificador, o que entrou, o que saiu e sob que versão. Sem isso não consegues reconstruir um caso concreto quando alguém pergunta por ele três semanas depois; é aí que entra a governança e controlo da automação com IA.
O que acontece quando dispara: gravidade, dono e a regra das três vezes
Um alerta sem destinatário é uma notificação. Antes de ligar seja o que for, escreve três coisas por fluxo crítico: quem responde (uma pessoa, não um departamento), o que se faz enquanto se arranja (o plano manual: continuar a faturar à mão não é um fracasso, é o plano) e o que justifica ligar a alguém fora de horas. Quase nada o justifica; convém decidi-lo a frio e não às 23h40.
E uma regra que poupa muitos incidentes futuros: se a mesma falha dispara três vezes, deixa de se arranjar e passa a redesenhar-se. Um erro que se repete não é azar, é uma suposição errada no desenho do fluxo —um caso que não foi contemplado, uma API que não é tão fiável como se pensava, um formato que muda mais do que se assumiu—. Remendar à terceira vez só garante que haverá uma quarta.
Nada disto é caro. Um batimento externo, uma confirmação de fecho e dois alertas bem escolhidos montam-se numa tarde por fluxo, e são a diferença entre dares por isso tu ou dares por isso através de um cliente. O que custa é sustentá-lo quando tens vinte fluxos vivos e ninguém cujo trabalho seja olhar para eles: isso já não é montar automações, é operá-las —e é exatamente o que fazemos em automação de operações—. Se ainda estás a decidir o que automatizar e com quê, volta ao pilar de automatizar com IA; se já o tens montado, começa pelo fluxo que mais dano faria se falhasse em silêncio.