Associer la supervision fonctionnelle à la supervision technique

ZOOM SUR LA SUPERVISION FONCTIONNELLE

 

Une application peut parfaitement fonctionner du point de vue technique alors même que certains processus métiers ou certaines fonctions applicatives ne fonctionnent pas correctement ou sont inutilisables à cause de fonctionnements erronés d’un ou plusieurs éléments de l’application ou de temps de réponse trop longs. La supervision fonctionnelle permet de se rapprocher du ressenti des utilisateurs, en jouant automatiquement des scénarios d’utilisation d’applications ou de processus (bout en bout impliquant plusieurs applications) et en plaçant des points de vérification et de mesure des temps de réponse à chaque étape du scénario. Les fonctionnalités et la manière de les tester (scénarios) sont décrites pas à pas puis exécutées à intervalles réguliers et ou selon un calendrier choisi afin, par exemple, de vérifier avant l’arrivée des utilisateurs ou après une mise à jour que toutes les fonctions sont effectivement disponibles avec le niveau de performance attendu. Le jeu régulier des scénarios en 24H/7J permettant aussi de détecter des créneaux clés durant lesquels les performances sont amoindries. Si un des scénarios échoue à une ou plusieurs étapes ou met plus de temps que prévu à s’exécuter, une alerte peut être levée selon le même principe que les alertes de supervision technique (critique s’il s’agit d’un échec ou d’un dépassement de seuil intolérable, warning s’il s’agit d’un dépassement de temps de réponse qui reste « supportable »).

La supervision fonctionnelle aussi appelée surveillance du ressenti utilisateur est la seconde étape des projets de supervision mais reste bien souvent réservée aux grosses organisations disposant de deux services séparés Études et Production ou encore d’une entité DevOps fortement impliquée dans l’automatisation des tests.

Il serait plus aisé de se limiter à cette seule méthode de supervision qui assure effectivement de savoir si une application est disponible et performante pour les utilisateurs. Toutefois, la supervision fonctionnelle ne fait que pointer des étapes en échec ou des dépassements de temps de réponse mais ne permet pas de diagnostiquer l’origine d’un incident ou d’un problème sauf si celui-ci est purement fonctionnel. Si une application web dysfonctionne, le scénario va le détecter et pointer l’étape concernée (absence d’une zone de saisie sur une page par exemple) mais il ne pourra pas préciser l’origine technique de l’incident ou du problème (serveur web, serveur d’application, base de données, réseau, bug …).

A contrario, se limiter à la supervision technique qui elle, offre bien des solutions de diagnostic, présente également des failles puisque cela ne permet ni de trancher entre les problèmes à origine technique et les problèmes à origine fonctionnelle (ce qui est souvent particulièrement utile notamment dans la relation avec les éditeurs), ni d’objectiver les temps de réponse afin de les qualifier (confortables, supportables, intolérables). Ces deux lacunes de la supervision technique engendrent bien souvent des problèmes de communication et une incompréhension entre l’informatique ou plus précisément les exploitants, pour qui les services sont disponibles et les utilisateurs ou les chefs de projets applicatifs, pour qui l’application ne fonctionne pas.

Qui n’a pas vécu, l’indisponibilité d’une application critique alors même que tous les éléments techniques semblaient fonctionner parfaitement ? Situation durant laquelle le dialogue entre les utilisateurs finaux et l’informatique et même entre les services études et les services de production, systèmes et réseaux, tourne souvent à l’orage.

Qui n’a pas vécu, des temps de réponse multipliés par 10 à une certaine heure de la journée, rendant impossible la tenue de ses engagements métiers, alors même que la base de données semblait parfaitement opérationnelle ?

​

​

DOIT ON PRIVILÉGIER LA SUPERVISION FONCTIONNELLE PAR RAPPORT A LA SUPERVISION TECHNIQUE ?

 

Généralement les outils de supervision informatique adressent uniquement les besoins de supervision technique, sans même assurer la consolidation applicative qui est pourtant la finalité du service informatique à rendre aux utilisateurs. Cela cantonne les solutions de supervision à des outils de techniciens et n’assure ni de comprendre aisément l’état applicatif, ni de mesurer l’impact des dysfonctionnements constatés, ni d’être certain que les utilisateurs disposent bien de l’ensemble des fonctions dont ils ont besoin avec le niveau de performance attendu. Par ailleurs, cela ne permet pas aux acteurs du support utilisateurs de disposer de suffisamment d’informations pour réaliser un premier diagnostic, comprendre l’impact d’une alerte, traiter efficacement les incidents, escalader vers les bonnes compétences et assurer une bonne communication avec les utilisateurs.

