Quando o vigia morre: por que o silêncio não é boa notícia

Você configurou os alertas. Semanas se passaram e nenhum e-mail chegou.

Há duas explicações. Ou realmente nada aconteceu, ou o sistema de alertas parou de funcionar e você não sabe. De fora, as duas parecem idênticas.

E a mente humana tende a ler o silêncio como boa notícia. É exatamente por isso que esse tipo de defeito vive meses sem ser notado.

Isso é um problema diferente de uma verificação que se cala

Em outro ponto desta wiki escrevemos: quando uma verificação não consegue ler seus dados, ela não deve se calar, deve dizer que não conseguiu ler.

O que descrevemos aqui está um degrau acima. Lá, uma verificação dentro de um vigia em funcionamento se calava. Aqui o próprio vigia sumiu. Não sobrou ninguém para falar, portanto também ninguém para dizer "não consegui ler".

Como um vigia morre em silêncio

O serviço para. Uma atualização, uma queda, falta de memória. O que avisaria você é justamente o que parou.

O caminho do correio quebra. Uma senha muda, um provedor bloqueia, o endereço volta. O vigia continua trabalhando, escreve suas mensagens, e nenhuma chega até você. Esse é o mais enganoso, porque do lado do servidor tudo parece saudável.

Alguém desliga e esquece. As notificações são desligadas temporariamente enquanto se investiga algo. O problema é resolvido. As notificações continuam desligadas.

A máquina desliga. O caso extremo: nada quebrado, só tudo em silêncio.

Os quatro têm algo em comum: nenhum produz uma mensagem. E se o seu jeito de perceber um defeito é receber uma mensagem, então defeitos que não produzem mensagem são invisíveis para você.

A solução tem outra forma: não um alarme, um batimento

É preciso inverter o sentido.

Um alarme diz: fale quando algo estiver errado. Um batimento diz: diga "estou vivo" em intervalos regulares mesmo quando nada acontece. E então que alguém perceba quando esse dizer parar.

A diferença importa. Um alarme é uma mensagem sobre um problema; um batimento é uma mensagem sobre o mensageiro. Eles respondem perguntas diferentes e nenhum substitui o outro.

Assim que existe um batimento, o significado do silêncio muda. O silêncio passa a carregar informação: algo que deveria estar falando não está.

Quem percebe precisa estar fora da máquina vigiada

Esta é a parte em que vale parar. Uma máquina não consegue anunciar a própria morte.

O lugar que avalia o batimento precisa estar fora do servidor vigiado: outra máquina, um telefone, um ponto externo. Uma verificação que roda dentro do servidor desliga junto com ele e não diz nada a ninguém.

Até a versão caseira mais simples basta: que o servidor deixe uma marca em algum lugar a cada hora, e você olhe a idade dessa marca. Não é preciso uma montagem complicada; a única coisa necessária é que a avaliação aconteça em outro lugar.

O batimento tem uma armadilha própria

Aqui há um erro de projeto sutil, e a maioria das montagens cai nele: amarrar o batimento ao calendário de algo que o usuário pode desligar.

Digamos que ele compartilhe o horário com o resumo diário. O usuário desliga o resumo, porque achou demais. O batimento para junto. O lado externo vê o sinal cessar e dispara um alerta de "sem notícias do seu servidor" enquanto absolutamente nada está acontecendo.

Você adivinha o resultado: o usuário se assusta uma vez à toa e na segunda desliga o alerta. Um alarme falso produzido pelo seu próprio mecanismo de segurança destrói a confiança nesse mecanismo mais rápido do que não ter nenhum.

A regra: o batimento precisa ter o próprio calendário, sem se apoiar em nada desligável.

A mesma forma, em outro lugar

No artigo sobre tarefas de backup desta wiki escrevemos: não olhe o estado da tarefa, olhe a idade do backup mais recente.

A mesma forma reaparece aqui: não pergunte ao sistema de alertas se ele funciona, olhe a idade do último sinal. Um estado é uma afirmação, uma idade é uma medida.

E por fim, a única coisa a fazer no dia da instalação: provoque um defeito de propósito e veja o e-mail chegar. Um alarme não testado não é um mecanismo, é uma esperança.

O que o Atlas faz

O Atlas Watch envia um resumo diário, avisa situações críticas na hora sem esperar o resumo, e ao lado disso emite um sinal de hora em hora dizendo "estou vivo".

O que vale contar é a que esse sinal não está amarrado.

O sinal não se apoia nem no calendário do resumo diário nem no do alarme. Os dois têm ajustes próprios e o usuário pode desligar qualquer um. Se o sinal dependesse deles, no instante em que o usuário desligasse o resumo o sinal pararia junto, e o outro lado diria "sem notícias deste servidor" mesmo sem nada acontecer. Por isso o sinal tem o próprio calendário.

O segundo detalhe segue o mesmo raciocínio: enquanto o ajuste de notificação está desligado, o arquivo de horário do sinal não é escrito. Assim não sobra um estado intermediário de "ligado mas não funciona"; ou o sinal existe ou não existe.

O caminho de notificação é seu: você define o seu próprio servidor de e-mail, e a mensagem sai do seu servidor. Enviar um sinal a um ponto externo é um acréscimo opcional, e o produto não depende disso para funcionar.

A lição geral: um mecanismo de segurança não deve se apoiar nas partes desligáveis daquilo que ele protege. Se se apoiar, morre em silêncio junto.