Archives mensuelles : septembre 2012

Introduction à la performance des systèmes d’information

Cet article a pour objectif de poser quelques définitions de base qui seront reprises dans une suite d’articles à venir sur la gestion des performances des Systèmes d’Information, qui traiteront différents points de vue : pilotage du niveau de service, optimisation du temps de réponse des applications, plan de capacité, déploiement de grands systèmes applicatifs, optimisation des ressources, etc.

La gestion des performances d’un SI est un problème délicat pour deux raisons :
parce que les SI sont de plus en plus complexes d’une part et parce que d’autre part la performance d’un SI ou d’une application est une notion relativement complexe en soit. La performance, à l’image d’autres notions transversales du SI comme l’urbanisme ou la
sécurité, est en effet une notion vaste qui exige différents points de vue pour être correctement traitée.

Beaucoup de SI rencontrent de fait des problèmes de performance qui se traduisent
par des symptômes assez différents comme des écroulements sous des pics de charge (par exemple dans des périodes de solde ou de clôture comptable), des changements d’échelle douloureux voire impossible quand l’activité d’une application ou d’un système s’accroît fortement, des coûts techniques qui dérivent de manière non
proportionnelle avec l’activité, des niveaux de service qui se dégradent et pénalisent les utilisateurs métier, des instabilités techniques récurrentes, etc.

Notre conviction est que certains problèmes de performance sont des problèmes complexes et qu’à ce titre, ils exigent une démarche particulière, et une vision relativement globale et structurée de la problématique. Le développement de la complexité des systèmes d’information ne fait qu’accroître ces cas où de nouvelles approches, ou au moins des approches utilisées dans d’autres domaines que celui de
l’informatique de gestion, deviennent nécessaires.

Quelques exemples de problèmes de performance
complexes

Tous les problèmes de performance ne sont pas complexes, fort heureusement. Quand il s’agit seulement de corriger une anomalie dans un programme, d’optimiser un
traitement ou une requête dans une base de données, d’accroître la puissance d’un serveur, les processus naturels et standards du développement et de l’exploitation des SI sont suffisants pour résoudre les problèmes qui peuvent apparaître et qui sont de fait
plus des incidents que de vrais problèmes au sens ITIL du terme.

Mais il y a certains cas où le problème ne se trouve pas facilement isolé sur un
point d’expertise où la bonne compétence dans la DSI apportera naturellement et facilement une solution. Il y a des cas, où même en « payant » et en ajoutant des
ressources le problème n’est pas résolu pour autant et des cas où, si le problème reste mal posé, il n’a pas de solution.

