Testamos um destinatário inalcançável e o envio ainda disse que deu certo
Tínhamos uma regra sobre quem deve enviar uma mensagem urgente. Ela deve sair em nome da pessoa ou do processo que realmente foi feito para agir na hora, e não de uma linha geral e compartilhada que só poderia repassar as palavras. O teste que usamos para decidir isso era simples: se o login da pessoa ainda funciona, envie em nome dela.
Um login é só um conjunto de credenciais que funcionam. Ele funciona mesmo que não haja nada do outro lado, ativo e capaz de responder. A gente podia enviar uma mensagem em nome de alguém sem ter ninguém ali para responder, e o sistema ainda assim informava sucesso. Dizia que a mensagem tinha saído direitinho. Ninguém ficaria sabendo que a única coisa que importava, ter alguém ali para responder, não era verdade.
As passagens de bastão entre pessoas falham do mesmo jeito. O sistema informa sucesso enquanto nada é capaz de agir sobre o que chegou.
Fomos procurar antes que isso nos prejudicasse
Ainda não tínhamos sido prejudicados por isso. Fomos atrás do problema de propósito, antes que ele tivesse chance de importar. Deixamos o destinatário pretendido inalcançável, não mexemos em nada no login dele e enviamos uma mensagem de teste.
Ela saiu em nome da pessoa, bem formatada, entregue com sucesso, sem ninguém para ver.
Um login que funciona só diz que o sistema aceitou o pedido. Não diz nada sobre o que está acontecendo do outro lado. São dois fatos separados, e nós tínhamos construído uma verificação para apenas um deles.
O que conta como prova de que alguém está lá
A correção trocou a pergunta. Em vez de perguntar “o login dessa pessoa ainda funciona?”, o sistema agora pergunta se essa pessoa ou esse processo deu sinal de vida recentemente, por conta própria, em intervalos regulares, em algum lugar que a gente consiga ver, independentemente de o envio de uma mensagem ter sucesso ou não. Se esse sinal recente estiver ausente, desatualizado ou impossível de ler por qualquer motivo, o sistema trata tudo do mesmo jeito, sempre. Ele presume que não há ninguém e passa para a próxima opção.
Ele não tenta adivinhar se a pessoa está indisponível, inalcançável ou se a verificação só falhou por um motivo qualquer. Quem espera do outro lado vive os três casos exatamente da mesma forma: acha que alguém está a caminho, e não vem ninguém. Tratar os casos como diferentes e enviar mesmo assim é como uma falha passa meses sem ser notada.
O backup diz que é um backup
O outro detalhe importou tanto quanto a verificação. O caminho de backup nunca finge ser o original. Quando o destinatário pretendido não consegue provar que está presente, a mensagem ainda sai, mas por uma linha claramente diferente e claramente identificada. Ela diz com todas as letras que o destinatário habitual parece estar indisponível e que aquilo é um backup. Se até isso falhar, cai para o recurso mais simples possível, também identificado. Cada etapa se anuncia.
Um backup que entra no lugar sem avisar falha em silêncio por meses, até o dia em que faz diferença.
Quem decide o quê
Um assistente ajudou em uma parte disso: projetar e descrever a verificação de “a pessoa está lá?” e garantir que cada etapa de contingência se identifique corretamente. Ele não deve decidir sozinho que um login que funciona é prova suficiente, e não deve redirecionar uma mensagem urgente sem avisar que fez isso.
Uma pessoa decide o que conta como prova de que alguém está disponível e o que é um backup aceitável quando não está. É um julgamento sobre o custo de uma mensagem perdida, e cabe a quem é dono desse risco.
Um login que funciona prova que a porta abre. Não prova que tem alguém atrás dela. Para qualquer coisa urgente, agora exigimos um sinal de vida recente e independente, tratamos a ausência ou a ilegibilidade desse sinal como “não há ninguém” e identificamos toda rota de backup como backup.