A pergunta que mais aparece antes de alguém contratar uma automação é: e se ela parar de funcionar?
A resposta honesta é que ela vai parar, em algum momento. O sistema de um fornecedor sai do ar, uma senha expira, um arquivo chega num formato diferente, o servidor reinicia. Não existe automação que nunca falha. Existe automação em que a falha aparece em minutos, e automação em que a falha aparece semanas depois, na reclamação de um cliente.
A pergunta certa não é se a automação vai falhar. É em quanto tempo alguém fica sabendo.
Os três jeitos de falhar
Falhar com erro. O processo tenta fazer algo e não consegue: o sistema do outro lado recusou, o dado veio incompleto. É o tipo mais fácil, porque deixa rastro. Basta alguém olhar o registro.
Parar de rodar. O processo simplesmente não acontece mais. Não há erro, porque não há tentativa. Nada fica vermelho em lugar nenhum.
Rodar sem fazer nada. O mais traiçoeiro. Tudo parece funcionar, só que nada chega. Zero pedidos num dia, zero cliques numa campanha: um número que também poderia ser só um dia fraco.
Os dois últimos são os que custam caro, porque nenhum deles avisa sozinho.
Dois casos reais
Um gerador automático de artigos alimentava um blog todos os dias. Um dia, o programa que fazia esse trabalho deixou de estar rodando no servidor. Sem erro e sem aviso: o blog só parou de receber artigos. Hoje, uma verificação confere todo dia se apareceu artigo novo, e avisa no WhatsApp se passar dois dias sem nenhum.
Em outra empresa, um receptor de cliques de campanha de WhatsApp ficou semanas ligado sem registrar um clique sequer. Uma opção de segurança recusava todas as chamadas antes de elas chegarem. Zero cliques parecia campanha fraca, e por isso ninguém desconfiou.
Nos dois casos, a automação estava "ligada". O que faltava era alguém, ou alguma coisa, conferindo se o resultado estava aparecendo.
O que resolve cada tipo
O registro de execuções resolve o erro. Toda execução fica registrada, com hora, motivo da falha e o dado que estava passando naquele momento. Quando algo dá errado, a investigação começa com a resposta pronta, e não com "alguém lembra o que aconteceu na terça?".
A vigia resolve a parada. Uma verificação separada, que roda de tempos em tempos e confere o resultado, não o processo. Não pergunta "a automação está ligada?", pergunta "o que devia ter acontecido aconteceu?". Apareceu artigo novo? A fila de tarefas andou? Se a resposta for não, um aviso sai no WhatsApp.
O sinal de vida resolve a vigia parada. E se a própria vigia parar, junto com o resto? Para isso existe um serviço de fora, em outro lugar, que espera receber um sinal a cada meia hora. Se o sinal não chega, é ele que avisa, por e-mail. Quem vigia não pode depender do mesmo servidor que está sendo vigiado.
O resumo diário resolve o "rodando sem fazer nada". Um resumo no fim do dia, no WhatsApp, com os números do que aconteceu: quantas ações, quantos resultados, quantas falhas. Número zero num resumo que costuma ter vinte salta aos olhos de quem lê todo dia.
~/aquino-code $ vigia --a-cada 30min --sinal-de-vida 30min
- no máximo, em horário comercial, até a vigia perceber uma parada
- 30 min
- para o sinal de vida atrasar antes do aviso por e-mail
- 20 min de tolerância
- no fim da tarde, com os números do dia
- 1 resumo por dia
Os intervalos de um sistema de prospecção em operação. O blog usa a mesma ideia com outro prazo: dois dias sem artigo novo.
Parar de propósito
Às vezes o certo é parar tudo, e rápido. Um aviso de bloqueio, uma mensagem saindo com erro, um dado estranho. Nessa hora, ninguém deveria precisar lembrar onde cada parte da automação está ligada.
Por isso existe uma pausa geral: um botão que para tudo de uma vez, pede o motivo e avisa no WhatsApp que a pausa aconteceu. Retomar é outro botão, e volta só o que a pausa parou.
Uma automação que não tem botão de parar não está pronta para entrar em produção.
A cópia de segurança que foi testada
Cópia de segurança diária é o mínimo. Mas cópia de segurança que nunca foi restaurada é só uma esperança. O teste que importa é pegar a cópia, restaurar num banco vazio e conferir se os dados voltaram inteiros.
Na prática: a cópia sai sozinha toda madrugada, fica guardada por trinta dias num lugar diferente do servidor, e a restauração foi testada com os dados reais antes de o sistema entrar em operação.
O que perguntar a quem vai construir a sua
- Onde eu vejo o registro do que aconteceu, e quanto tempo ele fica guardado?
- Se a automação parar, quem fica sabendo, por onde e em quanto tempo?
- E se o próprio servidor parar, quem avisa?
- Como eu paro tudo de uma vez, se precisar?
- Quando foi a última vez que a cópia de segurança foi restaurada de verdade?
Se alguma dessas perguntas não tiver resposta, a falha vai ser descoberta pelo seu cliente.
Quando é exagero
- Se a falha é barata e aparece sozinha. Um relatório interno semanal que não chegou é percebido na segunda de manhã por quem esperava por ele. Não precisa de vigia.
- Se monitorar custa mais que falhar. Para um processo pequeno, o registro de execuções já basta. Vigia, sinal de vida e resumo diário são para o que custa caro quando para.
- Se ninguém vai ler o aviso. Aviso que cai num lugar onde ninguém olha é igual a não ter aviso. Antes de montar o monitor, decida quem recebe.