Aller au contenu

Health

Status: CONTRACT

À quoi sert un Health Read Service ?

La famille Health regroupe les Read Services qui mesurent l'état de santé, la qualité ou la complétude d'une partie de CMonChoix sans jamais modifier les données observées.

Un Health Read Service répond à des questions comme :

  • la projection contient-elle les données attendues ?
  • les attributs critiques sont-ils présents ?
  • les états unknown, ambiguous et conflict augmentent-ils ?
  • une famille de données semble-t-elle dégradée ?
  • une population reste-t-elle exploitable par le Frontend ou un service aval ?

Il observe et mesure. Il ne répare pas.

Pourquoi ce composant existe

Un indicateur de santé doit pouvoir être consulté sans risque, y compris en production.

Séparer le Health de toute écriture permet :

  • d'inspecter une dégradation sans la masquer ;
  • d'obtenir des métriques reproductibles ;
  • de comparer plusieurs runs ou snapshots ;
  • de déclencher ensuite une investigation ou une intervention distincte.
Données persistées / projections
              ↓
       Health Read Service
              ↓
 métriques + catégories + warnings
              ↓
 diagnostic / monitoring / décision

Entrées

Un Health Read Service doit identifier le périmètre qu'il mesure, par exemple :

  • run ou snapshot ;
  • projection ;
  • verticale ;
  • feed ;
  • marchand ;
  • famille de produit ;
  • période ;
  • filtres d'éligibilité.

Une métrique sans population clairement définie n'est pas exploitable pour un diagnostic.

Sorties attendues

Le résultat doit être structuré et sérialisable.

Il peut contenir :

  • nombre d'éléments observés ;
  • nombre d'éléments éligibles ;
  • complétude ;
  • distribution des statuts ;
  • erreurs techniques ;
  • warnings ;
  • reason codes ;
  • ratios ;
  • échantillons représentatifs ;
  • version du calcul ;
  • contexte du run ou snapshot.

Les dénominateurs doivent être explicites. Un pourcentage seul ne suffit pas.

Santé, qualité et résolution

Ces notions sont liées mais différentes.

Le Resolver décide d'un état d'identité.

Le Quality Scorer mesure la qualité et la confiance d'informations disponibles.

Le Health Read Service agrège ou expose l'état observé sur une population afin de détecter une dégradation ou une anomalie.

Resolver      = décision individuelle
Quality       = évaluation individuelle ou locale
Health        = lecture de l'état d'une population ou d'un composant

Un Health Read Service ne doit donc pas réimplémenter les règles du Resolver ou du Quality Scorer.

Ce qu'un Health Read Service ne doit jamais faire

Il ne doit jamais :

  • écrire en base ;
  • corriger automatiquement une donnée jugée mauvaise ;
  • reconstruire silencieusement une projection ;
  • appeler un Write Service ;
  • déclencher une synchronisation ;
  • transformer un unknown ou un conflict en succès pour améliorer un KPI ;
  • masquer les données exclues ou non évaluées.

Signaux utiles

Selon le composant, les signaux de santé peuvent inclure :

  • proportion de resolved ;
  • proportion de unknown, ambiguous et conflict ;
  • attributs critiques manquants ;
  • projections absentes ou incomplètes ;
  • doublons ;
  • lignes en retard ou non rafraîchies ;
  • erreurs de traitement ;
  • données non éligibles ;
  • différences anormales entre runs comparables.

Il faut distinguer une dégradation métier d'un échec technique. Par exemple, une hausse de unknown n'est pas la même chose qu'une requête SQL en erreur.

Diagnostic

Lorsqu'un indicateur de Health se dégrade, vérifier dans cet ordre :

  1. la population comparée est-elle la même ?
  2. le run ou snapshot est-il complet ?
  3. un feed ou une verticale manque-t-il ?
  4. les règles d'éligibilité ont-elles changé ?
  5. la projection observée a-t-elle été reconstruite récemment ?
  6. les statuts métier sont-ils correctement séparés des erreurs techniques ?
  7. le problème vient-il de l'ingestion, du Domain Core, de la projection ou seulement de la lecture ?

Cette approche évite de réparer la mauvaise couche.

Relation avec le monitoring

Le monitoring peut consommer les métriques d'un Health Read Service, mais le Health reste un service de lecture métier ou applicatif.

Le monitoring se charge ensuite de :

  • stocker ou afficher les séries temporelles ;
  • produire des alertes ;
  • comparer à des seuils opérationnels.

Un seuil d'alerte ne doit pas être enfoui dans la logique métier si ce seuil relève de l'exploitation.

Reproductibilité

À données, filtres et version identiques, les métriques de santé doivent être stables.

Toute évolution de définition d'un KPI doit être versionnée ou documentée afin d'éviter de comparer deux métriques portant le même nom mais calculées différemment.

Tests attendus

Un Health Read Service important doit être couvert par :

  • tests read-only ;
  • tests de réconciliation des compteurs ;
  • tests sur populations vides ou incomplètes ;
  • tests séparant unknown, ambiguous, conflict et erreur technique ;
  • tests de déterminisme ;
  • tests de stabilité des reason codes ;
  • tests garantissant l'absence d'appel à un Write Service.

Invariants

  1. Un Health Read Service est strictement read-only.
  2. La population mesurée est explicite.
  3. Les métriques possèdent un dénominateur clair.
  4. Les états métier et les erreurs techniques restent distincts.
  5. Une mauvaise métrique ne déclenche pas elle-même une mutation.
  6. Le Health ne duplique ni Resolver ni Quality Scorer.
  7. Une définition de KPI modifiée doit être traçable.

Voir aussi