En outre, la supervision technique seule, n’apporte pas aux gestionnaires fonctionnels des services études et projets les éléments qui les intéressent, aussi bien pour ce qui concerne le suivi des performances que pour la surveillance purement fonctionnelle des applications et processus métiers. Cette lacune les oblige à se tourner vers des solutions dédiées de type robots de tests pour se rapprocher du ressenti utilisateurs et ce faisant ils ne disposent pas de solutions pour investiguer et diagnostiquer. Pourtant, comment analyser, comprendre et résoudre une baisse de performance récurrente sur un créneau horaire particulier, sans disposer du suivi capacitaire ? N’est-on pas plus serein en disposant du suivi de la bande passante pour planifier une requête génératrice d’un flux de données à forte consommation ? Qui n’a pas été témoin d’un dialogue de sourds entre la DSI qui présente des taux de disponibilité et de performance excellents alors que pour les utilisateurs les temps de réponse de l’application la rendent parfois totalement inutilisable ?

​

​

QUELS SONT LES BESOINS DE CHACUN ?

 

Les besoins en termes de supervision informatique ne sont en fait pas identiques selon les acteurs de l’organisation informatique :

1. Les exploitants ont besoin de connaître l’état de fonctionnement de chaque brique et service technique à un instant t, d’être alertés le plus précisément possible et d’en mesurer l’impact et la criticité : en cas de défaillance en cours, afin de corriger l’incident au plus vite (Processus ITIL de gestion des incidents), en cas de risque (dépassement de seuil ou croissance d’un fichier par exemple) afin d’avoir une démarche pro active dans les délais impartis pour anticiper et empêcher la survenue des incidents (augmenter à temps un tablespace ou un espace disque par exemple). Ils ont aussi besoin d’historiser le fonctionnement technique, les incidents, leur récurrence, de les analyser, paralléliser, décortiquer, pour mettre en place une gestion des problèmes visant à éradiquer les incidents récurrents, minimiser les risques, anticiper les besoins, gérer les capacités, avoir une démarche pro active, …

2. Les responsables fonctionnels et chefs de projets ont besoin de savoir si les applications et les processus métiers (traitements, requêtes et flux compris) fonctionnent effectivement et avec des temps de réponse acceptables du point de vue des utilisateurs (Gestion de la performance). Ils ont d’ailleurs ce même besoin en temps « classique » de production mais aussi lors des phases de tests, de préproduction, de recette, en amont des changements comme des mises en production (effets de bord, régression, baisse de performance, …) afin de vérifier que l’ensemble des fonctions restent disponibles, y compris celles qui n’ont a priori rien à voir avec le changement opéré (effets de bord). Ils doivent encore s’assurer que ce changement n’entrainera pas une baisse de performance de tout ou partie de l’application.

3. La Direction des Systèmes d’Information a besoin de savoir si les engagements pris auprès de la Direction Générale et des utilisateurs sont respectés, en termes de disponibilité, continuité et performance des applications. Ils doivent aussi disposer des informations leur permettant de prévoir les besoins à venir notamment en termes de ressources techniques et organisationnelles (Gestion des capacités) parfois à long terme quand les processus d’achat ne leur offrent pas une grande réactivité (marchés publics notamment). Dans une démarche de valorisation de l’apport informatique aux métiers, ils ont aussi besoin de « vendre », de la façon la plus objective et probante, le service rendu, les gains et la valeur ajoutée offerte par l’informatique aux différents métiers. A l’heure où la course aux réductions budgétaires impose de parler retour sur investissement, la DSI ne doit plus être réduite à un centre de coûts. Ces besoins supposent que les services études (projets et changements) et production (systèmes, réseau, support) dialoguent durant toutes les phases de vie des applications, se comprennent et partagent la même vision du fonctionnement, de la disponibilité et de la performance des applications et services informatiques mis à la disposition des métiers.

