Rien ne vous apprend autant sur un système que de le regarder tomber en panne. Petit florilège :
La fois où j'ai tout fait tomber moi-même. Pour qu'une page lente ne retarde pas toutes les autres, j'ai confié le rendu des pages à un pool de threads. Ensuite, pour vérifier que les déménagements de sites se faisaient sans accroc, j'ai envoyé un déluge de trafic de test sur les sites en production. Ils se sont figés pendant neuf minutes, et sont restés figés après l'arrêt du trafic. Chaque page gardait une connexion à la base de données tout en en demandant une deuxième ; avec des dizaines de threads et un pool de quinze connexions, chaque thread a fini par en attendre un autre. Pendant ce temps, le bilan de santé, qui ne touchait jamais à la base de données, annonçait joyeusement que tout allait bien.
La solution : des pools de base de données qui ne peuvent pas s'interbloquer, un limiteur qui transforme une surcharge en un rapide « réessayez » plutôt qu'en blocage (avec une part équitable pour chaque site, afin qu'un site très fréquenté ne puisse pas affamer les autres), un bilan de santé qui repère un processus coincé, un watchdog qui le redémarre et une règle ferme sur l'endroit où se font les tests de charge.
Le hoquet de 45 secondes. La plupart des déménagements de sites se passaient sans accroc, sauf un type : si le déménagement modifiait les règles de routage du site, l'ancienne et la nouvelle copie décrivaient brièvement la même route de deux façons différentes. La porte d'entrée, incapable de décider laquelle croire, n'en servait aucune pendant environ 45 secondes. Tout le reste du déménagement était correct, et c'est justement pour ça qu'il a fallu du temps pour repérer le problème.
Un site minuscule à 100 % de CPU. Une petite boutique de quelques centaines de visiteurs par jour saturait sans cesse son processeur. Le coupable n'était pas la clientèle, mais des scanners automatiques qui envoyaient plus de cent requêtes en dix secondes, à la recherche de fichiers comme /.env ou /wp-login.php qu'un site FolioPress n'a jamais. Chacune recevait une belle page « introuvable » entièrement mise en forme : environ 70 ms de travail, multipliées par cent.
La solution : ces requêtes reçoivent désormais un « Not found » de neuf octets avant tout vrai travail, et Cloudflare refoule la plupart d'entre elles avant même qu'elles n'arrivent.
« Serveur introuvable » pour un site en ligne. L'adresse web d'un tout nouveau site est créée pendant sa mise en place. Si quoi que ce soit cherchait le nom un instant trop tôt, les fournisseurs d'accès retenaient « ce nom n'existe pas » jusqu'à trente minutes, alors que le site fonctionnait parfaitement. La solution : une adresse générique (wildcard), pour que tout nom sous foliopress.io existe toujours ; les noms sans site reçoivent une page sympathique « il n'y a pas de site ici ».
Les voisins. Héberger beaucoup de sites côte à côte soulève des questions qu'un site isolé n'a jamais à se poser : ce que le code d'un site peut faire à un autre, et ce qu'un site peut revendiquer qui ne lui appartient pas. Un audit de sécurité avant l'ouverture des inscriptions a mis au jour quelques problèmes de ce genre. Tous sont corrigés : des cookies plus stricts, une preuve de propriété pour les domaines personnalisés, et chaque site monté dans son propre dossier séparé, pour qu'aucun site ne puisse atteindre les fichiers d'un autre.