Nichts lehrt dich so viel über ein System, wie ihm beim Scheitern zuzusehen. Ein paar Lieblingsgeschichten:
Als ich alles selbst lahmgelegt habe. Damit eine langsame Seite nicht alle anderen aufhält, habe ich das Rendern der Seiten auf einen Pool von Worker-Threads verlagert. Um dann zu prüfen, ob Website-Umzüge ohne Ruckler ablaufen, habe ich eine Flut von Testtraffic auf die Live-Websites losgelassen. Sie froren neun Minuten lang ein und blieben auch eingefroren, nachdem der Traffic aufgehört hatte. Jede Seite hielt eine Datenbankverbindung fest, während sie eine zweite anforderte, und bei Dutzenden Threads und einem Pool von fünfzehn Verbindungen wartete am Ende jeder Thread auf einen anderen. Währenddessen meldete der Gesundheitscheck, der die Datenbank nie anrührte, fröhlich, alles sei in Ordnung.
Die Lösung: Datenbank-Pools, die sich nicht gegenseitig blockieren können, ein Limiter, der eine Überlastung in ein schnelles „Versuch's gleich noch mal“ statt in einen Hänger verwandelt (mit einem fairen Anteil für jede Website, damit eine gut besuchte Website die anderen nicht aushungern kann), ein Gesundheitscheck, der einen hängenden Prozess bemerkt, ein Watchdog, der ihn neu startet, und eine feste Regel, wo Lasttests stattfinden.
Der 45-Sekunden-Schluckauf. Die meisten Website-Umzüge liefen nahtlos, eine Art aber nicht: Wenn der Umzug die Routing-Regeln der Website änderte, beschrieben die alte und die neue Kopie kurzzeitig dieselbe Route auf zwei verschiedene Weisen. Die Eingangstür konnte sich nicht entscheiden, wem sie glauben sollte, und bediente etwa 45 Sekunden lang keine von beiden. Alles andere am Umzug war korrekt – genau deshalb hat es eine Weile gedauert, den Fehler zu finden.
Eine winzige Website bei 100 % CPU. Ein kleiner Shop mit ein paar Hundert Besuchern am Tag lastete ständig seinen Prozessor voll aus. Schuld waren nicht die Kunden, sondern automatisierte Scanner, die mehr als hundert Anfragen in zehn Sekunden abfeuerten, auf der Suche nach Dateien wie /.env oder /wp-login.php, die eine FolioPress-Website nie hat. Jede bekam eine schöne, komplett gestaltete „Seite nicht gefunden“: etwa 70 ms Arbeit, hundertfach.
Die Lösung: Diese Anfragen bekommen jetzt ein neun Byte großes „Not found“, bevor irgendeine echte Arbeit passiert, und Cloudflare weist die meisten schon ab, bevor sie überhaupt ankommen.
„Server nicht gefunden“ für eine Website, die lief. Die Webadresse einer brandneuen Website wird bei der Einrichtung angelegt. Hat irgendetwas den Namen einen Moment zu früh nachgeschlagen, merkten sich Internetanbieter bis zu dreißig Minuten lang „diesen Namen gibt es nicht“, obwohl die Website einwandfrei funktionierte. Die Lösung war eine Wildcard-Adresse, sodass jeder Name unter foliopress.io immer existiert; Namen ohne Website bekommen eine freundliche „Hier gibt es keine Website“-Seite.
Nachbarn. Viele Websites Tür an Tür zu hosten, wirft Fragen auf, die sich eine einzelne Website nie stellen muss: was der Code einer Website einer anderen antun kann und was eine Website für sich beanspruchen kann, das ihr nicht gehört. Ein Sicherheitsreview vor dem Start der Registrierung hat ein paar solcher Fälle zutage gefördert. Alle sind behoben: strengere Cookies, ein Eigentumsnachweis für eigene Domains und jede Website in ihrem eigenen, separaten Ordner eingehängt, sodass keine Website an die Dateien einer anderen herankommt.