La métrologie ce n’est pas si simple
La mesure de la performance d’un système d’informations (SI) est une tâche complexe dans la maintenance opérationnelle de celui-ci.
D’une part parce que les SI sont eux aussi de plus en plus complexes (virtualisation de l’infrastructure, cloud computing, micro-services, …). D’autre part parce que la notion même de performance est elle aussi complexe tant dans la détection que dans l’objectivation d’un ressenti utilisateur par nature subjectif.
Toujours est-il que le suivi des performances est une tâche indispensable pour une gestion optimale du SI afin de respecter les niveaux de service au meilleur coût, pourtant trop souvent mis de côté.
Malheureusement c’est dans les situations de crise que l’on se rend compte de son importance. Il est fréquent que l’on confonde supervision et métrologie. Bien que la fonction de chacun des services soit différente, les utilisateurs ont tendance à penser que l’historisation des données proposée par les outils pourra leur servir le moment venu. Mais ces outils certes gardent sur une période donnée l’ensemble des métriques connectées mais au fil du temps agrègent les valeurs à l’heure puis à la journée puis au mois… Ce qui les rend souvent inexploitables dans le cas d’une analyse suite à un problème de performances par exemple.
La supervision est l’observation du fonctionnement du SI à l’instant T. Les évènements remontés ont uniquement pour but de fournir à l’exploitant un bilan de santé du SI au moment de l’observation.
La métrologie est la collecte d’un ensemble de métriques cohérent, validées et vérifiables sur le long terme en vue d’une analyse a posteriori de l’activité du SI dans son ensemble ou sur un périmètre fonctionnel ou technique précis. Elle permet également de projeter l’activité du SI dans le temps en fonction de l’évolution de l’activité ou pour une analyse de capacity planning. La supervision est une source de donnée de la métrologie mais nous verrons cela dans un prochain article.
La métrologie est votre amie
C’est pour vous donner envie de mettre en place une métrologie efficace de votre SI et d’en appréhender au mieux les avantages à investir dans un service de métrologie que je me lance dans cette série d’articles autour de la métrologie des performances.
Nous commencerons par les bases afin de définir les principales notions et les avantages d’un suivi régulier et sur le long terme.
Dans les prochains épisodes nous parlerons de méthodologie de collecte et des sources de données de la métrologie. Puis, par la suite des modèles de représentation, le suivi des coûts, la métrologie dans le « nouveau » monde…
En aparté n’hésitez pas à proposer des sujets que vous aimeriez voir traiter.
Bref ce vaste sujet devrait nous occuper quelques mois.
Episode 1: Les bases – Here we go !!!!
Qu’on le veuille ou non les problèmes de performances sont assez communs dans la plupart des SI et ils se traduisent par un accès difficile voire impossible à l’application de comptabilité suite à la réorganisation du temps de travail pendant la crise sanitaire (voir mon article sur le sujet), la dérive d’un traitement batch suite au déploiement de nouveaux utilisateurs sur une application ou l’écroulement progressif d’une ferme ESX du fait d’un manque de suivi des ressources disponibles, …
On le voit les problèmes de performances sont divers et variés et nécessitent une approche méthodologique spécifique pour correctement les appréhender.
Vous avez dit complexe ?!
Au début de cet article je vous parlais de la complexité des problèmes de performances et je vais détailler un peu plus cet aspect dès maintenant.
La complexité est multiple, qu’elle soit :
Technologique : Je ne pense pas enfoncer des portes ouvertes en vous disant que les SIs évoluent continuellement et que les incidents d’hier ne sont plus ceux d’aujourd’hui. On est passé d’application « simple » en 3 tiers avec des services d’infrastructures dédiés, à des applications multiservices utilisant des services d’infrastructure virtualisés. Et encore tout cela, c’était « AVANT » ! Aujourd’hui on parle d’applications phygital (parce que le digital c’est déjà has been !) installées on premise récupérant des données via des micro-services à la fois dans votre application de BI en SaaS et également dans votre CDN hébergé lui dans le cloud public. Si cette phrase vous paraît complexe, imaginez l’architecture de cette application. Et dans cet exemple je n’ai pas parlé de conteneur à la durée de vie éphémère. Ce n’est pas un hasard si l’aspect technologique de la complexité est le premier que j’ai choisi. De nos jours maîtriser les performances de son SI n’est vraiment pas simple. L’interdépendance applicative, la multiplication des modes d’hébergement et de computing font qu’il est de plus en plus nécessaire de disposer d’une vision de bout en bout des transactions avec des outils APM performants.
- Organisationnelle: La complexité croissante du SI a également eu un impact sur l’organisation des équipes. « Notamment la spécialisation de celles-ci dans un domaine applicatif particulier en mode DevOps (« Feature Team ») rend la gestion des performances plus complexe car les services restent mutualisés. On multiplie les responsabilités, les avis divers et la décharge du problème sur tel ou tel service. Or les services étant toujours plus interdépendants, chercher à résoudre un problème de performances en regardant chacun de son côté (le stockage, le réseau (évidemment c’est toujours lui le problème 😊), la base de données…) rend l’action totalement inefficace.
- À effet variable : La complexité a aussi un effet sur la prévisibilité du SI. Plus il est complexe plus son comportement est difficilement anticipable. Les problèmes peuvent apparaître progressivement ou à la suite d’un effet de seuil. Dans le premier cas, l’aspect progressif rend généralement sa résolution moins prioritaire car « sous contrôle » mais il suffit d’un événement exceptionnel pour aggraver la situation et rendre la situation critique. Dans le second cas, le manque d’anticipation et la prise de décision de nouveaux déploiements sur la base d’abaques empiriques provoquent souvent un effet de seuil et un comportement totalement différent de la solution. À titre d’exemple l’exécution d’une requête par le moteur de base de données dépend fortement du volume de données à traiter et la durée peut très vite devenir exponentielle.
On pourrait lister encore bien d’autres facteurs de complexité mais ceux-ci me semblent les plus impactant. Ce qu’il faut en retenir c’est qu’une approche méthodique d’un problème de performances avec une analyse transverse et s’appuyant sur des données vérifiées et vérifiables, ainsi que des projections mesurables, est une nécessité dans les SI d’aujourd’hui.
Les piliers de la perf !
Outre l’approche méthodologique dans la résolution d’un problème de performances, il faut également adopter une méthodologie dans la prise de mesure et leur caractérisation.
Par expérience j’ai appris à mesurer les performances selon 3 axes :
- L’activité ou l’ensemble des actions et des tâches supportées par le système (le nombre d’utilisateurs connectés, le nombre d’actions réalisées, le nombre de factures fournisseurs saisies…)
- Les ressources ou l’assortiment des moyens mis à disposition pour fournir un niveau de service raisonnable quelle que soit l’activité du système (le temps CPU, les I/O, la consommation mémoire…)
- Les niveaux de service ou la mesure de la qualité du service en fonction de l’activité et des ressources consommées (les temps de réponses, les temps d’attente, les temps d’exécution…)
L’objectif est de définir des indicateurs selon ces 3 axes pour chaque couche de service du SI et de les croiser pour obtenir des ratios, des classements et tout autre indicateur pertinent dans la gestion des performances.
Il va falloir nous quitter ! ☹
Nous arrivons maintenant à la fin de cet épisode. Mon objectif pour aujourd’hui était de vous faire prendre conscience de la complexité des SIs actuels et du véritable intérêt de la mise d’une gestion des performances du SI à travers une méthodologie.
Dans le prochain épisode nous parlerons des sources de données et de leur qualification ainsi que de l’intérêt d’une approche scientifique pour gérer dans l’instant, dans la durée et en anticipation l’évolution des performances du SI.
Thibault LABRUT – Architecte Solution
