Plattform
Zuverlässigkeit und Selbstheilung
Ein separater Wächterprozess beobachtet das Produkt, behebt Routinefehler selbst und eskaliert den Rest mit den Belegen im Anhang. Innerhalb des Produkts ist jede Sendung und Zustellung dauerhaft.
Prüfungen
Die meisten Prüfungen müssen zweimal hintereinander fehlschlagen, bevor ein Vorfall eröffnet wird; ein gestoppter Container oder eine beschädigte Datenbank wirken beim ersten Fehlschlag. Eine bestandene Prüfung setzt den Zähler für jeden Vorfalltyp zurück, den sie auslösen kann.
| P1 | Liveness-Endpunkt antwortet innerhalb von drei Sekunden |
|---|---|
| P2 | detaillierte Gesundheit: Datenbank erreichbar, Chat-Listener verbunden (mit Startkulanz nach Neustarts) |
| P3 | Aktualität des Listeners |
| P4 | der Live-Ereignisstrom |
| P5 | Container läuft und ist gesund |
| P6 | Festplattendruck |
| P7 | Ablauf des TLS-Zertifikats |
| P8 | ein Logik-Kanarienvogel |
| P9 | Datenbank-Schnellprüfung |
Das Playbook
- Dienst oder Listener ausgefallen: Container neu starten und auf Gesundheit warten; zeigen die Logs ein ungültiges Chat-Token, mit dem Auszug eskalieren, statt stillschweigend ein Token umzuschreiben.
- Listener zweimal innerhalb einer Stunde veraltet: eskalieren, da das nach einer Regression aussieht und nicht nach einem Aussetzer.
- Ereignisstrom oder API ausgefallen: die Proxy-Konfiguration neu laden, wenn sie validiert, den Container neu starten und, falls in den letzten 24 Stunden ein Deployment stattfand, es als Rollback-Kandidaten markieren.
- Festplattendruck: das Journal bereinigen, Logs rotieren, Wächterzustand aufräumen.
- Zertifikat läuft ab: erneuern und den Proxy neu laden.
- Anti-Flapping: Tritt derselbe Vorfall in 24 Stunden häufiger auf als konfiguriert, stoppt die automatische Heilung und eskaliert.
Mehr als Neustarts
- Eine tägliche Zusammenfassung fasst Vorfälle und Maßnahmen zusammen.
- Ein wöchentlicher synthetischer End-to-End-Durchlauf übt die echten Abläufe gegen Staging.
- Eine Logikwache führt die eigene Testsuite des Produkts gegen den bereitgestellten Code in einem schreibgeschützten Container aus und vergleicht mit der grünen Basislinie: Ein Test, der grün war und jetzt rot ist, ist eine Regression; ein roter Test, der nicht in der Basislinie ist, ist eine Benachrichtigung, keine Maßnahme.
- Eine autonome Fix-Pipeline kann eine bestätigte Regression durch einen eingegrenzten Patch, lokale Tests, einen Branch, CI, Staging, den synthetischen Durchlauf, Merge und Produktion führen, mit Gesundheitsschranke und automatischem Rollback. Sensible Geheimnisse werden aus ihrer Umgebung entfernt, und verbotene Pfade werden abgelehnt.
- Der Wächter läuft unter einem Dienst-Supervisor mit Watchdog, sodass eine hängende Schleife neu gestartet wird, nicht nur eine abgestürzte.
Innerhalb des Produkts
- Eine dauerhafte Bot-Outbox: Genehmigungsnachrichten, Raumhinweise und deren Entfernung werden in die Datenbank geschrieben und von der Schleife abgearbeitet, sodass eine Entscheidung, die bei ausgefallenem Bot getroffen wurde, dennoch zugestellt wird.
- Webhooks wiederholen mit Backoff und einem Schutzschalter je Endpunkt.
- Ein nächtlicher Abgleich vergleicht die Ereignisliste des Homeservers mit dem eigenen Nachrichtenprotokoll des Bots und erfasst jede Nachricht, die nie angekommen ist; eine Lücke schließt sich, wenn die Nachricht später auftaucht, und ein unvollständiger Abgleich wird als unvollständig protokolliert, nicht als sauber.
- Ein Materialisierungs-Watchdog warnt Admins, wenn die neueste zwischengespeicherte Bewertung älter als 26 Stunden ist oder das Fenster unzureichend abgedeckt ist.
- Der KI-Failsafe wechselt den Anbieter, wenn der aktive nicht mehr antwortet.
- Jeder bewertende Job läuft außerhalb der Ereignisschleife, sodass ein langer Durchlauf den Bot nie einfrieren kann; das wird durch einen Test abgesichert.