Niente ti insegna com'è fatto un sistema quanto guardarlo andare in pezzi. Alcune delle mie preferite:
La volta in cui ho buttato giù tutto da solo. Per evitare che una pagina lenta rallentasse tutte le altre, ho spostato il rendering delle pagine su un pool di thread di lavoro. Poi, per verificare che i traslochi dei siti filassero lisci, ho scaricato un'ondata di traffico di prova sui siti in produzione. Si sono bloccati per nove minuti e sono rimasti bloccati anche dopo che il traffico si era fermato. Ogni pagina teneva occupata una connessione al database mentre ne chiedeva una seconda e, con decine di thread e un pool di quindici connessioni, ogni thread ha finito per aspettarne un altro. Nel frattempo il controllo di salute, che non toccava mai il database, riferiva allegramente che andava tutto bene.
La soluzione: pool di database che non possono andare in deadlock, un limitatore che trasforma un sovraccarico in un rapido «riprova» invece che in un blocco (con una quota equa per ogni sito, così un sito trafficato non può affamare gli altri), un controllo di salute che si accorge di un processo bloccato, un watchdog che lo riavvia e una regola ferma su dove si fanno i test di carico.
Il singhiozzo di 45 secondi. La maggior parte dei traslochi filava liscia, ma un tipo no: se il trasloco cambiava le regole di instradamento del sito, la copia vecchia e quella nuova descrivevano per un attimo la stessa rotta in due modi diversi. La porta d'ingresso, incapace di decidere a quale credere, non ne serviva nessuna per circa 45 secondi. Tutto il resto del trasloco era corretto, ed è proprio per questo che ci è voluto un po' per accorgersene.
Un sito minuscolo al 100% di CPU. Un piccolo negozio con qualche centinaio di visitatori al giorno continuava a mandare il processore al massimo. I colpevoli non erano i clienti, ma scanner automatici che sparavano più di cento richieste in dieci secondi, a caccia di file come /.env o /wp-login.php che un sito FolioPress non ha mai. Ognuna riceveva una bella pagina «non trovata», curata in ogni dettaglio: circa 70 ms di lavoro, moltiplicati per cento.
La soluzione: ora quelle richieste ricevono un «Not found» di nove byte prima che parta qualsiasi lavoro vero, e Cloudflare respinge la maggior parte di esse prima ancora che arrivino.
«Server non trovato» per un sito che era online. L'indirizzo web di un sito nuovo di zecca viene creato durante la configurazione. Se qualcosa cercava il nome un attimo troppo presto, i provider internet si ricordavano che «questo nome non esiste» per un massimo di trenta minuti, anche se il sito funzionava benissimo. La soluzione è stata un indirizzo jolly (wildcard), così ogni nome sotto foliopress.io esiste sempre; i nomi senza un sito ricevono una pagina cordiale che dice «qui non c'è nessun sito».
I vicini. Ospitare tanti siti fianco a fianco solleva domande che un sito singolo non deve mai porsi: cosa può fare il codice di un sito a un altro, e cosa può rivendicare un sito che non è suo. Una revisione di sicurezza prima di aprire le iscrizioni ha fatto emergere alcuni di questi problemi. Sono stati tutti risolti: cookie più restrittivi, prova di proprietà per i domini personalizzati e ogni sito montato nella propria cartella separata, così nessun sito può raggiungere i file di un altro.