J’étais plongé dans la lecture du blog technique de Deepki lorsqu’une collègue vient me voir : il manque des données dans son application et il se trouve que cette semaine, je suis le DRIS de l’équipe collecte. Je me lance dans une grande tirade, expliquant que les données font un long chemin avant d’arriver dans son application et qu’il est possible qu’elles se perdent en route, mais qu’on a justement développé un outil pour déterminer rapidemment pourquoi elles se sont perdues. En fait, elle sait déjà tout ça, et je comprends qu’elle m’a laissé parler par pure politesse quand elle me montre clairement que dans son cas précis, l’outil ne signale aucun problème alors qu’il y a visiblement des données manquantes dans son application. Je regarde de plus près, elle a raison : tous les indicateurs sont au vert, et elle a encore raison : il manque des données dans son application. Aïe !

Monitorer notre système de collecte de données est un défi permanent. Chaque fois qu’on pense avoir envisagé tous les cas de figure, il en reste encore un à résoudre. Est-on passé à côté de quelque chose ou est-il impossible de trouver une solution parfaite ? Afin d’y voir plus clair, j’aimerais revenir à travers 3 articles, sur quelques phases marquantes de notre aventure.

  1. La première visualisation de notre système de collecte : Entre créativité et veille technique
  2. Pourquoi la connaissance métier est primordiale
  3. Être à l’écoute des besoins utilisateurs

Entre créativité et veille technique

La heatmap a ses limites

La collecte de données chez Deepki, ça remonte à loin. Et si je ne me trompe pas, la première c’était la collecte des factures. À ce moment là, on avait peu de clients, on lançait quelques tâches quand le besoin se présentait, puis on avait le résultat dans la journée. Pour monitorer, il suffisait de lire les logs, c’était le bon temps. Mais très vite, il a fallut automatiser le lancement des tâches car il y en avait trop pour toutes les lancer à la main. Le nombre de tâches a continué à augmenter, et soudain, c’est devenu impossible de savoir quand telle tâche avait commencé et quand telle autre s’était terminée. Du coup, on s’est lancé dans le développement d’un outil de monitoring. En se laissant guider par notre intuition, on a rapidemment développé une heatmap, on en était content.

Exécutions au cours du dernier mois. En vert, une exécution sans erreur et sans téléchargement, en rouge, avec erreur et sans téléchargement, en bleu, avec ou sans erreur mais avec téléchargement.

On y voyait le nombre d’exécutions de chaque tâche au cours du dernier mois, et le résultat de chaque exécution : succès, erreur, avec ou sans téléchargement de facture. Ça répondait à notre besoin, donc pour la suite, on a continué à suivre notre intuition. Lorsque le nombre de tâches est devenu trop grand pour une seule heatmap, on a regroupé les tâches par type, créant ainsi des ensembles de tâches. On avait alors une heatmap par ensemble de tâches. Mais bien sûr, Deepki a continué à se développer, et le nombre de clients augmentant de manière exponentielle, on a fini par avoir des centaines de heatmaps dont certaines faisaient plusieurs milliers de lignes.

Comment lit-on une heatmap de plusieurs milliers de lignes ? On zoome sur les 50 premières puis on extrapole, on obtient alors une vision très approximative de l’état d’un système. Et comment lit-on une centaine de heatmaps ? Chaque jour on en prend un dizaine au hasard et on règle les problèmes au fil de l’eau. Ça vous parait pérenne ? À nous non plus. Notre heatmap n’était pas scalable, il fallait trouver une autre façon de représenter l’état de notre système.

La mise en veille

C’est assez courant d’oublier que ce que l’on fait n’est jamais qu’une variation de ce qui existe déjà, que la plupart des problèmes qu’on rencontre ont déjà été résolus par d’autres, et qu’il est bon de regarder ce qui a déjà été fait pour mieux décider de ce qu’on va faire. Si on avait fait plus de veille, on aurait d’emblée considéré notre système de collecte comme un ETL et on aurait vu que d’autres avant nous ont posé les bases du monitoring de ce type de système. Il existe en effet des outils complets comme Airflow d’Apache et des guides de bonnes pratiques comme ce framework de chez DataDog. Dans ce dernier, le monitoring y est divisé en 3 catégories :

  • les métriques métier
  • les métriques ressources
  • les évènements.

Pour chaque catégorie il y a un panel d’indicateurs numériques précis, qui, contrairement aux heatmaps, ont l’avantage d’être tout à fait scalables. Dans la catégorie métier, par exemple, les indicateurs sont tout simplement débit, succès, erreur et performance. Sobre et efficace : on est loin des centaines de heatmap à plusieurs milliers de lignes qu’il revient à chacun d’interpréter. On peut alors se poser la question suivante : Avons-nous complétement perdu notre temps à essayer de représenter notre système de manière créative ? Finalement, n’aurait-il pas été plus judicieux de suivre une recette écrite et testée par d’autres ?

La recette magique

Aborder un produit de manière créative et autonome est une très belle façon de le comprendre et de se l’approprier car elle est très souvent source de plaisir. Cela dit, il reste important de prendre de la distance et de reconnaitre le mouvement dans lequel il s’inscrit et les concepts qu’il emprunte à d’autres. Car dès lors, des solutions éprouvées sont accessibles pour résoudre les problèmes recontrés.

Toutefois, lorsqu’on s’est lancé dans le développement des indicateurs conseillés par les bonnes pratiques, on s’est rendu compte d’un nouveau problème : développer un indicateur de succès, ça parait simple comme ça, mais encore faut-il savoir le définir, le succès. C’est un mot commun, mais chacun le définit à sa manière. La suite nous apprendra que la recette magique n’existe pas ; qu’il est nécessaire de comprendre tous les aspects de son produit si on veut le monitorer correctement. Mais cela est une autre histoire.

Affaire à suivre…