Retour au blog
critères de choix pour une solution de supervision IT

Supervision, comment concilier vos critères de choix – retour d’expérience

Le choix d’une console de supervision informatique peut faire face à des attentes différentes en fonction des équipes concernées. L’objectif de cet article est de présenter un cas concret ayant mis en exergue les contraintes de choix et les solutions apportées.

Analyse des besoins

La direction peut orienter les choix autour de la lisibilité du reporting, les capacités de présentation et la facilité d’intégration avec l’existant ainsi que le coût bien sûr. Ci-dessous quelques exemples de tableaux de bord sur lesquels la direction effectue un choix entre différents produits.

Tableau DSI
Figure 1 Exemple1 Tableau DSI
Tableau DSI 2
Figure 2 Exemple2 Tableau DSI
Tableau DSI 3
Figure 3 Exemple3 Tableau DSI

Les experts techniques peuvent orienter leurs choix sur les capacités techniques des solutions et leur intégration dans l’écosystème IT. Ci-dessous quelques exemples de tableaux de bord techniques sur lesquels les experts réseaux évaluent l’adéquation des solutions. 

Tableau de bord technique Netflow 1
Figure 4 Tableau de bord technique Netflow – Exemple 1
Tableau de bord technique Netflow 2
Figure 5 Tableau de bord technique Netflow – Exemple 2
Tableau de bord technique Netflow 3
Figure 6 Tableau de bord technique Netflow – Exemple 3

Les exploitants de la solution peuvent orienter leurs choix sur la lisibilité des alertes et les facilités d’administration ainsi que la facilité de gestion au quotidien. Ci-dessous quelques exemples de cartographie sur lesquels les exploitants notent les différentes solutions.

Tableau de bord Cartographie 1
Figure 7 : Tableau de bord Cartographie – Exemple 1
Tableau de bord Cartographie 2
Figure 8 Tableau de bord Cartographie – Exemple 2
Tableau de bord Cartographie 3
Figure 9 Tableau de bord Cartographie – Exemple 3

Les utilisateurs de l’IT sont rarement consultés, mais peuvent avoir besoin d’une visibilité globale sur l’état des services qu’ils utilisent. Une demande en ce sens est à traiter.

Demande de visibilité du pôle utilisateur
Figure 10 Demande de visibilité du pôle utilisateur

Analyse des choix

Les besoins de la direction et des utilisateurs ont été rapidement solutionnés en tenant compte de l’usage effectif de la console de supervision 

  • En effet la direction a besoin de tableaux de bords adaptés, mais ceux-ci sont soit disponibles au niveau de l’outil ou au niveau d’un outil de reporting connecté à la console. L’essentiel est de permettre un accès à des tableaux de bord.
    • Les utilisateurs ont besoin d’une information synthétique très simple sur l’accessibilité des services de l’entreprise afin de réorienter leurs travaux ( Internet, Messagerie , ERP, Accès Sites Administratifs), l’ajout d’un icône ( Systray Windows ) sur l’état global des services s’avère suffisant.

Ces 2 points ont mis en avant la nécessité de disposer d’un produit permettant des intégrations tierces simples.

Les besoins de l’équipe d’experts et des exploitants ont été plus délicats à concilier sur cette entreprise :

  • Les exploitants étant évalués sur la capacité à minimiser les pannes et la MTTR.
  • Les experts étant évalués sur la capacité à résoudre les pannes plus complexes et à l’amélioration des performances globales.

Le choix d’un outil permettant de répondre principalement aux attentes des experts a eu le vent en poupe au départ, néanmoins l’impact de pannes basiques a été cité en s’appuyant sur l’expérience de Toyota en 2023 :

(AFP – 2023) – La panne informatique géante qui a paralysé toutes les usines de Toyota au Japon pendant une journée la semaine dernière était due à une capacité insuffisante de stockage de données, a expliqué mercredi le numéro un mondial de l’automobile. 

Dans un communiqué, le constructeur automobile explique que le problème provient d’un serveur qui s’est trouvé à court d’espace disque, en raison d’une erreur dans un processus de maintenance IT le 27 août dernier, soit la veille de la panne.

Ceci a mis en avant la nécessité de disposer d’un produit et d’une intégration permettant d’offrir des vues adaptées à chaque équipe. L’analyse de l’outillage existant de l’équipe d’expertise a conduit à affiner le besoin réel en diagnostic. 

Les démonstrations éditeurs ne permettant pas d’évaluer la complexité pour une mise en œuvre commune aux 2 équipes, un POC a été réalisé avec en priorité le traitement d’un accès différencié à chaque service.Le POC a permis de mettre en pratique les besoins attendus et d’effectuer un choix éclairé conciliant les différentes parties prenantes.

Conclusion

Un choix de console s’appuie notamment sur :

  • Un périmètre technique (réseau, systèmes, applicatifs)
  • Une liste de besoins techniques 

Les points complémentaires pouvant permettre de maximiser le ROI du projet et son acceptance peuvent être sur :

  • La capacité d’intégration de solutions tierces (API et validation des intégrations tierces)
  • La connaissance de l’usage effectif par les différents services
  • La capacité des produits à disposer d’interfaces utilisateurs spécifiques pour chaque service.
  • La connaissance des outils existants dans l’entreprise afin éventuellement d’aller au-delà du besoin en supervision pour minimiser le nombre d’outils (concept ITOM).

Enfin un POC doit permettre de vérifier, non pas que les produits de supervision sont en capacité de superviser car c’est leur fonction première mais plutôt de valider des points spécifiques qui sont liés à l’usage et à la vie de la solution (facilité d’administration, point d’usage spécifique, exemple d’intégration avec un outil tiers,…)