Erkenntnisse aus dem Betrieb mehrerer OpenClaw-Gateways in der Produktion

Produktionsausfälle und ihre Ursachen

Ein Entwickler, der 3+ OpenClaw-Gateways rund um die Uhr für den persönlichen Gebrauch, eine gemeinnützige Organisation und eine Gemeinschaftseinrichtung betreibt, erlebte wiederholte Produktionsausfälle, weil Änderungen an OpenClaw wie Skizzenarbeit statt wie Produktionsbereitstellungen behandelt wurden.

Spezifische Fehlerszenarien

Das Upgrade, das nicht sterben wollte: Das Ausführen von pnpm add -g openclaw@latest führte zum Absturz des Gateways mit MODULE_NOT_FOUND, weil die neue Version in einem anderen Pfad installiert wurde, während die Dienstdatei den alten Pfad hartkodiert hatte. Ein Rettungsskript, das alle 5 Minuten neu startete, konnte nicht zwischen vorübergehenden Abstürzen (bei denen ein Neustart funktioniert) und strukturellen Fehlern (die zuerst eine Korrektur der Dienstdatei erfordern) unterscheiden.

Stiller Funktionsverlust: Nach der Konfiguration neuer Integrationen und dem Neustart des Gateways schienen Funktionen wie Text-zu-Sprache für Barrierefreiheit, E-Mail-Versand und X.com-Beiträge konfiguriert zu sein, waren aber aufgrund von API-Schlüsseln in falschen Konfigurationsabschnitten oder abgelaufenen Zugangsdaten tatsächlich defekt. Diese Fehler blieben tagelang unentdeckt.

Ursachenanalyse

Die Konfiguration des OpenClaw-Gateways ist auf mindestens fünf Orte verteilt:

• Haupt-JSON-Datei
• Umgebungsvariablen in Dienstdateien
• Docker-Flags
• Anbieterblöcke
• Skills mit eigenen Zugangsdaten

Das Rotieren eines Schlüssels an einem Ort lässt andere veraltet. Ein Upgrade von OpenClaw bricht hartkodierte Pfade. Das Aktualisieren eines Skills führt dazu, dass Zugangsdaten stillschweigend nicht mehr geladen werden. Dies sind Regressionen, die CI/CD in der Softwareentwicklung erkennen würde, aber es gab keine CI für die Gateway-Infrastruktur.

Umsetzung der Lösung

Funktionsaudit: Vor und nach jeder Änderung:

• Konfiguration parsen, um beanspruchte Funktionen aufzulisten
• Jede Funktion mit Live-API-Tests überprüfen (5-Sekunden-Timeout)
• Vorher/Nachher-Snapshots vergleichen

Konfigurationsvalidierungsprüfung: Keine direkten Bearbeitungen der Live-Konfiguration:

• JSON-Gültigkeitsprüfung
• Zeitgestempelte Backups
• Blockiert bekannte gefährliche Muster

Reproduzierbare Umgebung:

• Versionsunabhängige Dienstdateien (keine hartkodierten Pfade)
• Eine kanonische Zugangsdatendatei, von der alles andere abgeleitet wird
• Absturzschleifenerkennung (3 Fehler = Diagnosemodus, kein Neustartmodus)

Regressionsdetektor:

• Täglicher Vergleich mit einer bekannten guten Basis
• Änderungen als Verbesserung vs. Verschlechterung klassifizieren
• Bei Funktionsverlust alarmieren

Der Entwickler teilt diese Arbeit frühzeitig und fragt andere KI-Infrastrukturbetreiber: "Wie handhabt ihr das Gateway-Management?" und "Was ist eure Teststrategie für euren OpenClaw?"