A alteração número cinquenta não se parece com a primeira
Montar a automação foi a parte fácil: não havia nada para partir, ninguém dependia dela e o pior cenário era não funcionar. Meio ano depois, o cenário muda de forma. O fluxo leva meses a dar serviço, há duas ou três pessoas que dependem do que ele produz sem sequer saberem que há um fluxo por trás, e alguém pede «um ajuste pequeno» na lógica de atribuição. O ajuste faz-se a quente numa quinta-feira à tarde. Na sexta de manhã há quarenta emails que saíram para o comercial errado e ninguém sabe dizer desde quando.
A diferença entre os dois momentos não é técnica: é de risco. Em do protótipo em Make para produção está a primeira viagem, a de endurecer algo que funcionava na demo. Aqui vai a viagem número cinquenta, que é a que se repete para sempre: mexer em algo que já está vivo e a dar serviço, sem que o teste seja pago pelo cliente.
A cópia: dados de entrada reais, destinos de saída falsos
O erro clássico é testar com dados inventados. Cria-se um contacto de teste chamado «Test Test», com um email limpo, um telefone com formato perfeito e um assunto de três palavras, e o teste passa. Depois chega a realidade: o nome em maiúsculas com dois apelidos e um hífen, o anexo de onze megas, o email reencaminhado catorze vezes com a conversa toda colada por baixo, o campo vazio que passou dois anos sem estar vazio. Os dados inventados provam que o fluxo funciona com os casos que já tinhas imaginado, que são exatamente os que nunca partem.
A cópia correta constrói-se ao contrário: entra dado real, sai dado falso. Duplica-se o fluxo, mete-se-lhe a alteração, deixam-se intactas as credenciais de leitura e trocam-se todas as de escrita.
- Um nome que não engane. A cópia leva uma convenção estrita e visível —
[TESTE] nome-do-fluxo-data— para que ninguém a confunda com a boa numa lista de quarenta cenários às onze da noite. - Leitura real, escrita desviada. Cada passo que escreve para fora é redirecionado: o email para uma caixa interna, a linha do CRM para um objeto ou uma vista de testes, a notificação para um canal privado, o webhook de saída para um recoletor que só guarda o que recebe.
- Atenção ao acionador. Se a cópia dispara com o mesmo evento que a original, o evento é processado duas vezes. Ou a cópia se executa à mão sobre uma lista de casos guardados, ou se lhe põe um filtro de entrada que só deixa passar os casos de teste.
- Casos guardados, não casos improvisados. Guarda dez ou quinze execuções reais do último mês —as normais e as estranhas, incluindo a que já falhou uma vez— e passa sempre as mesmas pela cópia. Isso transforma «parece-me que está a correr bem» em «estes quinze casos dão o mesmo que antes, exceto naquilo que eu queria mudar».
As ferramentas ajudam na parte mecânica, mas nenhuma te monta os destinos falsos: isso é trabalho teu e é aí que se joga a segurança do teste.
| Ferramenta | O que te dá de origem | O que tens de montar tu |
|---|---|---|
| n8n | Fixar (pin) a saída de um nó para reexecutar sem voltar a chamar a origem; as execuções de produção ignoram o dado fixado, por isso não se infiltra na operação | Os destinos falsos: credenciais e variáveis de ambiente próprias da cópia a apontar para caixa, folha e canal de testes |
| Make | Clonar o cenário e um histórico de versões a partir do qual restaurar uma anterior | A cópia clonada arrasta as mesmas ligações reais; é preciso reapontá-las à mão antes da primeira execução |
| Zapier | Rascunhos para editar um Zap sem o desligar e uma versão guardada sempre que publicas, com volta atrás nos planos Professional, Team e Company | A publicação é total: a saída por percentagem ou por segmento não existe de origem, monta-se com um filtro no início do Zap |
O que se pode testar a quente e o que não: a linha é a escrita
Há uma única pergunta que decide se um passo se pode exercitar sobre o fluxo vivo: deixa rasto lá fora? Se a resposta for não, pode testar-se a quente sem dano. Se for sim, não se testa a quente nunca, e não há versão moderada dessa regra.
- Pode-se a quente: ler, classificar, extrair campos, pontuar, resumir, decidir um ramo, calcular e escrever o resultado num registo teu. O efeito fica dentro e podes sempre deitar o registo fora.
- Não se pode a quente: enviar email, mensagem ou fatura a alguém de fora; criar, atualizar ou apagar no CRM, no ERP ou na base de dados a sério; mover dinheiro; fechar ou reatribuir um ticket que o cliente vê; publicar. O destinatário não distingue o teu teste da tua operação.
Entre as duas há um caso intermédio que resolve quase tudo: a execução em seco. Deixas correr o fluxo inteiro com dados reais e substituis o último passo —o que escreve para fora— por um registo que anota exatamente o que teria enviado, a quem e com que conteúdo. Revês esse registo com calma e tens toda a informação de uma execução real sem nenhuma das suas consequências. É também a forma de descobrir a falha que não dá erro: o email que teria sido enviado corretamente, mas à pessoa errada. Esse é o que a monitorização clássica nunca vê, e está desenvolvido em detetar falhas em automações.
Lançá-lo por segmento e por percentagem, não de uma vez só
Uma alteração que passou na cópia ainda pode falhar em produção, e não por a teres feito mal: porque produção tem casos que a tua amostra não tinha. O volume real, a hora de ponta, o cliente com a configuração estranha, o mês de fecho. Publicar a cem por cento é apostar que os teus quinze casos representavam o mundo. Quase nunca representam.
- Primeiro por segmento, não ao acaso. O primeiro troço tem de ser o de menor custo se correr mal: só pedidos internos, só uma equipa, só um tipo de cliente, só os casos de valor baixo. Um segmento é fácil de explicar, fácil de vigiar e fácil de reverter, porque sabes exatamente a quem ligar.
- Depois por percentagem, com repartição estável. Quando o segmento aguenta, abre-se a uma parte do volume geral —dez por cento, depois trinta, depois setenta. A repartição faz-se com algo estável do registo (os últimos dígitos do identificador, por exemplo), nunca com um número aleatório: se a repartição for aleatória, a mesma encomenda pode ir pelo ramo novo hoje e pelo velho amanhã, e aí não podes comparar nada nem explicar o que aconteceu a um caso concreto.
- A cem por cento só quando o troço anterior sobreviveu a um ciclo inteiro. Não a uma tarde tranquila: a um ciclo completo do processo, com a sua segunda-feira de manhã e o seu fecho de mês, se o fluxo os sente.
- O filtro sai do fluxo quando isto acaba. Uma repartição por percentagem que fica posta seis meses é a próxima automação zombie: meia operação a passar por um ramo de que já ninguém se lembra.
A janela de observação: o que se olha e durante quanto tempo
«Vamos ficar de olho nisto» não é uma janela de observação. A janela tem de cobrir um ciclo completo do fluxo: se o processo tem picos às segundas, é preciso ver uma segunda-feira; se o volume se concentra no fim do mês, é preciso ver um fim de mês. Antes de a abrir precisas da linha de base —quantas execuções, quantos erros e quanto demorava na semana passada à mesma hora—, porque sem ela não estás a observar: estás a olhar.
| O que se olha | Está bem se... | Para-se se... |
|---|---|---|
| Volume de execuções | Parece-se com o da semana passada à mesma hora | Cai ou dispara sem motivo: o acionador mudou de comportamento com a alteração |
| Taxa de erro | Igual ou menor do que a linha de base | Aparece qualquer erro que não existia antes, mesmo que seja pouco frequente |
| Saída comparada | As únicas diferenças são as que procuravas | Aparecem diferenças que ninguém pediu: aí há um efeito colateral |
| Trabalho humano a jusante | Ninguém corrige à mão o que sai do fluxo | Alguém começa a arranjar coisas «porque o sistema anda a fazer coisas estranhas» |
A última linha é a mais importante e a que quase ninguém instrumenta. Os três primeiros indicadores dá-os a ferramenta; o quarto só o sabe a pessoa que recebe o trabalho. Por isso a janela de observação inclui avisar essa pessoa de que há uma alteração e pedir-lhe explicitamente que diga se alguma coisa lhe cheira mal. Uma alteração silenciosa transforma a tua equipa no sistema de deteção, sem lho dizer.
Voltar atrás em cinco minutos: o ensaio, não o plano
Toda a gente tem plano de reversão. Quase ninguém o executou alguma vez. E um plano que não se executou não é um plano: é uma intenção escrita num documento que se abre pela primeira vez no dia em que tudo corre mal, que é justamente o dia em que ninguém tem cinco minutos.
- Guarda a versão boa antes de mexeres em nada. Com nome e data, não «cópia 3». O Zapier cria uma versão sempre que publicas e permite voltar atrás nos planos Professional, Team e Company; o Make guarda histórico de cenário para restaurar uma versão anterior; no n8n o que é limpo é exportar o fluxo para JSON e versioná-lo no repositório da empresa, que ainda por cima te dá o diff que a interface não te dá.
- Escreve quem pode reverter e por onde se avisa. Uma pessoa com permissão, um canal onde se anuncia, uma frase. Se para reverter é preciso localizar a única pessoa que sabe, a tua janela de cinco minutos já são duas horas.
- Ensaia-o uma vez, com cronómetro. Sobre a cópia: parte alguma coisa de propósito e restaura. Se demoras quinze minutos, não tens uma reversão de cinco: tens um exercício por fazer.
- Tem claro o que não volta sozinho. Restaurar o fluxo estanca a hemorragia, mas não des-envia os emails que já saíram nem apaga as linhas que já foram criadas. Essa parte limpa-se à mão e é preciso saber de antemão como se localiza o que ficou escrito na janela má: por marca temporal, por etiqueta ou por identificador de execução.
Esse último ponto é o que separa a alteração ensaiada da alteração corajosa. A lista do que há para limpar escreve-se antes de publicar, não depois, e sai da mesma pergunta de antes: o que é que este fluxo escreve para fora? Cada escrita dessa lista precisa de saber como se desfaz. Se alguma coisa não se pode desfazer —uma cobrança, um email a um cliente—, esse passo é justamente o que sai em último lugar e com o segmento mais pequeno.
Nada disto se aguenta se o fluxo não estiver documentado: a cópia, a repartição e a reversão dependem de alguém saber que regra de negócio implementa cada ramo, e isso está em documentar as tuas automações. E quando a alteração afeta permissões, registos ou auditoria, a peça que falta é governação e controlo da automação. O resto do mapa —o que automatizar e com que critério— vive no guia-mãe de automatizar com IA.