Avec les nouvelles mesures sanitaires, une partie du service informatique de mon taff est sommé d'assurer le bon fonctionnement de nos systèmes internes de visioconférence avec un nombre élevé et inhabituel d'utilisateurs. Notre directeur souhaite des indicateurs afin de montrer l'(in)utilité du renforcement de la capacité de nos systèmes. Il souhaite partager ces indicateurs sur une page web.
Je ne vais pas recracher mon topo sur l'absurdité de la société du tout-chiffré qui complète une bonne introduction au sujet par DataGueule.
J'ai un Bac Économique et Social, donc, formation oblige (je me souviens des exercices consistant à tordre les chiffres afin de leur faire dire l'inverse), je me méfie des nombres. Ils ont rien d'objectif.
De même, le caractère évident d'un nombre est contestable. Exemple : je suis incapable de comprendre des indicateurs financiers genre telle marge est-elle correcte pour telle société commerciale exerçant dans tel secteur et ayant tel modèle d'affaires ? Aucune idée. Un graphe illustrant la masse salariale ou les effectifs par services de mon employeur me parlerait aussi peu : est-ce trop ? Pas assez ? Aucune idée. En revanche, j'ai un avis sur l'effectif de mon service, sur nos indicateurs techniques d'informaticiens, etc. Derrière un nombre, il doit y avoir un public à même de l'expliciter et un autre à même de le comprendre.
Dire si notre service de VoD sature, par exemple, c'est loin d'être évident : charge CPU ? Un nombre élevé de connexions peut faire tomber un serveur qui se touche. Nombre de fichiers ouverts ? Les connexions peuvent être mises en attente par le frontal pendant que l'applicatif digère. Temps de réponse de l'applicatif ? Nombre de requêtes / seconde ? Sur l'applicatif Django ou sur les fichiers statiques ? Ça ne mesure pas la même chose. Faut-il prendre en compte le chargement de la charte graphique (CSS, JS, images, etc.) ? Nombre d'adresses IP uniques / seconde ? Quid des NAPT et des reverse proxies ? Quid des usages qui chargent un serveur même avec peu de connexions simultanées ? Avec ces questions, on n'a toujours pas d'indicateur ultime sur l'utilisation réelle de notre service, et il faudra des compétences pour interpréter ceux sus-mentionnés.
Je pense qu'un nombre est utile pour trancher un débat et/ou asseoir une crédibilité quand il est échangé posément au sein d'une communauté humaine aux intérêts partagés dont chaque membre dispose des compétences pour le comprendre. Ça fait beaucoup de conditions.
Autrement dit, il est inutile dans une communauté hétérogène ou entre deux communautés aux intérêts divergents. Dans ce cas, un contradicteur contestera le chiffre, le questionnera, le déconstruira, lui opposera d'autres chiffres censés mieux mesurer l'objet du débat, chiffres qu'il enrobera dans un imaginaire, etc. Il suffit de lire les proses des gauchistes et des droiteux pour s'en rendre compte : à chacun ses chiffres sur les systèmes de redistribution et leurs apports, la pauvreté, la hausse (ou non) des inégalités, l'apport bénéfique (ou non) de ces inégalités, le calcul de la richesse d'un territoire, etc. Le but étant de remporter une bataille d'opinion afin de se faire élire, il n'y a pas d'honnêteté, donc les chiffres sont vains car bidons.
De même, un chiffre est inutile face à un supérieur hiérarchique / un élu, car le chiffre ne remplace pas une décision : si un chef veut envoyer des gens dans le mur, il enverra des gens dans le mur. Dans le cas qui m'intéresse, si jamais le redimensionnement en cours de notre installation interne de visioconférence se révèle être inutile car le nombre de conférences est largement en deçà, notre directeur pourra toujours montrer les chiffres (nombre de salles simultanées) et les graphes, ça aura aucun effet. Son supérieur rétorquera qu'il fallait sur-dimensionner "au cas-où". Pour ce chef, la question n'est pas de savoir si c'est utile ou non (ce qui se mesure), mais de prévoir un risque afin de (légitimement) se couvrir / couvrir notre organisation suite à un ordre venu d'encore plus haut. Il n'y a pas d'indicateurs pour mesurer cela. Du coup, lors d'une prochaine """"crise"""", notre directeur n'aura pas plus de poids / crédibilité. Il ne pourra pas invoquer "la dernière fois, ta demande était démesurée / disproportionnée, voilà les chiffres qui illustrent cela, donc soyons plus raisonnables cette fois-ci", car la logique sera toujours de se couvrir / de faire au mieux pour notre organisation, et le mieux, ça ne sera mesure pas vraiment, c'est très subjectif.
Dans le même genre, les non-débats sur une sortie du nucléaire dégagent des chiffres sur la part du nucléaire versus charbon, sur la fluctuation des énergies renouvelables, sur la durée de vie moyenne d'une centrale, sur la rentabilité écolo moyenne d'un panneau solaire, etc., sans jamais dégager la question décisionnelle qui me semble être clé : ne faut-il pas réduire nos besoins en énergie ? Question à laquelle aucun chiffre peut répondre.
En annexe, un point technique est intéressant. Notre supervision graphe nos métriques techniques avec RRDtool. Au-delà d'une période de temps définie (plusieurs, en vrai), il lisse les valeurs en gardant la moyenne sur un intervalle passé. Cela est perçu comme étant un problème.
D'une part, j'estime que nos graphes révèlent une tendance et que c'est elle qu'il faut prendre en compte, comme les chiffres Covid sus-cités dont la valeur d'un jour ne vaut rien. D'autre part, le lissage se compense par une sur-capacité (exemple : prévoir +20-30 %). Avec le graphe du nombre de requêtes/seconde sur nos bases de données, j'ai su dimensionner nos derniers serveurs, semble-t-il. Je saurai faire pareil avec nos annuaires LDAP. Une sur-capacité raisonnable rend une infrastructure résiliente aux chocs d'utilisation imprévus pour un sur-coût environ nul (c'est l'une des leçons de l'effet du confinement sur les réseaux informatiques, les Cassandre hurlant à leur saturation et appelant à la modération des usages ‒ sauf pour leur pomme ‒ se sont plantés).
Ensuite, dès que t'as une valeur que tu récupères une fois par tranche de cinq minutes pour ensuite produire une mesure par unité de temps (exemple : nombre de requêtes web par seconde), t'es déjà dans le faux statistique puisque tu considères qu'une valeur récupérée à un point du temps est vrai sur tout un intervalle de temps (de 5 minutes, en général). Le mieux est un compteur incrémental, comme le nombre total de bits émis/reçus sur un port d'un commutateur réseau depuis son démarrage (encore faut-il se souvenir de relever les compteurs 64 bits sinon ça produit des stats bidons) ou le nombre total de requêtes LDAP / MySQL depuis le démarrage du serveur. En cela, les trucs modernes comme Graphite, OpenTSDB, etc. ne font que stocker des points plus réguliers et les conservent plus souvent (et encore, il y a 5 ans, j'ai trouvé qu'OpenTSDB est poussif quand il doit appliquer une fonction sur un ensemble conséquent de points, d'où le choix de RRD de virer les points trop anciens n'est pas idiot). Il y a rien de magique. Je reconnais que les visualisations de Kibana sont plus dynamiques qu'un graphe RRD : en un clic, tu changes le format du graphe genre diagramme circulaire vers diagramme en barres, en un autre clic, ça prend tel intervalle de temps par défaut, en un autre clic, ça masque telles données.
On notera que RRDtool permet de choisir la fonction de consolidation (CF). Dans le cas présent, on pourrait conserver la valeur la plus élevée sur un intervalle. Cela permettrait d'illustrer le bon dimensionnement de notre système de visioconférence. Deux inconvénients : 1) on n'a toujours pas d'indicateur sur l'utilisation réelle / concrète (mais dans le cas présent, j'en vois pas trop l'intérêt…) ; 2) par le passé, j'ai passé une demi-journée à configurer notre supervision pour qu'elle crée des graphes RRD avec une CF différente… Sans succès.