Health¶
Vue d'ensemble¶
Le module Health est responsable de l'évaluation de l'état de santé opérationnel d'une Canonical Product Identity au sein de la Platform.
Alors que le module Quality mesure la qualité intrinsèque des informations disponibles, Health mesure la capacité de ces informations à traverser correctement les différentes étapes de traitement de la Platform.
Autrement dit :
- Quality répond à la question « Les données sont-elles fiables ? » ;
- Health répond à la question « Les données sont-elles dans un état normal de fonctionnement ? »
Ces deux notions sont complémentaires mais indépendantes.
Pourquoi un module Health ?¶
Une identité produit peut être parfaitement cohérente tout en présentant un problème de fonctionnement.
Quelques exemples :
- une projection n'a pas encore été générée ;
- une étape du Pipeline s'est interrompue ;
- certaines métadonnées attendues sont absentes ;
- une synchronisation est restée incomplète ;
- un traitement est en attente.
Dans tous ces cas, les données peuvent être correctes.
En revanche, leur état opérationnel nécessite une attention particulière.
C'est précisément le rôle du module Health.
Position dans l'architecture¶
Le module intervient une fois que les traitements principaux ont été réalisés.
Feed
│
▼
Pipeline
│
▼
Canonical Identity
│
▼
Projection
│
▼
Health
│
▼
Monitoring
Il ne participe jamais aux traitements métier.
Il observe leur résultat.
Responsabilités¶
Le module Health fournit une vision synthétique de l'état de fonctionnement des données.
Il peut notamment :
- signaler des traitements incomplets ;
- détecter des états incohérents ;
- exposer des indicateurs destinés au monitoring ;
- produire des métriques exploitables par les outils d'exploitation ;
- alimenter les rapports de validation.
Son rôle est exclusivement descriptif.
Les différentes dimensions¶
État du traitement¶
Health permet de savoir si un produit a correctement traversé les différentes étapes prévues par la Platform.
Par exemple :
- traitement terminé ;
- traitement partiellement terminé ;
- projection absente ;
- étape en attente ;
- traitement interrompu.
Le module ne tente jamais de reprendre un traitement.
Validation¶
Le module peut également exposer le résultat des différentes validations réalisées pendant le traitement.
Quelques exemples :
- validation réussie ;
- validation incomplète ;
- validation en attente ;
- validation échouée.
Health ne cherche jamais à corriger ces situations.
Alertes opérationnelles¶
Certaines situations méritent d'être signalées aux opérateurs.
Par exemple :
- projection manquante ;
- métadonnées absentes ;
- état incohérent entre plusieurs traitements ;
- informations devenues obsolètes.
Ces alertes permettent de faciliter le diagnostic sans bloquer le fonctionnement général de la Platform.
Indicateurs globaux¶
Le module peut agréger plusieurs informations afin de produire des indicateurs utilisables dans les tableaux de bord.
Par exemple :
- nombre de produits sains ;
- nombre de produits nécessitant une vérification ;
- nombre de projections manquantes ;
- nombre de traitements incomplets.
Ces indicateurs restent volontairement indépendants des verticales.
Ce que le module ne fait jamais¶
Health n'est pas responsable :
- de résoudre une identité ;
- de calculer la qualité des données ;
- de générer une projection ;
- d'afficher des informations dans le Frontend ;
- d'exécuter des traitements Runtime ;
- de corriger automatiquement un problème.
Il constate.
Il mesure.
Il signale.
Invariants¶
Aucun couplage métier¶
Le module ne contient aucune connaissance spécifique aux produits.
Il ignore complètement les notions de :
- Smartphone ;
- Photo ;
- TV ;
- Gaming ;
- Printer ;
- Mobility ;
- Toys.
Toutes les règles restent génériques.
Lecture seule¶
Health ne modifie jamais les données.
Toutes les informations produites sont calculées à partir de l'état actuel de la Platform.
Déterminisme¶
Pour un même état de la Platform, le résultat doit toujours être identique.
Aucun comportement aléatoire n'est autorisé.
Observabilité¶
Chaque indicateur produit doit être compréhensible.
Un état de santé ne doit jamais être implicite.
Les outils d'exploitation doivent pouvoir expliquer pourquoi un produit est considéré comme sain ou non.
Relation avec Quality¶
Bien que souvent associés, Health et Quality répondent à deux problématiques différentes.
Quality évalue la qualité métier des informations.
Health évalue leur état opérationnel.
Une identité peut ainsi :
- être de très bonne qualité mais présenter un problème de traitement ;
- être parfaitement traitée mais contenir peu d'informations ;
- être à la fois complète et saine ;
- ou cumuler plusieurs anomalies.
Cette séparation simplifie considérablement le diagnostic.
Exemple¶
Un smartphone possède une Canonical Identity correcte.
Toutes les informations sont présentes.
Le score Quality est excellent.
En revanche, une erreur empêche la génération de la projection destinée au Frontend.
Le module Health signale alors une projection manquante.
La qualité des données reste excellente.
Seul l'état opérationnel nécessite une intervention.
Évolution¶
À terme, Health deviendra le point central de l'observabilité de la Platform.
Il pourra notamment agréger :
- les indicateurs du Pipeline ;
- les états des projections ;
- les résultats des validations ;
- les métriques d'exécution ;
- les informations de monitoring.
L'objectif est de disposer d'une vision cohérente de l'état de santé global de la Platform sans introduire de dépendances entre les différentes couches de l'architecture.