Un client signale que l'application est cassée mais vous n'arrivez pas à reproduire. Que regardez-vous ?

Commencez par les détails précis : quel compte, à quelle heure, quelle action, ce qu'il a vu. Ensuite suivez cette requête à travers les logs, les traces et les rapports d'erreur avec un identifiant de requête ou de trace partagé, pour voir tout le chemin plutôt qu'un seul service. Comparez le taux d'erreur et la latence à la même fenêtre la veille pour séparer une vraie régression du bruit de fond. Si rien n'apparaît, le manque est dans l'instrumentation, donc ajoutez des logs structurés sur ce chemin.

La première chose que je fais, c'est transformer le signalement en quelque chose de cherchable : identifiant de compte, horodatage approximatif avec un fuseau, quel bouton, ce qui est apparu à l'écran. Les signalements vagues restent insolubles, donc cette conversation vaut cinq minutes. Ensuite je vais à la trace d'une requête dans cette fenêtre et je la suis à travers les services, parce qu'une ligne de log d'un seul service dit rarement si l'échec venait de chez nous, de la base ou d'un tiers. En parallèle je regarde le taux d'erreur et la latence par rapport à la même heure la veille, puisqu'un pic qui démarre à l'heure d'un déploiement connu est en général toute la réponse. Une chose que j'ai appris à vérifier tôt, c'est si c'est environnemental : une seule région, un seul navigateur, un service worker périmé qui sert de vieux assets, ou un proxy d'entreprise qui supprime un en-tête. Si rien n'est visible nulle part, j'arrête de chasser et je traite ça comme la découverte, puis j'ajoute des logs structurés avec l'identifiant de requête, l'identifiant utilisateur et les branches de décision sur ce chemin pour que le prochain signalement prenne des minutes. Les logs reçoivent des identifiants, jamais des tokens ni des données personnelles.