MÓDULO 4.4

🛡️ Confiabilidade

O que separa um brinquedo de um serviço pelo qual o cliente paga: tratamento de erros, retries e timeouts, idempotência para não duplicar, observabilidade com logs e alertas, testes em homologação e um checklist final antes de ir pra produção.

6
Tópicos
50
Minutos
Intermediário
Nível
Mão na massa
Tipo
Trigger Ação + retry 3 tentativas Sucesso ✓ on error Error workflow Alerta Slack Log

Ilustrativo — sucesso segue à direita; falha cai no ramo de erro que alerta e registra log.

1

🚨 Tratamento de erros

Em produção, tudo falha eventualmente. Quem trata erro é avisado; quem não trata descobre pelo cliente irritado. Use um error workflow global, o ramo de erro do node, ou continue on fail.

# Error Trigger — workflow dedicado a falhas
// disparado automaticamente quando QUALQUER fluxo falha
Workflow:  ={{ $json.workflow.name }}
Node:      ={{ $json.execution.lastNodeExecuted }}
Erro:      ={{ $json.execution.error.message }}
// → manda esse resumo pro Slack

✓ Fluxo que trata erro

  • ✓Error workflow global avisa toda falha.
  • ✓continue on fail em node não-crítico.
  • ✓Ramo de erro grava o item problemático.

✗ Fluxo que morre em silêncio

  • ✗Sem error workflow — falha passa batida.
  • ✗Um item ruim derruba o lote inteiro.
  • ✗Ninguém é notificado; cliente descobre antes.
2

⏱️ Retries e timeouts

Muita falha é transitória — API instável, timeout de rede. Um retry com backoff transforma "deu erro" em "resolveu sozinho na 2ª tentativa". Mas defina um timeout: esperar infinito trava o fluxo.

# configuração de retry no node (settings)
Retry On Fail:      true
Max Tries:          3
Wait Between Tries: 2000 ms   // idealmente crescente (backoff)
Timeout:            30000 ms  // não espere para sempre

📊 Retry com juízo

  • Backoff - espere mais a cada tentativa (2s, 4s, 8s) para não martelar a API.
  • Só o que é transitório - 5xx e timeout valem retry; 400/401 não (vão falhar igual).
  • Teto de tentativas - 3 a 5; depois, caia no ramo de erro e alerte.
3

🧬 Idempotência e evitar duplicidade

Retries e webhooks reentregam. Sem idempotência, cada reenvio vira duplicata — dois registros, dois e-mails, a mesma cobrança 3x. Idempotente = rodar o mesmo input duas vezes tem o mesmo efeito que rodar uma.

# UPSERT por chave idempotente em vez de INSERT cego
// chave idempotente derivada do evento
chave = ={{ $json.pedido_id + '-' + $json.tipo_evento }}

// UPSERT: se a chave já existe, atualiza; senão, cria
// → reenvio do mesmo evento não duplica
1

Defina uma chave idempotente

Um identificador estável do evento (ex.: pedido_id) que não muda entre reenvios.

2

Cheque antes de agir

SELECT pela chave antes de inserir, ou use UPSERT que já resolve isso no banco.

3

Dedupe antes de notificar

Marque "já enviado" para que um retry não dispare o mesmo e-mail de novo.

4

📡 Observabilidade: logs e alertas

Você não conserta o que não vê. Logs estruturados registram o que cada execução fez; alertas proativos avisam quando falha. A diferença entre 5 minutos e 5 horas de prejuízo.

# alerta para o Slack quando algo falha
POST ={{ $env.SLACK_ALERT_WEBHOOK }}
{ "text": "🚨 Falha no fluxo *={{ $json.workflow.name }}*\n
            Node: ={{ $json.execution.lastNodeExecuted }}\n
            Erro: ={{ $json.execution.error.message }}" }
Log estruturado

O que rodou, quando

Alerta

Slack / e-mail na falha

Métrica

Taxa de sucesso

Histórico

Execution history

💡 Dica prática

Alerte na falha, não no sucesso — senão vira ruído e você para de ler. E nunca logue a chave de API: mascare segredos antes de gravar qualquer linha.

5

🧪 Testes e ambiente de homologação

Testar direto em produção quebra o serviço do cliente ao vivo. Um ambiente de homologação (staging) com dados de teste é sua rede de segurança: valide a mudança lá antes de tocar no que está rodando.

✓ Com homologação

  • ✓Credentials e dados de teste separados (ENVIRONMENT=staging).
  • ✓Smoke test após cada mudança: dispara 1 caso e confere.
  • ✓Pin data com casos de borda (campo nulo, valor enorme).

✗ Testando em produção

  • ✗Mandar e-mail de teste para clientes reais.
  • ✗Editar o fluxo ativo sem cópia de segurança.
  • ✗Descobrir o bug só quando o volume real chega.

📊 O que testar antes de promover

  • Caminho feliz - entrada normal produz a ação esperada.
  • Casos de borda - campo faltando, lista vazia, valor inesperado.
  • Falha simulada - derrube a API de propósito e veja o ramo de erro agir.
6

✅ Checklist de produção

O checklist transforma "acho que tá pronto" em "está pronto" — e é o que você mostra ao cliente como garantia. Antes de ligar pra valer, passe por cada item.

🚀 Go-live checklist

☐Erros tratados (error workflow ativo)
☐Retries com backoff e timeout definidos
☐Idempotência garantida (sem duplicata)
☐Alertas de falha apontando para canal real
☐Segredos em $env/credential, nada hardcoded
☐Nulos tratados nas expressões
☐Testado em homologação (feliz + borda + falha)
☐Plano de rollback e dono responsável definidos

💡 Dica prática

Tenha sempre um plano de rollback: como desligar a automação e voltar ao processo manual em 1 clique se algo der muito errado. É isso que dá confiança para você (e para o cliente) ligar o fluxo.

📌 Resumo do Módulo

✓
Tratamento de erros - error workflow global; quem trata é avisado, quem não trata descobre tarde.
✓
Retries e timeouts - backoff só para falha transitória; sempre com teto e timeout.
✓
Idempotência - chave estável + UPSERT evitam duplicata em reenvios.
✓
Observabilidade - log estruturado e alerta na falha; nunca logue segredo.
✓
Homologação - teste em staging com casos feliz, borda e falha antes de promover.
✓
Checklist de produção - go-live + rollback transformam "acho" em garantia.

Próxima Trilha:

Trilha 5 · Comercialização - empacotar, precificar e vender sua automação como serviço.

← Voltar para Trilha Trilha 5 · Comercialização →