Il faut repenser la surveillance réseau en fonction de l'interaction utilisateur

Le Cloud, un défi pour le réseau

C'est un dilemme frustrant pour Forrest Schroth, particulièrement lorsque l'on sait que son entreprise s'oriente de plus en plus vers les logiciels à la demande. Ainsi la messagerie de l'entreprise s'est tournée vers le service Cloud de Microsoft Office 365 et plusieurs unités métier utilisent des ERP en SaaS.

Face au Cloud, Forrest Schroth recherche l'outil unique qui l'aidera à surveiller la qualité de l'interaction de l'utilisateur avec toutes les applications, et à intervenir sur celle-ci.

« Pour le moment, le groupe réseau exécute son propre jeu d'outils et le groupe applications le sien. Si un incident se produit, nous nous réunissons en cellule de crise et combinons nos données pour identifier le problème », explique-t-il.

Mais même forte de cette collaboration, l'identification des problèmes avec la majorité des logiciels de surveillance réseau s'avère difficile. En effet, les fournisseurs de solutions SaaS ne vous laissent généralement pas examiner l'intérieur de leurs environnements.

Forrest Schroth d'ajouter : « Ils ont tendance à vous renvoyer la responsabilité, et à dire que tout a l'air normal dans leur base de données lorsque vous avez conclu au bon déroulement de la transaction... jusqu'à ce qu'elle atteigne leur réseau. »

Pour éviter toute incidence sur l'utilisateur, un responsable IT comme Forrest Schroth s'appuie sur des procédés de contournement qui simulent l'interaction de l'utilisateur avec les applications Cloud, ou qui surveillent les événements susceptibles de gêner les performances du réseau et des applications.

Par exemple, certaines équipes IT déploient des capteurs et des agents dans l'ensemble du réseau pour reproduire et surveiller les situations auxquelles les utilisateurs sont confrontés en termes de temps de réaction des applications. D'autres doublent le matériel existant, notamment les pare-feu, pour obtenir des éclaircissements sur les événements susceptibles de ralentir, voire de bloquer, le trafic.

L'opacité du Cloud peut retarder, voire empêcher, la résolution des problèmes par les équipes d'administration réseau. Pourtant, selon John Burke, Directeur informatique et principal analyste chercheur chez Nemertes Research, les fournisseurs SaaS n'ont aucun intérêt à vous laisser surveiller les performances de leurs systèmes internes.

« C'est l'endroit où s'arrêtera toujours la visibilité des administrateurs réseau », explique-t-il.

Selon lui, cet obstacle s'aborde de trois manières :

1. L'une d'elles consiste à utiliser des sondes de gestion des performances des applications – sondes APM (Application Performance Management) – soit en ligne, soit depuis un port d'écoute (SPAN), afin de surveiller le trafic et de s'assurer que requêtes et réponses fonctionnent correctement.
2. Une autre possibilité consiste à recourir à un optimiseur ou à un équipement de délégation (proxy) – sous forme matérielle (équipement) ou logicielle (service) – capable de fournir des données sur les performances.
3. Enfin, la troisième possibilité consiste à placer des agents sur les appareils et les postes bureautiques afin de surveiller la durée des transactions.

« Il n'en reste pas moins que, si vos transactions réseau requièrent des temps de réaction fiables et prévisibles, choisir une solution SaaS sur un réseau public tel qu'Internet devrait automatiquement vous paraître suspect en termes stratégiques », explique John Burke.

Faire ressortir l'invisible

Selon Shamus McGillicuddy, analyste en chef de la gestion réseau chez Enterprise Management Associates, la frustration des administrateurs réseau comme Forrest Schroth dans ses relations avec les fournisseurs de solutions SaaS n'a rien d'exceptionnel.

« Nos études indiquent qu'un grand nombre d'administrateurs réseau se rendent compte de l'adoption de solutions SaaS en “informatique invisible” uniquement lorsque quelqu'un vient solliciter leur assistance du fait d'un problème, explique-t-il. Les équipes chargées des réseaux n'ont donc aucun moyen de contrôle mais n'en sont pas moins pointées du doigt. »

Parallèlement au soutien qu'apportent les sources traditionnelles d'informations sur les performances (telles que journaux de pare-feu ou les données de trafic de commutateur), les administrateurs réseau peuvent déployer des outils de surveillance de nature synthétique pour mieux comprendre l'interaction entre l'utilisateur et les services en Cloud.

Ces outils de surveillance synthétique font appel à des sondes. Installées à différents emplacements sur le réseau, celles-ci procèdent à des tests par commande ping pour vérifier le temps de réponse des applications. Ces outils effectuent également des tests qui déterminent, entre autres tâches, le délai nécessaire, par exemple, au chargement d'une présentation Web dans une fenêtre de navigateur.

Toutefois, Shamus McGillicuddy n'estime pas nécessaire que les fournisseurs de solutions SaaS offrent une visibilité totale sur leurs réseaux. Ce n'est pas pour autant qu'il faut leur laisser toute latitude, notamment si vos outils et logiciels de surveillance réseau détectent de leur côté un problème qui enfreint l'accord de niveau de service (SLA) dont vous bénéficiez.

