Porque o seu alojamento não o avisa quando o site cai

O seu servidor não se mexeu. O disco está bem, a rede responde, o processador está de braços cruzados. E a sua página inicial devolve um erro 500 a todos os visitantes há seis horas.

As duas afirmações são verdadeiras ao mesmo tempo, e é aí que está todo o mal-entendido. O seu alojamento não lhe mente nem o descura: olha para outra coisa diferente daquilo que julga que ele olha.

O que vigia, o que não vê, quem o vê

A coluna da direita é a que conta: em cinco casos em oito, a única pessoa informada é um visitante, e um visitante não lhe escreve. Vai para o resultado seguinte, e dessa falha só saberá se por acaso for você a olhar.

Dois objetos diferentes

Um alojamento vigia a máquina: tem energia, é alcançável, tem espaço em disco, a rede passa. A vigilância dele existe para cumprir o compromisso próprio, que diz respeito à infraestrutura.

O seu site é uma aplicação que corre nessa máquina. Um erro de PHP, uma extensão atualizada de través, um certificado expirado, uma base de dados parada: nada disso adoece a máquina. Do ponto de vista do alojamento está tudo normal, e factualmente ele tem razão.

As cinco falhas que um alojamento nunca assinalará

O certificado expirado. O servidor responde perfeitamente, é o navegador que se recusa a mostrar. Nenhum indicador de infraestrutura se mexe, e essa falha não deixa rasto nos seus registos.

O deploy falhado. A raiz de documentos aponta para o sítio errado, uma rota está errada, falta um ficheiro de configuração. A máquina serve conscienciosamente uma página de erro, que é exatamente o trabalho dela.

O erro aplicacional. Uma atualização de extensão, uma dependência incompatível, uma base que recusa ligações. O servidor web responde, e responde um 500.

A lentidão. Oito segundos por página é uma resposta válida para uma supervisão de infraestrutura. Para um visitante, é um site partido.

A falha parcial. A página inicial está bem, o funil de compra está morto. Nenhuma ferramenta que teste apenas a raiz do domínio o verá, incluindo a sua se a configurou assim. É também a falha mais cara, porque atinge justamente as páginas onde se ganha dinheiro.

O que um alojamento sinceramente não pode saber

Mesmo com a melhor vontade, um prestador não sabe:

• o que a sua página inicial deve mostrar;
• se uma redireção 302 é voluntária ou o resultado de um deploy falhado;
• se uma página em branco é uma opção de desenho ou um erro fatal apanhado tarde demais;
• se o seu certificado cobre o subdomínio que os seus clientes usam;
• se o formulário de contacto ainda envia alguma coisa a alguém.

Responder a estas perguntas pressupõe carregar as suas páginas e saber o que lá deveria estar. Não é o ofício dele, e honestamente não deveria ser: um alojamento que inspeccionasse o conteúdo das suas páginas levantaria outros problemas, bem mais incómodos.

Ler uma página de estado sem cair na armadilha

Uma página de estado verde não diz «o seu site funciona». Diz «não declarámos nenhum incidente nos nossos serviços». Três nuances valem a pena.

É declarativa. Um incidente aparece quando alguém o escreve, muitas vezes depois de confirmação interna, por vezes com uma hora de atraso em relação ao momento em que você o viu.

É global. Um incidente que atinge trezentos servidores em cinquenta mil pode nunca lá figurar, o que é compreensível e não o consola se estiver entre os trezentos.

Não cobre os serviços vizinhos. O registrar, o fornecedor de correio, a CDN, o gateway de pagamento têm cada um a sua, e uma falha num deles lê-se no seu site sem aparecer em lado nenhum no seu alojamento.

O caso da gestão contratada

Existem contratos que cobrem realmente a aplicação: gestão contratada, suporte gerido, ofertas com compromisso de disponibilidade aplicacional. Custam mais, e por vezes cumprem a promessa.

Duas verificações antes de contar com isso. Leia o que o contrato vigia exatamente: «supervisão 24/7» designa quase sempre a infraestrutura, não as suas páginas. E pergunte o que desencadeia uma intervenção: um limiar de carga não é o mesmo que um código HTTP inesperado na sua página inicial.

O teste que decide cabe numa pergunta ao suporte: se a minha página inicial devolver um erro 500 durante duas horas num domingo, alguém aí dá por isso? A resposta é instrutiva, seja ela qual for.

O que pode razoavelmente esperar do seu alojamento

O objetivo deste artigo não é fazer-lhe um julgamento. Presta um serviço preciso, e é útil saber qual, quanto mais não seja para não pagar duas vezes a mesma coisa.

Espere dele a disponibilidade da máquina, uma rede que responde, cópias de segurança que existem mesmo e se restauram mesmo, uma página de estado honesta, e um suporte capaz de dizer se o incidente vem do lado dele.

Não espere dele o conhecimento da sua aplicação, a verificação dos seus certificados aplicacionais, a revisão dos seus deploys, nem um alerta quando o seu conteúdo muda de forma.

Uma boa forma de resumir: o seu alojamento responde pela casa, você responde pelo que lá se passa dentro. Ambas as coisas são necessárias, e confundir os dois perímetros é a causa mais frequente de uma falha longa.

O teste de uma noite

Se não tem a certeza do que a sua instalação atual cobre, faça a experiência em vez da teoria. Num ambiente de pré-produção, provoque de propósito três falhas e veja quem o avisa, e em quanto tempo.

Pare o serviço aplicacional: deveria receber alguma coisa. Deixe expirar um certificado de teste: é aí que a maioria das instalações descobre o seu ponto cego. Por fim, parta uma única página deixando o resto do site de pé: é a falha mais frequente em produção, e aquela que quase nenhuma vigilância deteta por omissão.

O resultado deste exercício vale mais do que qualquer promessa comercial, incluindo a minha.

O ponto cego, no meio

Entre «a máquina está de pé» e «o site funciona» existe um espaço onde vive a maioria das falhas. Não os colapsos espetaculares: esses notam-se. Os discretos: um erro numa página, um certificado que expira num domingo, um formulário que deixa de enviar depois de uma atualização.

Ninguém vigia esse espaço por omissão. Nem o seu alojamento, cujo trabalho acaba antes. Nem os seus visitantes, que se vão embora em vez de escrever. E é precisamente aí que se joga o custo de uma falha, já que depende menos da falha em si do que do tempo que passou no ecrã.

Olhar de onde olham os seus visitantes

O único ponto de vista que corresponde à realidade é o de fora: carregar a página como um visitante, ler o código de resposta, verificar o certificado, e comparar com o que deveria acontecer.

É exatamente a diferença entre a vigilância de infraestrutura e a vigilância de site. As duas são complementares, não intermutáveis, e só uma delas lhe dirá que a sua página inicial está partida desde esta manhã. Falta decidir quem a põe de pé: um script seu ou um serviço externo, e a que ritmo a verificação deve correr.

Esta regra, aliás, não pára no seu servidor. Os links que outros sites lhe deram desaparecem exatamente da mesma forma, sem que ninguém lhe escreva e sem que nenhum relatório o mostre: o mesmo ponto cego, uma camada mais além.

E no dia em que o alerta chegar, não lhe dirá o que fazer: os primeiros quinze minutos continuam a ser os mesmos, com ou sem alojamento ao telefone.