Nada ensina tanto sobre um sistema como vê-lo falhar. Alguns dos meus favoritos:
A vez em que deitei tudo abaixo sozinho. Para evitar que uma página lenta atrasasse todas as outras, passei a renderização das páginas para um conjunto de threads de trabalho. Depois, para confirmar que as mudanças de sites corriam sem soluços, lancei uma enxurrada de tráfego de teste contra os sites em produção. Ficaram congelados durante nove minutos, e continuaram congelados depois de o tráfego parar. Cada página segurava uma ligação à base de dados enquanto pedia uma segunda e, com dezenas de threads e um pool de quinze ligações, todas as threads acabaram à espera de outra. Entretanto, a verificação de saúde, que nunca tocava na base de dados, relatava alegremente que estava tudo bem.
A solução: pools de base de dados que não podem bloquear-se mutuamente, um limitador que transforma uma sobrecarga num rápido «tente novamente» em vez de um bloqueio (com uma quota justa para cada site, para que um site movimentado não deixe os outros à fome), uma verificação de saúde que repara num processo encravado, um watchdog que o reinicia e uma regra firme sobre onde se fazem testes de carga.
O soluço de 45 segundos. A maioria das mudanças de sites corria sem falhas, mas havia um tipo que não: se a mudança alterava as regras de encaminhamento do site, a cópia antiga e a nova descreviam por breves instantes a mesma rota de duas maneiras diferentes. A porta de entrada, sem conseguir decidir em qual acreditar, não servia nenhuma durante cerca de 45 segundos. Todas as outras partes da mudança estavam corretas, e foi precisamente por isso que demorou a detetar.
Um site minúsculo a 100% de CPU. Uma pequena loja com umas centenas de visitantes por dia esgotava constantemente o processador. Os culpados não eram os clientes, eram scanners automáticos a disparar mais de cem pedidos em dez segundos, à procura de ficheiros como /.env ou /wp-login.php que um site FolioPress nunca tem. Cada um recebia uma página «não encontrada» bonita e com design completo: cerca de 70 ms de trabalho, cem vezes seguidas.
A solução: esses pedidos recebem agora um «Not found» de nove bytes antes de qualquer trabalho a sério, e a Cloudflare trava a maioria deles antes de chegarem.
«Servidor não encontrado» para um site que estava no ar. O endereço web de um site novinho em folha é criado durante a configuração. Se alguma coisa procurasse o nome um instante cedo demais, os fornecedores de internet memorizavam «este nome não existe» durante até trinta minutos, mesmo com o site a funcionar perfeitamente. A solução foi um endereço wildcard que apanha todos os nomes, para que qualquer nome sob foliopress.io exista sempre; os nomes sem site recebem uma página simpática a dizer «não há nenhum site aqui».
Vizinhos. Alojar muitos sites lado a lado levanta perguntas a que um site isolado nunca tem de responder: o que o código de um site pode fazer a outro, e o que um site pode reclamar que não é seu. Uma revisão de segurança antes de abrir os registos encontrou alguns destes problemas. Estão todos corrigidos: cookies mais rigorosos, prova de propriedade para domínios personalizados e cada site montado na sua própria pasta separada, para que nenhum site consiga chegar aos ficheiros de outro.