4. On peut même considérer les métiers, comme un quatrième acteur ayant besoin de savoir, de comprendre, d’être rassurés sur la bonne prise en compte de ses besoins en termes fonctionnels comme de performance et de continuité du service mais aussi lors de mises à jour ou de migrations importantes. L’informatique n’a plus à faire face à des utilisateurs réfractaires à l’informatique ou totalement béotiens dans l’usage, cela ne rend pourtant pas forcément le dialogue entre ces deux mondes plus simples. Il faut vulgariser le fonctionnement et la complexité informatique sans laisser penser qu’il est comparable de faire fonctionner l’informatique d’une entreprise ou d’un établissement public et l’ordinateur « maison » réservé à un usage domestique. La supervision doit dans ce cadre pouvoir servir de vitrine au service informatique.

 

 

PILOT IT UNE SOLUTION DE MONITORING FEDERATRICE

​

Pour réconcilier tous ces acteurs autour d’une même vision, d’un même enjeu, il s’avère utile de mettre en place une supervision répondant aux besoins de l’ensemble des acteurs impliqués, ce qui implique d’associer la supervision fonctionnelle à la supervision technique pour présenter un fonctionnement applicatif fédérateur.

Cette association permettra dans la plupart des cas de statuer sur l’origine technique ou fonctionnelle d’un dysfonctionnement comme d’une baisse de performance et d’objectiver les temps de réponse, évitant ainsi, aussi bien les incompréhensions que les pertes de temps.

 

Si l’on prend l’exemple d’une application donnée, son état consolidé de fonctionnement résultera du contrôle :

• de l’état technique de tous les composants et services dont elle a besoin pour fonctionner de façon optimale (base de données, service web, services applicatifs, serveur, réseau, ressources, …),

• du résultat des scénarios fonctionnels joués (seuils de temps de réponse compris) avec par exemple les étapes suivantes : lancement de l’application, saisie du couple identifiant/mot de passe, ouverture d’une page, saisie de texte, modification d’un élément déclenchant l’ouverture d’une page, enregistrement puis déconnexion de l’application.

 

Si un scénario est en échec ou avec des temps de réponse intolérables, soit l’état technique permettra d’en comprendre les raisons et d’intervenir rapidement, soit tous les composants techniques semblent fonctionner correctement et cela permettra de se focaliser sur la recherche d’une cause fonctionnelle.

 

La solution doit donc présenter un état consolidé des différents services dont l’application a besoin pour fonctionner et des tests fonctionnels (temps de réponse compris) associés, pour offrir au service support les informations utiles et pertinentes afin qu’il puisse intervenir dans les meilleurs délais et avec la meilleure efficacité.

 

Répondre à ces 4 besoins, tous essentiels, au travers d’une même solution de supervision, en mesure d’associer la supervision fonctionnelle à la supervision technique pour en déduire une véritable supervision applicative, présentera ainsi autant d’avantages organisationnels que techniques. Cela fédèrera l’ensemble des acteurs autour d’un même outil, consolidant les résultats des contrôles techniques et des tests fonctionnels comme de leur suivi et proposant des alertes elles aussi consolidées en une même vision du fonctionnement applicatif, celui du service effectivement et objectivement rendu aux utilisateurs.

 

Associer la supervision fonctionnelle à la supervision technique dans un même outil, assure aussi un meilleur partage d’informations entre les équipes puisque cet outil partagé dans un même objectif doit être enrichi aussi bien par les projets, impliqués dans les scénarios de tests fonctionnels, que par les exploitants, en charge du déploiement et du paramétrage de la supervision technique.

 

Cela permettra au service support comme aux astreintes, en prise direct avec les utilisateurs, de jouer tout leur rôle de communication, de primo diagnostic et d’escalade vers les bons interlocuteurs, réduisant ainsi l’effet goulot d’étranglement et perte de temps dans les remises en service.

 

Les résultats des contrôles fonctionnels et de performance, automatisés dans des scénarios joués périodiquement par l’outil de supervision, au même titre que les résultats des contrôles techniques lancés, peuvent ainsi être mis en parallèle et pris en compte dans le calcul de la disponibilité applicative. Les mêmes tests jusque-là utilisés uniquement à des fins de tests et recettes avant mises en production peuvent d’ailleurs être ainsi réutilisés en contexte de production, ce qui ajoute l’efficience à la pertinence.