Aller au contenu

Rater l’implémentation de sa solution de supervision (à tous les coups) : les 10 erreurs les plus courantes

Blog Rater l’implémentation de sa solution de supervision (à tous les coups) : les 10 erreurs les plus courantes

La supervision fait partie du paysage IT depuis si longtemps qu’on en oublie souvent que le déploiement d’une solution de supervision doit respecter des règles bien précises. Parce que nombre de solutions sont proposées en open source ou simplement parce que la supervision n’est pas toujours envisagée comme un projet à part entière, nombre d’utilisateurs de solutions de supervision s’enlisent dans des situations complexes au moment du déploiement. Nous sommes allés faire un tour au support technique et avons listé, avec les techniciens Centreon, les erreurs les plus courantes qui amènent à rater (à coup sûr), son projet d’implémentation de la supervision.

1. Ne pas affecter les bonnes compétences sur ce projet (un stagiaire ça suffira largement)

De nombreux projets de supervision commencent par des tests effectués sur une solution accessible en open source. Si un besoin de supervision est identifié, l’open source permet d’accéder rapidement et sans coût non seulement à une solution complète mais aussi à une communauté. De fil en aiguille, le test devient un projet, affecté au stagiaire de passage. Comme tout projet, le projet de supervision doit être cadré et se voir affecter des ressources adaptées et en nombre suffisant. Même si le stagiaire est brillant, seul et sans sponsor, son projet risque vite de devenir difficile à gérer et à maintenir.

2. Ne pas se former (pas besoin c’est open source)

Le monde open source le sait bien. Il y a une réelle tendance à oublier de se former dès qu’il s’agit d’utiliser des outils open source. Est-ce la gratuité du produit ou la réputation d’une communauté qui pousse les utilisateurs à jouer les « self-made-monitoring-pros » ? Certes, il sera toujours possible de parvenir à ses fins mais il est bien dommage de passer deux heures à intégrer une nouvelle sonde alors qu’il suffit de quelques minutes pour le faire si on est formé. En passant à côté des possibilités offertes par l’outil, le projet peut en pâtir et ne pas bénéficier de toute la valeur ajoutée de la solution.

3. Tout superviser d’un coup (celui qui a peur est un peureux…)

Un vieux dicton dit que « qui trop embrasse mal étreint ». La puissance offerte par les solutions de supervision ne doit pas pousser à mettre la charrue avant les bœufs. Aller trop vite, trop loin et trop rapidement peut amener à l’abandon du projet par manque de ressources financières ou humaines. Un projet de supervision doit rester ambitieux mais être déployé à un rythme adapté, étape par étape, afin de s’assurer de la réussite du projet et accompagner le changement.

4. Personnaliser à outrance la solution de supervision (puisque c’est possible…)

L’un des points forts d’une solution comme Centreon est la possibilité pour ses utilisateurs de personnaliser et coder tout en bénéficiant d’un socle commun. Cette ouverture qui a fait le succès de la solution ne doit pas non plus amener une personnalisation à outrance de la plate-forme de la solution. Le mieux est l’ennemi du bien… En effet, le risque sera alors de s’éloigner des standards et de perdre le bénéfice de la standardisation et des mises à jour et évolutions proposées par l’éditeur. Parmi les conséquences directes de l’ultra-personnalisation, on notera des temps de migration importants ou de fonctionnalités spécifiques non compatibles en cas de montée de version.

5. Rester dans son coin (je ne parle pas aux inconnus)

La communauté open source est une source intarissable d’informations et d’expériences partagées dont il serait dommage de se priver. La supervision est un métier en perpétuelle évolution et plus encore depuis quelques années avec la tendance DevOps qui fait évoluer en profondeur les pratiques IT. Échanger avec l’éditeur et la communauté est un élément indispensable à la réussite d’un projet de supervision.

6. Dupliquer le projet précédent (qui a 10 ans mais qui marchait)

Dupliquer le projet que l’on avait mené précédemment avec un autre outil présente le risque au mieux de reproduire les mêmes erreurs, au pire de ne pas réussir à mener à terme le projet de déploiement. Les processus se définissent aussi en fonction de l’outil que l’on a choisi. Changer d’outil est ainsi l’occasion de remettre à plat les pratiques de supervision et en améliorer la performance. Repenser ses processus permet de les améliorer mais aussi de tirer parti de la puissance et des fonctionnalités du nouvel outil utilisé.

7. Surdimensionner le projet (histoire de se faire plaisir)

Avec des outils de supervision toujours plus puissants et plus automatisés, on peut être tenté de voir grand. Tellement grand que le projet de supervision finit par être surdimensionné… Certes, cela permet de se faire plaisir mais cela ne répondra pas aux attentes des utilisateurs IT et métier …

8. Collecter des données sans savoir ce que l’on va en faire (ce qui est pris n’est plus à prendre)

La donnée est devenue le nerf de la guerre en matière de business comme en matière de SI. Il est important de collecter des données afin de pouvoir ensuite les analyser, les corréler et produire les bons indicateurs, pour les bonnes personnes et au bon moment. On peut donc être tenté de collecter tout ce qui est accessible sans pour autant réfléchir et anticiper l’utilisation future de ces données. Trop de données tue la donnée ! Il est important d’anticiper l’utilisation qui sera faite des données afin de ne stocker que ce qui est nécessaire et éventuellement de définir une durée de rétention pour les données de type reporting, logs ou données numériques pour les graphiques de performance.

9. Penser uniquement technique (que veux-tu que le marketing comprenne à l’IT ?)

La performance du système d’information impactant de plus en plus le business des entreprises, la supervision occupe aujourd’hui une place essentielle dans le dispositif IT des entreprises. La qualité et la disponibilité du SI impactent directement le business et les équipes métiers ont besoin d’accéder à des indicateurs qui leur sont propres sur le niveau de performance de leurs outils.

10. N’avoir confiance qu’en soi-même (l’éditeur ? quel éditeur ?)

L’éditeur développe des solutions clés en main, testées par des utilisateurs différents et déployés dans des contextes variés. Il dispose d’une vision globale des possibilités offertes par son outil et maîtrise son cœur de métier. Il a développé une réelle expertise dans son domaine, issue de l’expérience de tous ses clients. Une expertise qu’il a à cœur de partager avec tous ses clients.

Lire aussi :

Partager

Facebook picto Twitter picto Twitter picto

Publications similaires

Découvrez comment Centreon va transformer votre business

Restez informés sur notre actualité