Disponibilidade não é uma pergunta de sim ou não

Um leitor perguntou por que marcamos como inacessível um servidor que abria normalmente no navegador dele. Ele estava certo e nós também. O servidor responde na maior parte das vezes — e no restante derruba a conexão.

Um servidor, duas verdades

Mandamos vinte e cinco requisições. Cerca de um terço voltou assim:

curl: (56) Recv failure: Connection reset by peer

Não é timeout. Não é problema de TLS. A conexão abre, a requisição sai e o servidor desliga no meio da resposta. Espaçar as requisições em três segundos não mudou nada, então também não é limitação de taxa. Nossas medições concordam: 31% das sondagens àquele host falham.

Por que uma checagem só mente

Se um servidor falha uma requisição a cada três, checar uma vez não diz quase nada. Duas em três vezes você vai chamá-lo de saudável e na terceira de quebrado — e as duas respostas estão igualmente erradas, porque a verdade é uma porcentagem, não um estado.

Nos alertas é pior. Duas falhas seguidas parecem uma queda. Com 31% de falha, duas seguidas acontecem em cerca de 9% das vezes — mais ou menos uma vez por dia se você checar a cada duas horas. Isso não é queda. É aritmética.

Quão comum é isso?

Varremos o catálogo atrás de servidores que não estão nem confiavelmente no ar nem confiavelmente fora. Cerca de 180 ficam nesse meio instável, falhando entre 10% e 90% das vezes. Uma fatia pequena do ecossistema — e uma fatia grande da confusão.

O que fazer com isso

• Se você está escolhendo um servidor: leia a porcentagem, não o selo. Um servidor a 70% vai falhar em produção, silenciosamente, uma chamada a cada três.
• Se você opera um servidor: resets intermitentes de conexão costumam apontar para o proxy ou load balancer na frente do app, não para o app. Os logs da aplicação vão parecer limpos.
• Se você constrói monitoramento: nunca decida com uma amostra só. Exija uma sequência e diga a taxa em voz alta.