Was uns über 2.000 Discord Server beigebracht haben

Ein Discord Bot auf drei Servern und derselbe Bot auf über zweitausend sind nicht dasselbe Programm in groß. Ein paar Annahmen, die im Kleinen völlig harmlos sind, werden ab einer bestimmten Größe zu genau den Fehlern, die man am schwersten findet.

Hier vier davon, die uns echte Ausfälle gekostet haben.

1. Fehler verteilen sich nicht gleichmäßig, sie verstecken sich

AlphaCloud läuft aufgeteilt auf mehrere Prozesse, sogenannte Shards. Discord legt fest, welcher Server auf welchem Shard landet, und jeder Shard kennt nur seine eigenen Server.

Das führt zu einer Fehlerklasse, die von außen aussieht wie Zufall: Auf einem Teil der Server funktionieren Willkommensnachrichten, auf einem anderen nicht. Kein Fehler im Log, keine Meldung, nichts. Der Grund war ein einzelner Netzwerkaufruf ohne Zeitlimit. Nimmt die Gegenseite die Verbindung an und antwortet dann nie, wartet der Code für den Rest der Laufzeit des Prozesses. Alles, was danach kommt, passiert nicht mehr, und weil kein Fehler geworfen wird, meldet auch nichts einen Fehler.

Die Lehre daraus ist unspektakulär und gilt überall: jeder ausgehende Aufruf braucht eine Obergrenze. Ein Aufruf, der ewig wartet, ist schlimmer als einer, der scheitert, weil ein Scheitern wenigstens sichtbar ist.

2. Ein Neustart ist keine Lösung, sondern eine Frist

Als wir die Ursache noch nicht kannten, half ein Neustart des betroffenen Shards zuverlässig. Genau das ist das Problem an Neustarts: sie funktionieren, und dadurch verschwindet der Druck, die Ursache zu suchen.

Inzwischen behandeln wir "hilft ein Neustart?" als Diagnose, nicht als Behebung. Wenn ja, lebt der kaputte Zustand im Arbeitsspeicher, und dann gibt es eine Stelle im Code, die ihn aufbaut und nie wieder abbaut.

Der Umkehrschluss gilt auch: alles, was einen Neustart überleben muss, gehört in die Datenbank. Läuft eine mehrstufige Aktion gerade, zum Beispiel ein Rollenumbau über tausende Mitglieder, und der Prozess stirbt mittendrin, darf die Aktion nicht einfach weg sein. Sie muss beim nächsten Start erkannt und fortgesetzt werden.

3. Die Grenzen von Discord gelten pro Bot, nicht pro Prozess

Discord begrenzt, wie viele Anfragen ein Bot pro Sekunde stellen darf. Naheliegende Annahme: mehr Prozesse, mehr Durchsatz. Falsch. Das Limit hängt am Bot, nicht am Prozess. Drei Shards mit jeweils vollem Budget ergeben zusammen das Dreifache des Erlaubten, und Discord bremst dann alle drei.

Also rechnet bei uns jeder Prozess aus, wie viele es insgesamt gibt, und nimmt sich nur seinen Anteil. Das klingt selbstverständlich, war es aber nicht, und der Fehler war lange unsichtbar, weil jeder einzelne Prozess für sich betrachtet brav im Limit blieb.

Eine verwandte Falle: wiederkehrende Aufgaben laufen bei uns in festen Abständen, etwa alle fünf Minuten. Wenn alle Shards gleichzeitig starten, feuern sie ihre Aufgaben für immer im selben Moment. Seitdem bekommt jeder Prozess beim Start einen zufälligen Versatz.

4. Was Leute wirklich einstellen, ist nicht, was man erwartet

Der technische Teil ist die eine Hälfte. Die andere: Die Voreinstellung ist für die meisten Server die Einstellung. Ein Modul, dessen Standardwerte falsch sind, ist auf den allermeisten Servern falsch konfiguriert, egal wie gut die Einstellungsseite ist.

Daraus folgt für uns zweierlei. Erstens kostet jede Voreinstellung mehr Nachdenken als die Einstellung selbst. Zweitens ist die bessere Frage bei einem neuen Modul nicht "was kann man hier alles einstellen", sondern "was tut das Modul, wenn niemand etwas einstellt, und ist das für einen normalen Server richtig".

Das ist auch der Grund für eine Entscheidung, die sich zunächst nach dem Gegenteil anhört: Mit v1.8.0 kann inzwischen fast jede Nachricht des Bots frei gestaltet werden. Aber Pflichtbausteine wie der Grund in einer Verwarnungs DM oder das Kategorienmenü in einem Ticketpanel lassen sich verschieben und nicht löschen. Gestaltungsfreiheit ja, aber nicht bis zu dem Punkt, an dem ein Server sich aus Versehen etwas baut, das aussieht wie es funktioniert und es nicht tut.

Der gemeinsame Nenner

Drei der vier Punkte sind derselbe Gedanke in verschiedenen Kostümen: Bei dieser Größe ist ein stiller Fehlschlag teurer als ein lauter. Ein Absturz wird gemeldet und behoben. Eine Funktion, die einfach nichts mehr tut, kann monatelang so bleiben, und man erfährt davon durch einen Bug Report von jemandem, der sich die Mühe gemacht hat, zu schreiben.

Deshalb ist die Frage, die wir uns bei neuem Code inzwischen als erstes stellen, nicht "funktioniert das", sondern "wie sieht es aus, wenn es nicht funktioniert, und würden wir es merken".