L’observabilité devient utile lorsqu’elle réduit la distance entre un incident et son explication. Dans les systèmes orientés workflows, cela suppose généralement de combiner télémétrie technique et état métier visible, plutôt que d’ajouter toujours plus de dashboards.
Le but est la compréhension opérationnelle, pas le volume d’instrumentation.
Le problème
Les équipes collectent logs, métriques et traces mais restent incapables de répondre à des questions simples : la transition a-t-elle été enregistrée ? Quel retry a déjà eu lieu ? Un replay est-il sûr ? Sans ces réponses, l’incident reste instrumenté techniquement mais opaque opérationnellement.
Ce qui casse en pratique
- Les logs montrent une exception, pas la transition métier qui a échoué.
- Les opérateurs savent qu’un workflow est bloqué sans voir le dernier checkpoint réussi.
- Les métriques de queue paraissent normales alors qu’un workflow critique est bloqué sur une seule classe d’échec.
- Le produit demande “l’action utilisateur a-t-elle réussi ?” et l’ingénierie doit reconstituer la réponse à partir de plusieurs systèmes.
Décisions de conception
- Émettre des événements métier sur les transitions importantes afin que le comportement produit soit visible hors des logs d’application.
- Donner à l’outillage interne un état de workflow explicite, des raisons d’échec et des prochaines actions sûres.
- Conserver la chaîne d’exécution complète entre requête, job et appel externe pour rendre l’asynchrone explicable.
- Suivre les classes d’échec par type de workflow afin que les incidents à fort impact remontent plus vite.
Arbitrages
- Une observabilité orientée domaine demande plus de modélisation que le logging infra par défaut.
- Les vues opérateur coûtent du temps produit, mais elles évitent une forte dépendance au support technique.
- Une télémétrie riche augmente stockage et bruit si elle n’est pas reliée à de vraies questions opérationnelles.
Patterns de production
- Journaux d’événements métier liés aux transitions, pas seulement aux exceptions.
- Correlation IDs propagés entre requêtes, workers et appels d’intégration.
- Vues admin montrant
queued, running, failed, completed, replay-required.
- Alertes de workflow basées sur classe d’échec, lag et nombre de transitions bloquées.
Ce que je ferais différemment
- Définir les besoins d’observabilité par workflow avant l’implémentation.
- Ajouter davantage d’indications “prochaine action sûre” dans les vues opérateur.
- Considérer la propagation de traces vers les workers comme obligatoire sur les parcours riches en intégration.