Un acheteur affirme avoir payé, mais sa commande reste « en attente ». L’équipe technique trouve des requêtes HTTP en succès, paiement voit une capture chez le prestataire et support ne dispose que du numéro de ticket. Trois heures sont perdues à rapprocher des horodatages avant de découvrir un événement de commande rejeté. Pendant ce temps, le client relance, la finance hésite à rembourser et le vendeur ignore s’il doit préparer l’envoi.
Le problème vient d’une observabilité centrée sur les composants. CPU, latence et codes d’erreur sont nécessaires, mais ils ne disent pas quel dossier est touché, quelle promesse a échoué ni quels clients doivent être réparés. Les équipes possèdent des signaux sans chronologie commune.
Le vrai enjeu de l’observabilité métier d’une marketplace opérateur est de relier une intention aux états et effets qui la réalisent. Contre-intuitivement, instrumenter moins de champs mais imposer des identifiants stables apporte souvent plus qu’un océan de logs non corrélés.
Vous allez comprendre comment construire identifiants, événements, traces, dossiers, SLI et outils d’enquête. Les données sensibles restent minimisées ; les flux asynchrones transportent contexte et causalité, puis le run suit les dossiers exposés jusqu’à réconciliation.
Définir la question métier
Partir d’un verdict utilisateur
« La commande est-elle confirmée ? », « le vendeur sera-t-il payé ? » ou « l’offre est-elle publiée ? » sont des questions opérationnelles. Chacune possède début, sortie et états intermédiaires. L’instrumentation vise ces réponses.
L’équipe collecte les enquêtes réelles et les informations manquantes. Elle évite d’ajouter des champs sans usage. Une donnée d’observabilité a un owner et une durée de conservation.
Le parcours est décrit avec succès, échec, attente légitime et ambiguïté. Un timeout peut appartenir à plusieurs catégories selon l’effet. Les dashboards et runbooks utilisent ce vocabulaire commun.
Nommer l’unité d’impact
Compte, panier, commande, paiement, offre, retour ou payout peuvent être touchés. Les métriques conservent l’unité sans créer une cardinalité incontrôlée. Les détails restent dans les traces ou dossiers.
L’incident mesure volume, valeur et ancienneté. Une erreur rare sur un paiement élevé peut dépasser une panne bruyante de recommandation. Les priorités deviennent métier.
Le compromis porte sur la granularité. Une métrique par requête coûte peu mais masque le dossier ; une trace complète de chaque action peut exposer des données et saturer le stockage. L’équipe conserve 100 % des verdicts métier et erreurs, puis échantillonne les détails techniques des parcours sains selon trafic et risque.
Propager les identifiants
Distinguer corrélation et identité
Trace, requête et message possèdent des identifiants techniques ; commande et paiement possèdent des identités métier. Le contexte transporte les deux. Une corrélation éphémère ne remplace pas l’identifiant du dossier.
Les formats sont validés aux frontières. Un fournisseur externe reçoit une référence compatible et la renvoie dans ses webhooks. Le mapping reste unique et auditable.
Les identifiants ne contiennent ni email ni donnée sensible. Ils sont opaques, stables et uniques. Les outils permettent de passer du dossier à la trace et de la trace au dossier selon les droits.
Préserver la causalité
Un événement indique son parent et l’intention d’origine. Retry, compensation et batch gardent la chaîne causale. L’enquête distingue deux opérations concurrentes sur le même objet.
Les jobs propagés longtemps conservent un identifiant d’exécution et un identifiant métier. Un checkpoint n’ouvre pas une nouvelle histoire. Les doublons sont détectables.
Le contrat de propagation accepte request_id, journey_id, identités métier et causalité. Les messages asynchrones transportent correlation_id et causation_id ; un retry garde la même identité logique mais reçoit une tentative distincte. Le monitoring détecte les ruptures de chaîne et les dossiers créés sans parent.
Concevoir les événements métier
Décrire un fait immuable
Commande confirmée, paiement capturé, offre publiée et remboursement initié sont des faits datés. L’événement porte objet, version, acteur, source et cause. Il n’expose pas un état mutable sans contexte.
Le schéma est versionné et compatible. Les consommateurs déclarent leurs attentes. Un champ critique supprimé bloque la publication avant production.
L’outbox écrit le fait avec la transaction métier. Une confirmation en base sans événement devient un écart mesurable. Le relay possède retry, idempotence et checkpoint.
Éviter les événements bavards
Chaque modification de champ n’a pas besoin d’un fait public. Les événements portent un changement utile aux consommateurs. Les détails techniques restent dans les logs.
Une taxonomie d’événements limite les noms proches et les doublons. Les owners documentent source et SLO. Les événements sans consommateur sont revus.
Par exemple, payment_capture_requested reçoit commande, montant, devise, prestataire, clé idempotente et version de contrat ; sa sortie est capturé, refusé ou inconnu. Le schéma exclut numéro de carte et email. Une registry refuse les champs non classifiés et vérifie la compatibilité avant qu’une nouvelle version soit publiée.
Articuler logs, métriques et traces
Donner un rôle à chaque signal
Les métriques alertent et quantifient ; les traces suivent un parcours ; les logs expliquent un point ; les événements constatent le métier. Aucun signal ne remplace les autres. Les liens sont prévus.
Le log structuré contient niveau, service, opération, version, corrélation et code de résultat. Les messages libres complètent sans porter les seules informations utiles.
Les métriques utilisent des dimensions bornées. Les identifiants uniques n’entrent pas dans les labels. Un exemplaire relie un point agrégé à une trace représentative lorsque l’outil le permet.
Échantillonner sans perdre les erreurs
Les traces réussies peuvent être échantillonnées ; les erreurs, latences extrêmes et dossiers sensibles suivent une règle renforcée. La décision d’échantillonnage conserve la chaîne complète.
Le volume et le coût sont mesurés par signal. Une hausse anormale déclenche un contrôle. Les quotas ne doivent pas supprimer précisément la période d’incident.
La pipeline associe chaque signal à une finalité. Les logs expliquent un événement, les métriques mesurent une population et les traces relient la causalité. Des exemplars permettent de partir d’une alerte agrégée vers quelques dossiers représentatifs. Cette séparation évite d’indexer chaque détail coûteux tout en conservant le chemin vers la preuve.
Reconstruire le dossier
Assembler une chronologie métier
Le dossier présente intention, états, événements, paiements, messages et actions support par heure commune. Il indique sources et confiance. Une absence reste visible au lieu d’être remplacée par un statut supposé.
Les événements tardifs se placent selon leur occurrence et leur réception. L’équipe distingue retard de transport et action réellement tardive. Les fuseaux sont normalisés.
Une vue synthétique répond au verdict ; le détail ouvre trace et payload masqué. Support n’a pas besoin de lire des milliers de logs. Les développeurs conservent la profondeur technique.
Calculer les états incohérents
Des invariants détectent paiement capturé sans commande, expédition sans stock réservé ou payout sans livraison. L’anomalie porte règle, dossier et ancienneté. Elle rejoint une file.
La correction reste une commande métier auditée. Le dossier montre avant, action et après. L’observabilité ne devient pas une console de modification directe.
Protéger les données
Minimiser à la source
Tokens, mots de passe, données bancaires et documents ne sont jamais loggés. Les champs personnels sont masqués ou remplacés par identifiants. Les bibliothèques imposent ces règles.
Une liste positive définit les attributs autorisés. Les erreurs sérialisées sont filtrées. Les tests injectent des secrets factices et vérifient leur absence.
La rétention varie entre métriques, traces et dossiers. Les purges sont instrumentées. Les sauvegardes suivent la même politique avec délais documentés.
Contrôler les accès
Support, finance, sécurité et développement voient des projections différentes. Une élévation temporaire exige motif. Les consultations sensibles sont auditées.
Les exports ont périmètre, chiffrement et expiration. Un lien de trace ne contourne pas les droits du dossier. Les environnements restent séparés.
Les politiques de rétention suivent la finalité : quelques jours pour le debug détaillé, plusieurs mois pour un mouvement financier, puis agrégation ou suppression. Une tâche automatise expiration et prouve son exécution. Les accès aux dossiers sensibles déclenchent un audit et une revue, sans ralentir les recherches ordinaires du support.
Suivre les flux asynchrones
Mesurer la file et le travail
Backlog, âge du plus ancien, débit, retries et dead letters décrivent la file. Le métier ajoute dossiers et valeur exposés. Une queue vide n’est pas saine si les producteurs n’émettent plus.
Chaque message porte intention, schéma, tentative et délai. Le consumer produit un verdict. Le heartbeat distingue traitement long et worker bloqué.
Les checkpoints et partitions sont visibles. Une reprise garde la position saine et évite de rejouer les succès. Les dead letters ne deviennent pas un cimetière sans owner.
Tracer retry et idempotence
Le retry conserve la même intention et crée une tentative liée. Le système distingue duplicate ignoré, reprise réussie et effet compensé. Les clés ont une durée suffisante.
Un message empoisonné est isolé après seuil et n’arrête pas toute la partition. Son dossier indique cause et action. La correction permet un replay contrôlé.
Mesurer les sorties utiles
Construire numérateur et dénominateur
Le SLI compte intentions éligibles et sorties réussies sous délai. Les exclusions sont fixes et expliquées. Une donnée manquante ne vaut pas succès.
Commande, paiement, publication et support ont des objectifs distincts. Le parcours transverse mesure la fin, les domaines localisent la cause. Les fenêtres montrent budget consommé.
La qualité du calcul est monitorée : retard, événements rejetés et échantillon de rapprochement. Un dashboard périmé affiche son âge. Les décisions s’arrêtent si la télémétrie n’est plus fiable.
Alerter sur l’impact
Les burn rates détectent incident rapide ou chronique. L’alerte indique parcours, dossiers, valeur, version et runbook. Elle ne se contente pas d’un nom de pod.
Les seuils évitent le bruit et conservent les cas critiques absolus. Un seul double débit peut page l’astreinte même si le taux global reste faible.
Scénario : 99,9 % des requêtes répondent, mais 3 % des commandes restent « en validation » plus de dix minutes. Si le SLI mesure seulement HTTP, il reste vert ; s’il mesure verdict de commande, alors l’alerte ouvre le runbook, donne la population et suspend les nouvelles confirmations sur le consumer touché.
Accélérer l’investigation
Préparer des parcours de diagnostic
Depuis commande, compte ou paiement, l’outil ouvre la chronologie et les traces. Des vues enregistrées couvrent paiement inconnu, commande bloquée et offre absente. Les filtres utilisent des codes stables.
Le diagnostic compare une cohorte saine et touchée par version, marché ou fournisseur. Il aide à isoler le changement. Les requêtes partagées sont versionnées.
Un endpoint réservé expose état, dépendances et décisions sans effet. Les réponses sont masquées selon le rôle. L’équipe n’exécute pas un script ad hoc sur la production pour chaque ticket.
Conserver les preuves de décision
L’investigation note hypothèse, requête, résultat et décision dans le dossier d’incident. Les captures ne remplacent pas les liens vers les données datées. Le débrief reste reproductible.
Les accès et requêtes coûteuses sont bornés. Une recherche globale exige une fenêtre. L’outil protège la plateforme pendant l’incident.
Le parcours de diagnostic possède entrées, requêtes, décisions et sorties attendues. Un test synthétique l’exécute après chaque déploiement. Si une vue, un index ou une permission empêche d’atteindre le verdict sous cinq minutes, alors le runbook est considéré dégradé et reçoit une action avant l’ouverture du trafic suivant.
Outiller support et finance
Donner un verdict lisible
Support voit confirmé, en vérification, action requise ou erreur avec prochaine étape. Les codes techniques restent derrière. Le message indique la fraîcheur et les actions sûres.
Finance voit intention, capture, remboursement, ledger et rapprochement. Une transaction fournisseur non liée est signalée. Les montants et devises restent structurés.
Les deux équipes partagent l’identifiant de dossier et la chronologie. Une escalade enrichit le contexte sans recopier des informations personnelles dans un ticket.
Limiter les actions manuelles
Retry, réconciliation et compensation sont des commandes nommées avec prévisualisation. Les rôles et plafonds s’appliquent. Une écriture directe en base est exclue.
Chaque action produit événement et résultat. Si elle échoue, le dossier reste ouvert. Les usages manuels alimentent la roadmap d’automatisation.
L’action manuelle est une commande typée avec préconditions, prévisualisation, owner et résultat. Rejouer un webhook, libérer une réservation ou recalculer un solde utilise une clé idempotente et crée un événement. Le support ne modifie jamais directement une colonne, car cette correction serait invisible des projections et de la réconciliation.
Piloter incident et reprise
Identifier la population exposée
L’incident commander filtre les dossiers par version, intervalle, fournisseur et état. La liste est exportable avec contrôle. Les communications visent les personnes réellement touchées.
Le kill switch réduit le parcours concerné. L’observabilité vérifie sa propagation. Les nouveaux dossiers sont distingués de ceux à réparer.
Prouver la réconciliation
La reprise suit backlog, états incohérents et dossiers sans verdict. Le service revenu n’est qu’une étape. Les corrections sont comptées et échantillonnées.
Scénario : le bus revient après une panne. Si des paiements restent sans commande, alors l’incident continue. La clôture exige verdict, ledger et message pour chacun ou transfert explicite à un owner.
La reprise vérifie source, événements, projections et sorties client. Si 250 paiements ont été capturés mais que 247 commandes seulement sont confirmées, alors l’incident reste ouvert. Finance rapproche les trois écarts, support contacte les dossiers exposés et plateforme ajoute une fixture reproduisant la rupture avant retour complet.
Adapter la méthode et éviter les erreurs
Pour qui cette observabilité convient
Elle convient aux marketplaces avec domaines, files ou fournisseurs externes. Une architecture simple peut commencer par commande, paiement et publication avec identifiants et dossiers communs.
Produit définit les verdicts ; domaine les événements ; plateforme les signaux ; data les SLI ; support les dossiers ; sécurité les accès. Chaque owner valide une sortie.
Erreurs fréquentes en observabilité métier
Empiler des logs, mettre des identifiants en labels, perdre la causalité, exposer des données sensibles et clôturer quand le service revient sont les erreurs majeures. Elles ralentissent la réparation.
Une autre erreur consiste à tracer les composants sans définir le verdict métier. L’équipe voit où le code passe, mais pas si la promesse est tenue.
Plan d’action pour installer l’observabilité métier
Semaines 1 à 4 : identités et événements
La première semaine choisit commande, paiement et publication, puis analyse vingt incidents. L’équipe définit identités, verdicts et chronologies. La deuxième ferme propagation et schémas d’événements.
Les semaines trois et quatre instrumentent outbox, traces, logs et dossiers. Sécurité ferme les champs autorisés ; support teste les vues ; data rapproche un échantillon aux sources.
Semaines 5 à 8 : SLI et reprise
La cinquième semaine construit SLI, burn rates et alertes. La sixième suit files, retries et anomalies métier. Les runbooks lient dossier, trace et commande de réparation.
Les semaines sept et huit rejouent événement perdu, paiement ambigu et bus indisponible. Le go exige population exposée retrouvée, données protégées et réconciliation exécutée sans requête directe.
Le comité supprime les signaux sans usage et mesure coût, couverture et temps d’enquête. Toute nouvelle fonctionnalité critique doit déclarer identifiants, événements et verdict avant lancement.
Le dossier de go contient schémas, règles de rétention, dashboards, alertes et quatre runbooks exercés. Support doit retrouver un dossier sans identifiant technique ; finance rapproche un paiement ; sécurité prouve masquage et expiration ; plateforme rejoue un événement sans double effet. Les seuils sont testés avec une population synthétique puis une cohorte réelle. Si l’équipe ne peut pas nommer les clients exposés ou prouver leur convergence, la fonctionnalité reste sous kill switch.
- À faire d’abord : choisir trois verdicts et leurs identifiants stables.
- À tester ensuite : événement perdu, retry, donnée sensible et reprise.
- À différer : les métriques sans question opérationnelle.
- À refuser : tout log contenant secret ou donnée bancaire.
Guides complémentaires pour l’opérateur
Structurer dossiers et objets
Les écrans du back-office opérateur structurent chronologies et actions.
Le catalogue PIM marketplace fournit les identités d’offre.
Borner le premier parcours
Le MVP marketplace avant ouverture aide à choisir les signaux critiques.
La méthode pour ouvrir une première catégorie permet de tester les dossiers en conditions réelles.
Conclusion : observer une promesse
L’observabilité métier relie une intention, des événements, des traces et un verdict dans le même dossier.
Identifiants, causalité et données minimisées rendent l’enquête rapide sans transformer les logs en base parallèle.
SLI et chronologies pilotent l’incident jusqu’à la réconciliation des clients exposés. Cette continuité réduit le diagnostic, borne la population touchée et donne à chaque équipe une preuve commune avant réparation, communication et retour au nominal.
Pour concevoir cette observabilité, Dawap peut vous accompagner dans votre marketplace opérateur.
