Archives mensuelles : avril 2013

Approche générale des problèmes de performance

Chaque type de problème de performance mérite une démarche adaptée, mais il se dégage néanmoins une approche générale des problèmes de performances qu’il est d’autant plus nécessaire de suivre que le problème est complexe. Voici quelques principes généraux à appliquer pour prévenir, diagnostiquer et résoudre des problèmes de performance.

Des objectifs de niveau de service

Au départ d’une démarche de performances, il doit impérativement il y a avoir des objectifs à atteindre définis en termes mesurables non subjectifs. Par exemple un temps de réponse de transactions clés, un temps d’exécution d’un traitement, une durée pour un plan batch, un délai pour traiter des messages, etc. Cet exercice de formalisation est  nécessaire pour échapper au « tout tout de suite » qui est l’expression naturelle du besoin utilisateur sans contraintes. La définition d’objectifs de niveau de service est avant tout  une analyse du besoin et de la valeur attendue du SI. C’est aussi un premier niveau de  négociation d’un compromis acceptable entre besoin et coûts.

Une implication de toutes les compétences et de tous les acteurs

Pour traiter les trois axes des performances (charge, niveau de service, ressources) il faut faire collaborer efficacement des représentants métier/organisation, des acteurs du  développement de la solution, des experts des technologies et des exploitants qui opèrent la solution au quotidien et en pilote le fonctionnement. Cette collaboration doit s’appuyer sur des processus (ITIL notamment), sur des outils (métrologie, tableaux de bord, outils
d’extrapolation/prévision) et sur des hommes. La collaboration décloisonnée entre organisations est essentielle pour le succès. Les solutions ne sont pas toujours exclusivement dans les technologies ou même le développement. L’analyse des  problèmes peut amener les clients à reconsidérer l’organisation du travail pour un compromis globalement plus efficace.

Un respect des « bonnes pratiques » d’architecture

Ceci permet très en amont de garantir des marges de manœuvre dans la solution pour traiter les problèmes de performances éventuels. Ces bonnes pratiques ne sont hélas pas toujours les plus en vogue, car elles ont tendance à promouvoir des solutions qui ont fait leurs preuves au détriment de solutions prétendument innovantes.

Certains principes d’architecture sont les garants les plus sûrs de certains écueils classiques sur lesquels des générations d’informaticiens se sont déjà cassés les dents. Privilégier la « scalabilité »
des infrastructures, limiter les fonctions centrales uniques surtout dotées d’un stock de données, modulariser les fonctions et les données des systèmes complexes en les découplant au maximum (notamment en termes de ressources), ne pas chercher à réinventer ce que fait très bien une base de données (notamment en termes de cache ou de tri), etc.

Une démarche scientifique

Modèle, mesure et prévisions ! Au cœur de travaux sur la performances d’un SI, il doit il y avoir une démarche scientifique de construction de modèles qui expliquent ce qui est observé et qui doivent permettre de prévoir ce qui se passera plus tard. La confrontation  entre la prévision et la réalité est le moyen le plus efficace d’identifier et de comprendre les anomalies. Par exemple, paralléliser un traitement en deux processus, doit permettre de réduire le temps de traitement par près de deux. Si ce n’est pas le cas, c’est qu’il y a des ressources en contention ou que le traitement n’est pas parallélisé efficacement.

Une démarche pragmatique et hiérarchisée

Modèle ne signifie pas « usine à gaz », cela doit rester un outil pragmatique au service de
la résolution des problèmes et rester au niveau de précision suffisant pour obtenir les résultats attendus. La démarche doit également toujours privilégier les actions simples aux gains très probables, aux actions complexes aux conséquences délicates à
anticiper. De même, la relation étroite avec les clients du service (ou leurs représentants) doit permettre de hiérarchiser les problèmes et de traiter les priorités ; les problèmes
les plus visibles ne sont pas nécessairement les plus prioritaires et les plus dangereux pour l’ensemble de la solution.

Une remise en cause des évidences

Il s’avère quelque fois que les solutions mises en œuvre sont inadaptées pour traiter les besoins exprimés. Il faut savoir remettre en cause les besoins ou les solutions pour échapper à de telles impasses. Par exemple, certains usages peuvent solliciter une
solution applicative d’une manière suffisamment particulière pour justifier des développements spécifiques (par exemple : des factures avec un nombre de lignes très élevé par rapport à la moyenne, des volumes de données très asymétriques selon les
entités clientes, etc). La solution peut également être inadaptée parce qu’elle propose une architecture qui structurellement ne peut pas assurer le service demandé. Il est par exemple vain d’attendre d’une architecture asynchrone de garantir un temps de traitement très court et très constant ou à l’inverse d’attendre d’un service synchrone unitaire de traiter efficacement un grand volume d’événements.

Une valorisation objective des gains et des coûts

Pour les opérations lourdes, il est important de peser les coûts, les bénéfices attendus et  les risques encourus avant de les lancer. Il faut s’assurer en outre de la faisabilité et de la portée des gains au plus tôt. Cet exercice peut aider à prioriser les travaux et à favoriser les actions les plus efficaces. Le risque est important, notamment en présence d’experts chevronnés et soucieux de bien faire, de traiter d’abord ce qui valorise l’expertise au  détriment de ce qui est essentiel.

Un suivi dans le temps

Les problèmes de performance complexes ne se font ni ne se défont en un jour. La maîtrise des performances est un travail qui s’inscrit dans la durée et doit être porté par des processus pérennes des équipes de la DSI. Les problèmes sont souvent décelables par une analyse continue et un suivi dans le temps, avant de devenir des risques véritables pour les utilisateurs. Ce suivi dans le temps, commence en amont du projet, dès la conception, en phase de recette notamment avec des tests de performance, en phase de déploiement en anticipant chaque étape du déploiement, et en fonctionnement récurrent pour surveiller et détecter toute dérive inexpliquée (pour aligner les ressources ou mener les travaux d’amélioration et d’optimisation).

Une communication efficace

Pour mobiliser toutes les compétences et tous les acteurs, pour ne pas démobiliser les clients et leur (re)donner confiance dans la solution, il est indispensable de communiquer efficacement. Cette communication doit à la fois être la plus objective (en s’appuyant sur des mesures incontestables) et la plus transparente possible (en identifiant les problèmes et en rendant public le processus de leur résolution). Elle doit également donner de la visibilité sur le plan d’amélioration pour permettre à chacun de percevoir la démarche et d’aider de son mieux en attendant la résolution cible. Par exemple, des utilisateurs peuvent mieux supporter des mesures transitoires même contraignantes si la cible est bien identifiée.