Newsletter ALALOOP -  Mars 2009

Tableaux de bord techniques & décisionnels pour le reporting du S.I.

Tableaux de bord : un outil efficace de pilotage des coûts du S.I.

"On n'améliore que ce que l'on mesure" affirme William Deming. Cette évidence admise aujourd'hui de tous est également vraie concernant les budgets d'exploitation du S.I.. C'est ce que nous avons démontré dans un livret blanc "Approche économique Alaloop" que vous pouvez télécharger sur notre site à l'adresse : http://www.alaloop.com/index.php/acces-documentation.html

Bonne lecture !

Jean-Louis Mélin, PDG d'Alaloop

Stratégies de mesure des performances d'applications et du ressenti utilisateur (QoE)

De nombreuses questions nous sont régulièrement posées sur les stratégies possibles de test des applications. Nous résumons ci-dessous les deux stratégies principales en dégageant leurs objectifs et caractéristiques.

Data Center centric : une vision pour comprendre et résoudre les problèmes

Elle consiste à positionner les robots de mesure à la frontière de responsabilité entre le Data Center et l'opérateur du réseau WAN, pour :

• valider localement les performances des applications (Service Delivery) grâce à un robot qui exécute des tests unitaires de l'application ;

• valider la capacité des liens réseaux de l'opérateur WAN vers les sites utilisateurs distants, à transporter les flux d'application dans de bonnes conditions.

Cette stratégie suppose d'avoir qualifié en phase de développement les délais de transit nécessaires pour un bon fonctionnement de l'application, sur le réseau WAN. Dans la pratique, il n'est pas rare que les applications soient déployées sans tenir compte de leur fonctionnement sur des liens WAN bas débit !

Une enquète rapide auprès de quelques utilisateurs tests, couplée à l'observation des délais réseau, permettra de déterminer le délai réseau minimal pour assurer un bon ressenti utilisateur.

User centric : une vision du "ressenti utilisateurs" (QoE : Quality of Experience)

Elle consiste à positionner les robots de mesure qui exécuteront les tests de ressenti utilisateur (QoE) sur les sites distants, au plus près des utilisateurs réels. Ils utiliseront les applications dans les mêmes conditions que ces derniers (*). 
On choisira donc de préférence des robots logiciels installés sur des postes standards de l'entreprise, soumis aux mêmes règles de mise à jour. Cela ne va pas sans poser des problèmes d'exploitation de mesure : arrêts intempestifs du poste sur lequel fonctionne le robot, arrêt des mesures en cas de mise à jour logicielle, etc... Enfin, il faut garder présent à l'esprit que la multiplication des robots de ressenti utilisateur (QoE) génère du trafic réseau et entraine une charge supplémentaire de l'application.

(*) Le strict ressenti utilisateur est souvent difficile à assurer dans la mesure où un robot logiciel exécute plus rapidement un script d'utilisation d'application que ne le ferait un opérateur humain.

Comparaison des deux approches

Stratégie de mesure suggérée par Alaloop : une double approche (Application +QoE)

Nous préconisons une approche centralisée (Data Center centric) qui peut être complétée par des robots de ressenti utilisateur-QoE (User centric) sur quelques sites distants représentatifs. L'avantage principal de cette démarche est son faible coût d'instrumentation en regard des résultats obtenus.
En effet, les coûts d'une instrumentation complète pour la mesure d'application sont souvent élevés avec de fréquentes tâches d'administration. Compte tenu de l'expérience acquise sur de nombreux environnements logiciels, nous recommandons une approche graduelle qui permet d'éliminer rapidement la grande majorité des problèmes sans recourir nécessairement à une instrumentation complexe.

Cette approche est représentée dans le schéma ci-contre.

On distingue :

- 1 robot (Alaloop ASA) de test des performances d'application sur le Data Center ;

- 1 robot (Cisco IP-SLA) de test des performances de l'infrastructure réseau pour le transport des flux d'application vers les sites distants ;

- quelques robots logiciels sur des PC standards pour valider le ressenti utilisateur.

Hébergement des portails Alaloop

Afin de répondre aux interrogations concernant l'hébergement des portails Alaloop, nous analysons ci-dessous les 3 modes d'hébergement proposés. Nous rappelons que les échanges sont limités et sécurisés entre le portail et l'instrumentation présente sur l'Intranet Client.

1/ Data Center Alaloop et liaison instrumentation sur VPN Internet

Cette solution, disponible depuis novembre 2008, est désormais l'offre de référence.

Avantages : réactivité du CSC (Centre Service Clients) pour toutes les opérations de MCO et l'évolution du portail, aucun coût direct/indirect d'hébergement pour le client.

Inconvénient : translation d'adresses IP.

2/ Data Center Alaloop et liaison instrumentation sur ligne louée

Cette solution est une variante de la précédente. Elle permet de raccorder directement le portail dédié du Client sur son Intranet.

Avantages : identiques à la solution précédente avec en outre le portail dans le plan d'adressage du Client.

Inconvénient : coût de la ligne dédiée.

3/ Data Center Client

Cette solution, proposée à l'origine, est toujours possible si la mise en place d'un VPN Internet ou l'hébergement du portail s'avère irréalisable.

Avantage : le portail est intégré dans l'environnement Client.

Inconvénients : ils découlent de l'éloignement des serveurs du CSC Alaloop dans le cadre d'un service managé (difficultés pour assurer la maintenance, les sauvegardes, les évolutions matérielles et logicielles). Signalons également un coût plus élevé, ainsi que les frais d'hébergement, à la charge du Client.