Von 25 Fehlern in vier Wochen hat meine Überwachung vier erkannt und darauf reagiert. Darüber, die Sache zu prüfen statt der Behauptung – und darüber, wer die Prüfungen prüft.
Am 2. September habe ich Claude mein System komplett durchsehen lassen: fünf Audits, die nur lesen durften, darunter ein Rückblick auf neunzig Tage Fehler. Laut meinen Notizen bescheinigte das Speicher-Audit meinem Dokumentenarchiv eine zweite Kopie: Ein wöchentlicher Job kopierte es auf den Heimserver.
Am selben Abend wurde der Job selbst geprüft. Er war kein einziges Mal erfolgreich gewesen. Seit Mitte Juli war er jeden Sonntag pünktlich gestartet, hatte versucht, einen Ordner anzulegen, für den ihm die Rechte fehlten, und hatte aufgegeben, bevor er sein Log öffnete. Kein Fehler, kein Alarm.
Vier von fünfundzwanzig
Eine Retrospektive hatte am 5. August für die vier Wochen ab dem 7. Juli 25 belegbare Fehler gefunden. Sechs davon erkannte eine Maschine: Auf vier reagierte sie, bevor jemand etwas merkte, auf zwei reagierte niemand. Sieben bemerkte ein Mensch, zwölf wurden durch Zufall entdeckt. Zwei Jobs verschickten derweil in acht Tagen rund 56 falsche Fehleralarme.
In derselben Nacht hat ein headless Claude-Lauf (ohne jemanden an der Tastatur) auf Yavin* eine Regressions-Suite gebaut: 136 wöchentliche Prüfungen für das, was früher funktioniert hat und jetzt nicht mehr. Eine Entwicklungsaufgabe ist seitdem erst erledigt, wenn ein Lauf grün ist oder seine roten Ergebnisse erklärt sind.
Active, sagte systemd
Am 26. Juli war das Telegram-Gateway, mein Alarmkanal, rund zwölf Stunden tot; am 28. Juli hing die Notiz-Synchronisation rund fünfzehn Stunden fest. systemd (der Dienstverwalter von Linux) meldete beide die ganze Zeit als „active“. Das sagt nur, ob ein Prozess lebt, nicht, ob er seine Arbeit tut.
Am 29. Juli hat Claude einen Watchdog gebaut, der nach Belegen für Arbeit sucht, etwa nach der Zeile „fully synced“ im Log der Synchronisation. Beim Gateway prüfte er nur den Prozess, und der lebte ab dem 30. Juli zwei Tage lang untätig weiter.
Behauptungen, als erledigt notiert
Manche grünen Haken werden von Hand gesetzt, oft von Claude. Am 13. Mai meldete das morgendliche Stand-up 129 überfällige Aufgaben; tatsächlich waren es null.
Im September habe ich die Secrets meiner Automationen in einen Speicher umgezogen, den Maschinen unbeaufsichtigt lesen. Am 17. September bestanden seine Fallback-Tests (der Ausweichweg, wenn der Speicher nicht erreichbar ist) sieben von sieben, in je 0,00 Sekunden: Sie hatten das Netz nie berührt, und Claude hat sie in derselben Sitzung korrigiert. Am Nachmittag hielt die Aufgabennotiz fest, der Speicher sei „flipped live … verified for real“. Eine Korrektur vom 25. September stellte klar, dass er auf zwei Rechnern für keinen einzigen Dienst live gewesen war: Der Gesundheitscheck hatte die zusammengeführte Konfiguration gelesen, also die Behauptung. Dank des Fallbacks ging nichts kaputt. Am 9. Oktober wurde die Umstellung überprüft: Speicher aus, wieder ein, und dabei zusehen, was die Rechner luden.
Neunzig Tage und ein Monitor für Abwesenheiten
Die Durchsicht ergab, dass meine drei wichtigsten harten Regeln gehalten hatten: null Verstöße in 635 archivierten Sitzungen. Der Schaden lag bei Dingen, die lautlos stehen blieben, etwa bei einem Wächter, der im Juli neun Tage lang alle zwei Stunden abstürzte und seinen eigenen Ausfall nicht melden konnte.
Am 3. September hat Claude einen Abwesenheitsmonitor gebaut: eine Liste der erwarteten Jobs mit ihrem Rhythmus, wöchentlich darauf geprüft, ob jeder eine Spur hinterlassen hat. Er hat sich seitdem in beide Richtungen geirrt: Am 2. Oktober hielt er einen fehlschlagenden Job für in Ordnung, weil er nur prüfte, ob der Timer ausgelöst hatte; am 9. Oktober meldete er drei Jobs als fehlend, die gelaufen waren – der wöchentliche Neustart hatte die Spuren gelöscht. Beides ist behoben.
Das Muster
Prüf die Sache, nicht die Behauptung; niemand bewacht die Wächter; und ein geplanter Job ist fertig, wenn sein Timer ausgelöst hat, nicht wenn er einmal von Hand geklappt hat. Eine Behauptung kann von überall kommen: aus einem Dienststatus, einem bestandenen Test, einem Audit, einer Aufgabennotiz von vor einer Stunde. Jede Prüfung ist selbst eine Behauptung und muss aus dem richtigen Grund rot werden können. Zwei Backup-Umzüge, im Juli als laufend notiert, waren einmalige Kopien.
Viele dieser Behauptungen hat Claude geschrieben – und auch die Prüfungen gebaut, die 0,00 Sekunden bemerkt und die Korrekturen verfasst. Inzwischen verlange ich neben „erledigt“ auch „wie geprüft“.
Fertig ist das nicht. Am Ende der Kette stehe ich und lese eine wöchentliche Zusammenfassung der Regressionsläufe auf Telegram; die letzte vor diesem Text war rot. Nichts schlägt Alarm, wenn der Heimserver selbst nicht mehr antwortet: Jeder Watchdog läuft auf ihm.
Teil 6 von zwölf in der Serie darüber, wie ich mein AI OS gebaut habe. Der Anfang: das Vorwort.
Als Nächstes: eine Regel in Großbuchstaben, die trotzdem wieder gebrochen wurde – und wo Regeln wirklich wohnen.
* Rechnernamen sind geändert (hier: Yavin, mein Heimserver). Die echten stammen aus einer anderen Saga.
Anhang – für alle, die selbst bauen
- Zähl, wie deine Fehler gefunden wurden. Von einer Maschine erkannt und darauf reagiert, erkannt und ignoriert, von einem Menschen bemerkt, durch Zufall gefunden: Bei mir waren es 4, 2, 7 und 12 von 25.
- Prüf Belege für Arbeit, nicht einen lebenden Prozess. Eine Heartbeat-Zeile im Log, eine geänderte Datei, eine angekommene Nachricht.
- Leg die Prüfung in derselben Änderung an wie den Job. Führ eine Liste der erwarteten Jobs mit ihrem Rhythmus; ein Job, der in seinem Zeitfenster keine Spur hinterlässt, ist ein Befund. Mein neuester Wächter fiel zwei Tage nach dem Start aus und bekam seine eigene Prüfung drei Wochen später.
- Misstrau einem Test, der zu schnell ist. Lass jede neue Prüfung einmal aus dem richtigen Grund rot werden, bevor du ihrem Grün traust.
- Schreib „wie geprüft“ neben „erledigt“. Bei geplanter Arbeit heißt das: Der Timer existiert, hat zweimal ausgelöst, und ein Monitor hat den zweiten Lauf gesehen.
- Gib der Kette ein menschliches Ende. Eine Zeile, die du jede Woche erwartest; bleibt sie aus, ist der Prüfer selbst der Fehler.
- Was ich stattdessen erwogen habe: mehr Alarme auf dem vorhandenen Monitor (er schickte schon überwiegend falsche), die Neustart-Regeln von systemd (sie greifen nur, wenn ein Prozess endet, und diese endeten nicht) und ab und zu ein großes Audit (die Durchsicht im September fand die Archivkopie sieben Wochen zu spät). Ich habe mich für eine wöchentliche Regressions-Suite und einen Abwesenheitsmonitor entschieden: Beide prüfen Belege nach festem Plan, und eine wöchentliche Zeile, die ich lese, hält sie ehrlich.