Uma automação confiável não esconde o processo. Ela transforma cada etapa importante em um estado que pessoas e sistemas conseguem compreender.
O fluxo precisa existir fora do código
Quando uma automação vive apenas como sequência de funções, o usuário enxerga dois estados: começou e terminou. Qualquer coisa entre eles vira espera, dúvida ou uma mensagem genérica de erro. Para operações reais, isso é pouco.
Prefiro modelar etapas que tenham significado para o domínio. Uma campanha pode estar programada, na fila, enviando, pausada ou concluída com falhas. Uma chamada de portaria pode estar tocando, aceita ou guardada. Um relatório pode estar consultando fontes, pronto na camada base ou aguardando análise.
Esses estados não servem apenas para desenhar badges. Eles definem quais ações são permitidas, como retomar o processo e o que precisa ser comunicado.
Tentativa automática exige idempotência
Repetir uma operação é útil quando a falha foi temporária. É perigoso quando o sistema não sabe se a primeira tentativa produziu efeito. Um envio duplicado, uma cobrança repetida ou dois registros iguais são formas diferentes do mesmo problema.
Antes de adicionar retry, a operação precisa de identidade. Uma chave idempotente, um estado persistido ou uma restrição no banco deve permitir responder se aquele trabalho já foi realizado. A tentativa seguinte continua do ponto seguro, não do começo imaginado.
Também é importante separar falhas recuperáveis de falhas permanentes. Tempo esgotado e indisponibilidade podem justificar nova tentativa. Endereço inválido, permissão negada ou payload inconsistente pedem correção, não insistência.
Logs técnicos não substituem uma interface operacional
Um log ajuda quem desenvolve. A pessoa que opera precisa de outra coisa: saber qual item falhou, por quê, o que já aconteceu e qual ação está disponível. Observabilidade de produto traduz o comportamento técnico para o contexto da tarefa.
No Disparador, isso significa registrar erros por destinatário e tipo, manter a campanha navegável e permitir pausa ou retomada. No PortariaGo, a resposta do morador precisa voltar para o porteiro na mesma tela em que a chamada foi iniciada. No Dossiê, fontes opcionais podem falhar sem apagar a camada base.
A interface operacional é parte do mecanismo de recuperação. Quando o sistema mostra estado e contexto, uma pessoa consegue concluir o que a automação não resolveu sozinha.
Métrica útil responde uma pergunta de operação
Contar execuções é um começo, mas raramente explica saúde. Quero saber quanto tempo cada etapa leva, onde a fila cresce, quais falhas se repetem, quantas tentativas foram necessárias e qual parte exigiu intervenção.
A métrica certa depende da promessa do produto. Em e-mail, entrega, abertura e clique contam histórias diferentes. Em tempo real, atraso entre evento e atualização importa. Em coleta de dados, a disponibilidade de cada fonte precisa ser distinguida da disponibilidade do relatório completo.
Observabilidade boa reduz o tempo entre perceber um problema e entender o que fazer. Se o dashboard só confirma que algo deu errado, ele ainda não concluiu o trabalho.
Elementos mínimos de uma automação operável
- Estados persistidos com significado para quem opera
- Identidade idempotente antes de qualquer tentativa automática
- Separação entre falha temporária, permanente e ação humana
- Histórico por item, não apenas um log global
- Métricas associadas à promessa real do produto