Voici quelques exemples où une approche plus globale est nécessaire :

  • Améliorer la performance d’une fonction critique complexe : certaines
    fonctionnalités sont difficiles à mettre en œuvre et la tenue des exigences de performances peut être structurellement délicate, par la complexité des traitements, la multiplicité des applications à faire collaborer ou les contraintes de temps pour traiter les volumes. Quelques exemples :

    • Assurer une vision « temps réel » des stocks pour une entreprise
      de distribution multi-canal avec des stocks distribués (fournisseurs, entrepôts, magasins, partenaires logistiques).
    • Assurer les pics de transactions de sites internets pendant des périodes de
      promotion ou des ventes flash, en garantissant la disponibilité
      des stocks.
    • Assurer un calcul d’optimisation logistique ou d’approvisionnement dans un temps limité pour tenir les délais et contraintes des partenaires
      logistiques.
  • Dimensionner une infrastructure pour une cible de déploiement : dans le cadre
    du déploiement d’une solution à l’échelle d’un grand groupe ou d’une montée en charge associée à une évolution forte d’une activité métier, il est souvent nécessaire d’anticiper la capacité de la solution à prendre en charge la montée en charge
    et d’avoir un « coup d’avance ». L’enjeu est de garantir le niveau de service et la capacité à aligner les infrastructures requises, sans « sur-investir » ni mettre en péril
    l’activité métier.
  • Améliorer les performances d’une solution applicative globalement médiocre :
    certaines applications issues de développements lourds et longs sont mises en service sous une forte pression de délais, au détriment d’un temps de qualification et d’optimisation suffisant. En conséquence, les problèmes de performances surgissent au fil du déploiement, avec l’augmentation de l’activité et l’accroissement
    du volume de données d’historique. Traités trop tardivement ces problèmes peuvent bloquer le déploiement, voire créer des incidents opérationnels graves en nuisant à des processus métier critiques pour l’entreprise.
  • Identifier et traiter une contention de ressources qui impacte toutes ou plusieurs
    fonctions : certains problèmes de performances n’ont pas de cause manifeste aisée à cerner. Les contentions peuvent être liées à l’architecture de la solution et à des contentions indirectes ou subtiles entre différentes ressources.
  • Réguler et absorber un pic d’activité : le dimensionnement d’une
    infrastructure pour supporter l’intégralité d’un pic de charge est souvent trop coûteux, surtout s’il n’y a pas d’enjeux incontournables métier à tenir un délai de traitement strict. La mise en place de mécanisme de délestage est pour autant souvent subtile à mettre en place, et en particulier doit favoriser les
    processus ou clients/usagers les plus critiques du service (favoriser les transactions d’achat par rapport aux transactions d’information par exemple). Cette régulation demande une coordination très forte entre vision fonctionnelle (des besoins et
    priorités) et vision technique (des contraintes de ressources).
  • Maîtriser la durée d’un plan batch : garantir qu’un plan batch de nuit ne
    dépassera pas la fenêtre allouée est sans doute l’exemple le plus complexe des problèmes de performances. Beaucoup de facteurs influencent cette performance : la complexité et la structure des traitements, leur capacité ou non à être parallélisés (eux mêmes ou entre eux), les dépendances fonctionnelles qui en
    contraignent l’ordonnancement, les contraintes induites par d’autres applications ou partenaires externes, les grands volumes à traiter, la fluctuation de l’activité au cours du temps, etc.

Quels sont les principaux facteurs de complexité ?

Il est probablement impossible de dresser la liste des facteurs qui peuvent influer sur la complexité des performances d’un SI ou d’une application, mais les suivants sont certainement les principaux :

  • La complexité des solutions et technologies : le premier facteur est clairement celui de la complexité des solutions et technologies. La fragmentation des tiers, l’interdépendance des applications, la complexité des technologies sous-jacentes, la rapidité de leur évolution et de leur obsolescence, la multiplication des progiciels, l’introduction de services en mode SaaS, la virtualisation des ressources… Tous ces éléments rendent la compréhension des problèmes de performance plus délicate. Cette complexité est un fait qui ne changera pas et risque au contraire de continuer à s’accélérer.
  • La multiplication et la dispersion des expertises : cette complexité s’accompagne d’une fragmentation des expertises, tant sur les solutions fonctionnelles, applicatives que techniques. Dans des DSI où ces mêmes experts sont souvent déjà fortement sollicités, il est difficile de les faire travailler efficacement ensemble.
  • Le manque de points de mesures : on pense trop rarement dans ces solutions complexes à les doter de moyens de mesures efficaces (au delà des fondamentaux du socle d’infrastructure de base) permettant d’en comprendre finement le comportement et les dysfonctionnements éventuels.
  • L’absence de repères : cette complexité et ces multiples expertises font perdre les repères sur ce qui est « normal » versus ce qui ne l’est pas. Dans un contexte où le plus souvent, les technologies « masquent » une partie de la complexité, il n’est plus très facile pour un administrateur SAN d’identifier le comportement anormal en IO d’une application, pour un administrateur de base de données d’identifier des requêtes en anomalie ou une mauvaise conception des données, pour un développeur de comprendre les conséquences d’un de ses choix d’architecture logicielle, etc.
  • Les effets d’échelle : le comportement des technologies n’est pas similaire à toutes les échelles, une base de données qui traite un volume de données de quelque Go de données utiles, ne se comporte pas comme une base qui en traite des To. Une application Java pour 50 utilisateurs internes ne se comporte pas comme un site
    internet soumis à des pics d’activité de milliers d’utilisateurs par nature incontrôlables. Pour autant, les technologies, les experts et les développeurs sont souvent les mêmes.
  • La progressivité de la dégradation : les problèmes de performance sont rarement détectés « au bon moment » et apparaissent souvent de manière progressive ou à l’occasion de périodes exceptionnelles où la solution est sollicitée de manière anormale. Cet enlisement progressif dans les sables mouvants de la dégradation des performances endort les acteurs et lorsque le problème se révèle vraiment, il peut être trop tard pour agir…
  • La difficulté d’anticipation et d’extrapolation : il est structurellement difficile de prévoir le comportement d’un système complexe. C’est d’ailleurs un des facteurs de caractérisation d’un système complexe : son comportement ne peut plus se prévoir
    simplement par celui de ses parties.
  • La négociation des solutions : les problèmes de performance réellement complexes s’accordent rarement d’une solution technico/technique « locale » et nécessitent plutôt un compromis entre contraintes technologiques, complexité
    et délai de développement et besoin métier. Cette « négociation » est rarement perçue comme telle par tous les acteurs mais donne souvent au contraire lieu à des affrontements stériles entre études et production, ou DSI et utilisateurs.

