Les entreprises de toutes tailles, de toutes nationalités et de tous secteurs ont ainsi lourdement investi par exemple dans les ERP pour rechercher la transversalité des processus de gestion, de distribution et de fabrication.
Dans les foyers, l’avènement d’Internet entraîne de nouveaux comportements des clients-internautes, des partenaires et fournisseurs et implique un effort continu et conséquent de mise à niveau, voire de révolution du système d’Information et notamment des applications métiers des entreprises.
La rapidité d’adaptation doit cependant respecter un certain nombre de fondamentaux en matière de disponibilité et de performances sans quoi le Système d’Information failli à la mission qui lui revient dans la stratégie de développement de l’entreprise.
Quels sont dès lors les comportements à observer lorsque la performance globale d’une application s’avère insatisfaisante ?
Une approche très répandue quand les performances sont en berne : En mode panique, tout le monde sur le pont pour trouver le coupable !
La conception et la qualité du code de l’application sont bien sur des éléments déterminants de sa performance et l’équilibre entre le fonctionnel et le technique un facteur clé dans le comportement futur de l’application.
Mais le comportement de l’application sur l’infrastructure de l’entreprise représente également un fondement de l’édifice : les composants réseaux, les systèmes d’exploitation, les bases de données, les middlewares, les portails, la sécurité… sont autant de couches distinctes qui interagissent et déterminent l’équilibre de l’ensemble.
Or, on observe le plus souvent une approche des problèmes opérationnels liés à cette infrastructure logicielle, parfois inadaptée à la fois au problème posé et aux enjeux qu’ils soutendent :
Les responsables des Systèmes et des réseaux (parfois chez un infogéreur) supervisent, administrent l’ensemble des systèmes d’exploitation, des postes et des serveurs et des réseaux LAN et WAN mais doivent passer la main au DBA quand la Base de Données semble impliquée dans le problème, au service Sécurité, à l’éditeur du progiciel ou au responsable du développement de l’application. S’ensuit le plus souvent un échange plus ou moins constructif et courtois sur l’origine du problème, qui n’est pas forcément aussi immédiat à déterminer qu’il n’y paraissait au départ.
L’enjeu pourtant est de plus en plus déterminant car dans le cyber espace qui est le nôtre aujourd’hui, chaque minute de perdue pour résoudre un problème de performance ou de disponibilité peut affecter le niveau de Service, occasionner un manque-à-gagner ou même une perte nette de résultat.
Dès lors, une approche globale de l’ensemble des couches d’infrastructure, jusqu’à l’application elle-même apparaît clairement comme la meilleure méthode pour résoudre de manière rapide et efficace des incidents complexes qui tendent à ce manifester au même rythme que les changements incessants apportés au Système d’Information.
Cette approche se heurte néanmoins à un obstacle de taille : les individus capables de maîtriser autant de technologies différentes et évoluant si rapidement, s’ils existent, sont de toute façon en nombre insuffisant pour faire face à la demande des entreprises.
La mise en place de méthodes et de processus permettant d’isoler les incidents afin de les reproduire et les analyser est ce qui a été mis en œuvre depuis des décennies en informatique et qui a fait ses preuves. La complexité des « systèmes ouverts » et des nouvelles architectures (Web, SOA…), rend la tâche particulièrement ardue aujourd’hui et nécessite d’avoir recours à des méthodes et des outils adaptés.
Pour employer une analogie, comment imaginer violons, cuivre, percussions et piano soliste jouer harmonieusement un concerto rien qu’en lisant une partition ?
Le chef d’orchestre en matière de résolution de problème d’infrastructure logicielle a ceci de commun avec le musicien qu’il n’a pas nécessairement la virtuosité de ses collaborateurs, mais qu’en revanche il sait lire les partitions pour les faire jouer ensemble.
De même il dispose des répétitions avant le concert pour affiner la cohérence d’ensemble, tout comme l’application en pré-production pourra être intégrée dans son contexte, testée, et stressée en condition quasi opérationnelle pour anticiper son comportement avant la mise en production.
Enfin, comme le chef d’orchestre doit faire corps avec ses musiciens au service de l’œuvre qu’ils interprètent, une approche transversale doit permettre de coordonner les différents acteurs informatiques de la DSI (conception, développement, intégration, réseau, bases de données, sécurité etc…) pour identifier les causes réelles des goulets d’étranglement.
De l’homo sapiens cartographicus dynamicus…
Dans la phase d’intégration d’une application, il est encore possible de simuler tous types de charges, de stress afin d’affiner et valider l’architecture cible, et anticiper son point d’inflexion « performance » lors de la montée en charge des utilisateurs.
Des outils performants existent sur le marché qui permettent de réaliser les tests fonctionnels, unitaires et de montée en charge censés représenter la réalité à venir.
Trop souvent cependant, les résultats s’avèrent peu cohérents et même en décalage avec ce que réserveront les réalités de la production.
La raison en est qu’en production, l’impact réciproque entre l’infrastructure et l’application est absolument fondamental sur les performances et que par conséquent, il est indispensable d’une part de tester l’application dans son environnement d’infrastructure cible et d’autre part, de mesurer très finement les impacts de l’application à chaque point de l’infrastructure pour évaluer et corriger les dysfonctionnements.
Une cartographie dynamique ainsi réalisée permet d’assainir le comportement d’une application avant même de penser à simuler de la charge utilisateurs.
…A l’homo sapiens non- intrusivus !
En phase opérationnelle, il arrive que l’épreuve des faits s’avère plus problématique qu’escompté en raison de tests non représentatifs ou de changements non prévus (événement organisationnel ou technique majeur, accroissement soudain de la clientèle…).
Là aussi, il convient de mesurer l’ensemble des composants qui constituent l’application en mettant en œuvre une technologie capable à la fois de fournir tous les éléments pertinents de l’application - et pas nécessairement plus- et en évitant un phénomène bien connu des scientifiques de l’atome : le risque de distorsion induite par l’outil lui-même sur les mesures du phénomène observé.
Les outils utilisés doivent dès lors respecter ces deux aspects cruciaux : la complétude des données collectées et le caractère non intrusif des moyens de mesure.
La mise en œuvre des moyens de mesure implique fortement tous les départements clés de la DSI et le travail d’équipe vers un objectif commun prend alors tout son sens.
Par ailleurs, de plus en plus, les causes des problèmes de performance applicative sont à la fois multiples et asynchrones. Il convient donc de mesurer l’application à des endroits stratégiques, aux périodes de pics et sur plusieurs jours pour obtenir la matière première « données » nécessaire au diagnostic.
Ces endroits stratégiques sont chacun des composants de l’infrastructure, les internes de l’application et les localisations représentatives des utilisateurs
En effet, la mesure des éléments d’infrastructure apporte un éclairage indispensable sur les problèmes de performance. Mais encore faut-il le corréler avec le vécu des utilisateurs de l’application (ou des internautes), c'est-à-dire caractériser ce problème, le quantifier (fréquence, intensité) et le comparer à la norme.
Le diagnostic lui-même est une étape très lourde qui implique alors d’analyser jusqu’à plusieurs téraoctets de données et d’en corréler et synthétiser les résultats au travers du filtre de l’expert « chef d’orchestre ».
La compétence technique, la capacité d’analyse, l’intuition et l’expérience de l’expert sont ses meilleures armes pour diagnostiquer correctement l’origine réelle des problèmes.
Les modifications qui découlent de cette démarche de bout en bout peuvent concerner des paramétrages réseau, des upgrades de versions d’éléments d’infrastructure, des optimisations de bases de données etc, mais peuvent aller jusqu’à des modifications de code applicatif ou de choix d’architecture.
En pérennisant ces prises de mesure, un tableau de bord peut également permettre alors aux différents intervenants internes sur l’application (les responsables fonctionnels et techniques, les différents intervenants techniques) d’obtenir une vision synthétique et pertinente à leur niveau de l’application et en même temps de partager la même vision synthétique et factuelle de la situation.
Enfin, le suivi dans le temps de la performance applicative est un élément d’autant plus crucial que les changements vécus par le Système d’Information sont fréquents. Conserver la maîtrise de l’application et son infrastructure demande une méthode et un effort continuel pour que le dispositif mis en place ne tombe pas en désuétude et ne devienne inopérant.
La gestion des infrastructures applicatives implique une vision globale qui n’est possible que par une dynamique provenant de la Direction des Systèmes d’Information car l’enjeu dépasse de loin les composants techniques. La notion de Contrat de Services en interne, les contraintes de disponibilité et de réactivité qu’impliquent les comportements des utilisateurs ou des internautes et l’impact souvent déterminant sur les résultats de l’entreprise en font un défi majeur de la DSI.
La mise en place d’outils et méthodes adaptés à l’environnement technique et humain, l’accompagnement des utilisateurs et la mise en œuvre de bonnes pratiques sont les éléments clés de la réussite d’un tel projet. Et si les bases de l’architecture applicative sont solides, la DSI peut alors concentrer ses forces sur la mise en musique des métiers de l’entreprise…
Pour contacter l'auteur : www.qsconsultants.eu
Dans les foyers, l’avènement d’Internet entraîne de nouveaux comportements des clients-internautes, des partenaires et fournisseurs et implique un effort continu et conséquent de mise à niveau, voire de révolution du système d’Information et notamment des applications métiers des entreprises.
La rapidité d’adaptation doit cependant respecter un certain nombre de fondamentaux en matière de disponibilité et de performances sans quoi le Système d’Information failli à la mission qui lui revient dans la stratégie de développement de l’entreprise.
Quels sont dès lors les comportements à observer lorsque la performance globale d’une application s’avère insatisfaisante ?
Une approche très répandue quand les performances sont en berne : En mode panique, tout le monde sur le pont pour trouver le coupable !
La conception et la qualité du code de l’application sont bien sur des éléments déterminants de sa performance et l’équilibre entre le fonctionnel et le technique un facteur clé dans le comportement futur de l’application.
Mais le comportement de l’application sur l’infrastructure de l’entreprise représente également un fondement de l’édifice : les composants réseaux, les systèmes d’exploitation, les bases de données, les middlewares, les portails, la sécurité… sont autant de couches distinctes qui interagissent et déterminent l’équilibre de l’ensemble.
Or, on observe le plus souvent une approche des problèmes opérationnels liés à cette infrastructure logicielle, parfois inadaptée à la fois au problème posé et aux enjeux qu’ils soutendent :
Les responsables des Systèmes et des réseaux (parfois chez un infogéreur) supervisent, administrent l’ensemble des systèmes d’exploitation, des postes et des serveurs et des réseaux LAN et WAN mais doivent passer la main au DBA quand la Base de Données semble impliquée dans le problème, au service Sécurité, à l’éditeur du progiciel ou au responsable du développement de l’application. S’ensuit le plus souvent un échange plus ou moins constructif et courtois sur l’origine du problème, qui n’est pas forcément aussi immédiat à déterminer qu’il n’y paraissait au départ.
L’enjeu pourtant est de plus en plus déterminant car dans le cyber espace qui est le nôtre aujourd’hui, chaque minute de perdue pour résoudre un problème de performance ou de disponibilité peut affecter le niveau de Service, occasionner un manque-à-gagner ou même une perte nette de résultat.
Dès lors, une approche globale de l’ensemble des couches d’infrastructure, jusqu’à l’application elle-même apparaît clairement comme la meilleure méthode pour résoudre de manière rapide et efficace des incidents complexes qui tendent à ce manifester au même rythme que les changements incessants apportés au Système d’Information.
Cette approche se heurte néanmoins à un obstacle de taille : les individus capables de maîtriser autant de technologies différentes et évoluant si rapidement, s’ils existent, sont de toute façon en nombre insuffisant pour faire face à la demande des entreprises.
La mise en place de méthodes et de processus permettant d’isoler les incidents afin de les reproduire et les analyser est ce qui a été mis en œuvre depuis des décennies en informatique et qui a fait ses preuves. La complexité des « systèmes ouverts » et des nouvelles architectures (Web, SOA…), rend la tâche particulièrement ardue aujourd’hui et nécessite d’avoir recours à des méthodes et des outils adaptés.
Pour employer une analogie, comment imaginer violons, cuivre, percussions et piano soliste jouer harmonieusement un concerto rien qu’en lisant une partition ?
Le chef d’orchestre en matière de résolution de problème d’infrastructure logicielle a ceci de commun avec le musicien qu’il n’a pas nécessairement la virtuosité de ses collaborateurs, mais qu’en revanche il sait lire les partitions pour les faire jouer ensemble.
De même il dispose des répétitions avant le concert pour affiner la cohérence d’ensemble, tout comme l’application en pré-production pourra être intégrée dans son contexte, testée, et stressée en condition quasi opérationnelle pour anticiper son comportement avant la mise en production.
Enfin, comme le chef d’orchestre doit faire corps avec ses musiciens au service de l’œuvre qu’ils interprètent, une approche transversale doit permettre de coordonner les différents acteurs informatiques de la DSI (conception, développement, intégration, réseau, bases de données, sécurité etc…) pour identifier les causes réelles des goulets d’étranglement.
De l’homo sapiens cartographicus dynamicus…
Dans la phase d’intégration d’une application, il est encore possible de simuler tous types de charges, de stress afin d’affiner et valider l’architecture cible, et anticiper son point d’inflexion « performance » lors de la montée en charge des utilisateurs.
Des outils performants existent sur le marché qui permettent de réaliser les tests fonctionnels, unitaires et de montée en charge censés représenter la réalité à venir.
Trop souvent cependant, les résultats s’avèrent peu cohérents et même en décalage avec ce que réserveront les réalités de la production.
La raison en est qu’en production, l’impact réciproque entre l’infrastructure et l’application est absolument fondamental sur les performances et que par conséquent, il est indispensable d’une part de tester l’application dans son environnement d’infrastructure cible et d’autre part, de mesurer très finement les impacts de l’application à chaque point de l’infrastructure pour évaluer et corriger les dysfonctionnements.
Une cartographie dynamique ainsi réalisée permet d’assainir le comportement d’une application avant même de penser à simuler de la charge utilisateurs.
…A l’homo sapiens non- intrusivus !
En phase opérationnelle, il arrive que l’épreuve des faits s’avère plus problématique qu’escompté en raison de tests non représentatifs ou de changements non prévus (événement organisationnel ou technique majeur, accroissement soudain de la clientèle…).
Là aussi, il convient de mesurer l’ensemble des composants qui constituent l’application en mettant en œuvre une technologie capable à la fois de fournir tous les éléments pertinents de l’application - et pas nécessairement plus- et en évitant un phénomène bien connu des scientifiques de l’atome : le risque de distorsion induite par l’outil lui-même sur les mesures du phénomène observé.
Les outils utilisés doivent dès lors respecter ces deux aspects cruciaux : la complétude des données collectées et le caractère non intrusif des moyens de mesure.
La mise en œuvre des moyens de mesure implique fortement tous les départements clés de la DSI et le travail d’équipe vers un objectif commun prend alors tout son sens.
Par ailleurs, de plus en plus, les causes des problèmes de performance applicative sont à la fois multiples et asynchrones. Il convient donc de mesurer l’application à des endroits stratégiques, aux périodes de pics et sur plusieurs jours pour obtenir la matière première « données » nécessaire au diagnostic.
Ces endroits stratégiques sont chacun des composants de l’infrastructure, les internes de l’application et les localisations représentatives des utilisateurs
En effet, la mesure des éléments d’infrastructure apporte un éclairage indispensable sur les problèmes de performance. Mais encore faut-il le corréler avec le vécu des utilisateurs de l’application (ou des internautes), c'est-à-dire caractériser ce problème, le quantifier (fréquence, intensité) et le comparer à la norme.
Le diagnostic lui-même est une étape très lourde qui implique alors d’analyser jusqu’à plusieurs téraoctets de données et d’en corréler et synthétiser les résultats au travers du filtre de l’expert « chef d’orchestre ».
La compétence technique, la capacité d’analyse, l’intuition et l’expérience de l’expert sont ses meilleures armes pour diagnostiquer correctement l’origine réelle des problèmes.
Les modifications qui découlent de cette démarche de bout en bout peuvent concerner des paramétrages réseau, des upgrades de versions d’éléments d’infrastructure, des optimisations de bases de données etc, mais peuvent aller jusqu’à des modifications de code applicatif ou de choix d’architecture.
En pérennisant ces prises de mesure, un tableau de bord peut également permettre alors aux différents intervenants internes sur l’application (les responsables fonctionnels et techniques, les différents intervenants techniques) d’obtenir une vision synthétique et pertinente à leur niveau de l’application et en même temps de partager la même vision synthétique et factuelle de la situation.
Enfin, le suivi dans le temps de la performance applicative est un élément d’autant plus crucial que les changements vécus par le Système d’Information sont fréquents. Conserver la maîtrise de l’application et son infrastructure demande une méthode et un effort continuel pour que le dispositif mis en place ne tombe pas en désuétude et ne devienne inopérant.
La gestion des infrastructures applicatives implique une vision globale qui n’est possible que par une dynamique provenant de la Direction des Systèmes d’Information car l’enjeu dépasse de loin les composants techniques. La notion de Contrat de Services en interne, les contraintes de disponibilité et de réactivité qu’impliquent les comportements des utilisateurs ou des internautes et l’impact souvent déterminant sur les résultats de l’entreprise en font un défi majeur de la DSI.
La mise en place d’outils et méthodes adaptés à l’environnement technique et humain, l’accompagnement des utilisateurs et la mise en œuvre de bonnes pratiques sont les éléments clés de la réussite d’un tel projet. Et si les bases de l’architecture applicative sont solides, la DSI peut alors concentrer ses forces sur la mise en musique des métiers de l’entreprise…
Pour contacter l'auteur : www.qsconsultants.eu
