Os alertas estão configurados e não chega nada: o caminho de entrega que ninguém testa

Monitoramento tem duas metades. A verificação que percebe que algo está errado, e o caminho que leva essa notícia até uma pessoa. Quase toda a atenção vai para a primeira, e quase todas as falhas silenciosas moram na segunda.

A parte incômoda: um caminho de entrega quebrado e um sistema saudável parecem exatamente iguais de onde você está. Os dois produzem uma caixa vazia.

Por que enviar e-mail de um servidor deixou de ser simples

Um servidor enviar o próprio e-mail direto foi normal por muito tempo e hoje é exceção. Três coisas aconteceram.

Os destinatários pararam de confiar em remetentes desconhecidos. Uma mensagem que chega sem registros de política de remetente batendo, sem assinatura e de um endereço sem reputação é tratada como suspeita, e a versão educada de suspeita é a pasta de spam.

Conexões residenciais e de pequenas empresas são bloqueadas no nível da porta. Muitos provedores não permitem conexões de saída na porta usada para entrega direta, justamente porque foi abusada. Seu servidor tenta, e nada te avisa que nunca saiu.

A reputação pertence ao endereço, não a você. Um endereço residencial ou de nuvem pequena carrega a história que tem. Você herda.

Nada disso torna o problema difícil. Torna a configuração ingênua silenciosamente ineficaz, o que é pior que difícil.

As duas formas que funcionam

Enviar por um relé em que você já confia. Seu servidor entrega a mensagem, com credenciais, a um provedor que tem permissão de enviar. É a resposta comum e funciona, com uma ressalva que vale saber: provedores costumam exigir que o endereço remetente seja um que eles hospedam, então uma mensagem que parece vir de outro lugar é recusada ou reescrita.

Não enviar e-mail nenhum e usar um segundo canal. Uma notificação push ou uma mensagem num serviço que você já lê. Soa como retrocesso e muitas vezes é a opção mais confiável, justamente por não depender da entregabilidade do e-mail.

Qualquer que seja a escolha, o importante é a seção seguinte.

O teste que realmente prova

Quase todo mundo testa notificações do mesmo jeito errado: aperta o botão "enviar teste" sentado na frente da máquina, não vê nada falhar, e considera resolvido.

Esse teste prova que o processo consegue entregar uma mensagem. Não prova que ela chega. Um teste de verdade responde quatro perguntas:

Caiu na caixa de entrada, não no spam? Entrega e visibilidade são resultados diferentes, e só um te acorda.

Veio do endereço que os alertas reais vão usar? Um teste enviado com uma identidade não diz nada sobre uma tarefa noturna usando outra.

Chegou na hora em que o alerta real vai disparar? Alguns caminhos se comportam diferente às três da manhã e às três da tarde, geralmente porque limites de taxa de um relé ou filtros de um provedor dependem do horário. Essa falha é mais rara e é exatamente a que importa.

Sobreviveu com a máquina sob carga? Uma mensagem enfileirada durante um incidente real está competindo com o incidente.

Falhas que não produzem erro nenhum

A fila. O e-mail é gerado, aceito localmente, e fica numa fila que tenta de novo para sempre. Nada se perde, nada é entregue, e ninguém olha a fila porque não houve erro que empurrasse para isso.

O remetente reescrito. O relé aceita a mensagem, troca o remetente por um endereço que você não lê, e entrega perfeitamente numa caixa que ninguém abre.

O filtro que você mesmo fez. Alertas são todos parecidos, em algum momento uma regra pega um, e a regra continua funcionando muito depois de você esquecer que a escreveu.

O endereço que deixou de existir. A pessoa saiu, o apelido encaminhava para a conta dela, e o encaminhamento agora cai no vazio.

O único hábito de verdade útil

Faça a ausência de mensagem significar algo.

Um sistema que só fala quando algo está errado não se distingue de um sistema que perdeu a capacidade de falar. Uma mensagem diária dizendo que está tudo bem transforma o próprio silêncio em sinal: se hoje não chegou nada, o caminho de entrega é a primeira coisa que você checa, e você descobre numa manhã calma em vez de durante um incidente.

Por isso um resumo diário vale mais do que parece. O trabalho real dele não é o conteúdo, é provar que o canal ainda existe.

O que o Atlas faz

O Atlas Watch manda uma mensagem por dia em vez de um fluxo de alertas, e essa escolha é deliberada pelo motivo acima. O resumo carrega o estado acumulado durante o dia, e a chegada dele é por si só a prova de que o caminho está intacto.

As mesmas notificações também podem chegar ao portal da conta, o que aqui importa em especial: é um segundo canal que não depende da entrega de e-mail do host. Se o que quebrou foi o e-mail, o canal que não usa e-mail é o que ainda te avisa.

E a parte honesta, porque é o assunto inteiro deste texto: quando uma verificação não consegue ler seus dados, o Watch diz que não conseguiu ler em vez de ficar calado. Uma tarefa de backup ausente e uma saudável parecem idênticas de fora, e a única coisa que as separa é um vigia disposto a relatar a própria cegueira.