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

Um leitor perguntou-nos porque marcávamos como inacessível um servidor que abria sem problemas no navegador dele. Ele tinha razão e nós também. O servidor responde na maior parte das vezes — e nas restantes corta a ligação.

Um servidor, duas verdades

Enviámos-lhe vinte e cinco pedidos. Cerca de um terço voltou assim:

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

Não é timeout. Não é problema de TLS. A ligação abre, o pedido sai e o servidor desliga a meio da resposta. Espaçar os pedidos em três segundos não mudou nada, por isso também não é limitação de taxa. As nossas medições concordam: 31% das sondagens àquele host falham.

Porque é que uma única verificação mente

Se um servidor falha um pedido em cada três, verificá-lo uma vez não diz quase nada. Duas em cada três vezes vai chamá-lo saudável e na terceira avariado — e as duas respostas estão igualmente erradas, porque a verdade é uma percentagem, não um estado.

Nos alertas é pior. Duas falhas seguidas parecem uma interrupção. Com 31% de falha, duas seguidas acontecem cerca de 9% das vezes — aproximadamente uma vez por dia se verificar de duas em duas horas. Isso não é uma interrupção. É aritmética.

Quão comum é isto?

Procurámos no catálogo servidores que não estão nem fiavelmente no ar nem fiavelmente em baixo. Cerca de 180 ocupam esse 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 isto

• Se está a escolher um servidor: leia a percentagem, não o emblema. Um servidor a 70% vai falhar em produção, em silêncio, uma chamada em cada três.
• Se opera um servidor: reposições intermitentes de ligação apontam normalmente para o proxy ou balanceador à frente da aplicação, não para a aplicação. Os registos aplicacionais vão parecer limpos.
• Se constrói monitorização: nunca decida com uma única amostra. Exija uma sequência e diga a taxa em voz alta.