Trois points de vue indissociables…

La notion de performance n’a pas de sens dans l’absolu. Il n’est pas pertinent de parler d’une application ou d’un SI performant ou non performant sans mettre en relation trois axes majeurs qui caractérisent vraiment et pleinement la performance. Ces trois axes principaux sont :

  • le travail à effectuer, où en termes informatiques le volume et la complexité des traitements à effectuer sur les informations. Autrement dit : quelle complexité intrinsèque de traitement, indépendamment de l’implémentation qui peut en être faite. Ce travail à effectuer est à mesurer sur plusieurs plans :
    • le volume des données effectivement à traiter, en discernant ce qui doit lu, mis à jour, créé ou supprimé par le traitement,la complexité algorithmique du traitement en termes d’accès aux données, de calculs et de mise à jour de données.
    • le modèle de charge du travail qui définit le profil de la charge : est-il
      étalé ou au contraire astreint à des pics ou périodes particulières ?
  • le temps imparti pour effectuer ce travail : cette dimension temps de
    traitement est déterminante pour caractériser la performance. Ce temps de travail peut selon les cas se mesurer en millisecondes (pour la proposition de mots clés dans un moteur de recherche au fil des saisies), en secondes (pour les temps d’attente d’un utilisateur dans le cadre d’une transaction interactive), en minutes (pour l’attente d’un traitement de restitution) ou en heures (pour des traitements lourds de type batch). La relation au temps est
    éminemment subjective et doit être autant que possible mise en perspective des enjeux opérationnels et du coût associé au temps pour le métier. La mesure du temps pour une solution d’enchère en ligne n’est pas la même que pour un traitement de facturation mensuel.
  • les ressources utilisées pour effectuer ce travail : il s’agit là d’identifier toutes les ressources employées. Les plus évidentes sont les capacités de traitement (secondes CPU) du ou des serveurs assurant le traitement ou le volume des données
    stockées sur disque. Mais il y a d’autres ressources employées qui sont à prendre en compte : comme la mémoire, le nombre et le volume des entrées / sorties (lié en partie à la mémoire), le nombre et le volume d’échanges réseau, etc.

La difficulté de ces trois points de vue est qu’il ne sont pas maîtrisés par les mêmes
acteurs de l’entreprise, ni en termes de causes réelles, ni en termes de conséquences. Et à l’évidence, ils s’opposent. On comprend bien qu’il est plus difficile de traiter vite un travail
plus difficile ou plus volumineux, ou que traiter plus vite est susceptible de consommer plus de ressources. Tant que ces points de vue peuvent être conciliés, il n’y a pas de soucis particuliers : par exemple si les utilisateurs acceptent le « surcoût » de davantage de ressources ou l’impact de temps de traitements allongés. En revanche, si ce n’est pas le cas, il faut arbitrer ces trois points de vue et trouver les meilleurs compromis.

Conclusion

Ce premier article pose les bases de la problématique de la performance des SI. Dans un prochain article, seront abordés le coût de la gestion des performances, les modèles permettant de d’appréhender la performance et la démarche générale proposée par enioka pour gérer la performance des SI.