« Vous payez pour un service, et non pour une infrastructure, explique-t-il. Si vous surveillez votre réseau dans les règles de l'art et garantissez qu'il affiche un fonctionnement de haut niveau – et êtes en mesure de prouver à votre fournisseur de solutions SaaS qu'une interaction utilisateur donnée est traçable jusqu'au Cloud – alors vous pouvez vous assurer que ce dernier est conscient de tout problème éventuel et qu'il y remédie dans les délais impartis. »

Des capteurs pour historiciser les connexions et les problèmes

La Stevenson University de Baltimore complète sa boîte à outils de surveillance réseau (surveillance du trafic SNMP, des systèmes Windows et des services) avec des « outils plus élaborés », comme l'explique Robert Hutter, responsable des systèmes réseau et d'entreprise de l'établissement.

La Stevenson University compte 4 000 étudiants à plein temps et près de 1500 enseignants et personnels répartis sur trois campus. Elle s'assure que l'interaction utilisateur est optimale grâce aux capteurs du logiciel de surveillance réseau PRTG de Paessler. Ils permettent de simuler des scénarios répandus, tels que l'ouverture d'une session ou le téléchargement de fichiers depuis Internet.

« Cette approche élimine le caractère manuel des tests », explique Robert Hutter.

Les capteurs contribuent parallèlement à l'identification d'autres problèmes et à une intervention sur ceux-ci. Par exemple, si les capteurs détectent que les utilisateurs de campus différents n'arrivent pas à se connecter, Robert Hutter sait qu'il est très probablement en présence d'un problème au niveau d'un des services ou applications hébergés que l'université utilise.

Et le même de poursuivre : « Cette approche nous donne davantage de poids pour faire appliquer nos SLA ».

La capacité de procéder à une analyse d'historique constitue un autre avantage des capteurs. Ces données sont agrégées et analysées par la plateforme PRTG et, dans certains cas, archivées sur une durée allant jusqu'à un an.

« Nous pouvons, par exemple, examiner la sollicitation des ressources d'un serveur particulier sur un an, ou suivre les changements de mode d'utilisation d'Internet en périodes de pointe, explique Robert Hutter. Sans données d'historique de long terme, ni surveillance constante, il y a de quoi s'arracher les cheveux. En revanche, l'installation de capteurs vous permet d'accélérer les processus d'exploration, de dépannage et, au final, de résolution. »

En matière de performances et de disponibilité du réseau, Robert Hutter recommande de jouer la transparence auprès des utilisateurs. L'université publie une page Web qui répertorie les indisponibilités passées, en cours et planifiées.

« Les utilisateurs ont désormais le réflexe de consulter le site Web », explique-t-il. Résultat : une interaction utilisateur plus efficace et qui inspire davantage la confiance, même lors de chutes temporaires de performances.

Fortification du pare-feu

Responsable de l'exploitation technique au City College de San Francisco – établissement fort de plus de 60 000 étudiants, 2 000 membres du personnel et 8 sites répartis sur la ville – Tim Ryan a dû adapter la stratégie d'assistance de son équipe informatique à des schémas de trafic changeants.

« Nous avions pour habitude de nous assurer que chacun bénéficiait du même confort d'interaction en normalisant l'infrastructure jusqu'au moindre port de commutateur et jusqu'à la moindre carte réseau, explique-t-il. La technologie sans fil a introduit une variable par laquelle l'interaction de chacun devenait différente. » 

Plutôt que d'investir dans davantage de logiciels de surveillance réseau et autres outils, Tim Ryan a attribué à son parc de pare-feu Check Point et Palo Alto Networks un rôle accru quant à la surveillance des interactions utilisateur avec les ressources installées tant sur site qu'en Cloud.

Parallèlement au contrôle des autorisations fixes, les pare-feu déterminent désormais si la latence s'accroît au-deçà d'un seuil donné ou si le nombre de paquets abandonnés atteint un niveau inacceptable.

« Ces deux fonctions ont une incidence évidente sur l'interaction utilisateur », explique Tim Ryan.

Forts de plus de 50 millions d'entrées de journal quotidiennes, les pare-feu révèlent également menaces et vulnérabilités, offrant ainsi des éclaircissements supplémentaires lorsqu'un virus ou un logiciel malveillant est susceptible d'affecter les performances du réseau ou des applications pour un groupe d'utilisateurs donné.

Avec un nombre croissant d'applications telles que la messagerie qui migrent vers le Cloud, Tim Ryan s'attend à dépendre encore davantage de ces journaux en termes d'intelligence.

Et le même de poursuivre : « Si le fonctionnement de nos applications en Cloud ralentit, nous disposons d'informations exploitables. »

Chez Cross Country Healthcare, Forrest Schroth considère que l'interaction utilisateur atteindra son nirvana lorsqu'il trouvera un outil holistique capable de fournir, pour les applications SaaS, la visibilité de bout en bout dont il dispose déjà pour les applications sur site. Son rêve : une surveillance réseau qui combinerait mesures du fonctionnement du réseau et délais des transactions au niveau applications.

Et Forrest Schroth d'avouer : « Je n'ai pas encore trouvé ».