Les spécifications de la supervision [partie 1]

Cet article poursuit le travail engagé de dégrossissement de l’activité des responsables supervision. Bonne lecture, et encore une fois n’hésitez pas à nous faire part de vos remarques.

Les spécifications de la supervision

Les spécifications de la supervision, c’est la seconde grande épine dans le pied d’un responsable d’équipe supervision. Il s’agit en effet d’un exercice difficile : Où commencer ? Où s’arrêter ? bien souvent, les spécifications sont réalisées « sur le tas », et on se retrouve avec une supervision inadéquate.

Mais plutôt que de traiter de manière rhétorique le sujet, je vous propose de commencer en vous présentant des exemples, bien réels, de choix partis d’un bon sentiment qui ont mené à de véritables catastrophes en terme de supervision. Rappelez-vous une chose : si la supervision est mal paramétrée, alors soit il faudra plus de gens pour la maintenir (€), soit elle ne sera pas efficace, et donc l’impact se portera sur la relation avec votre (ou vos) client(s).

Cas 1 : La formation sur le tas

J’ai rencontré ce cas dans de nombreuses entreprises dans lesquelles la DSI a grossi dans un faible laps de temps, et pour laquelle les compétences initialement prévues ne sont plus adaptées.

C’est l’exemple d’une société qui avait un parc d’une trentaine de serveurs, et pour laquelle la supervision n’était pas la priorité, donc elle était confiée à un expert système qui avait installé du Nagios, avec peut être du CENTREON, et définissait le paramétrage dont il pensait avoir besoin pour superviser ses machines. Puis vint le jour ou le parc se mit à compter 400 serveurs (merci la virtualisation) et l’expert système s’est retrouvé à conserver cette activité sur un coin de table, sauf que la maîtrise n’était plus du tout la même, les attentes en hausse et la ressource bien incapable de répondre au besoin.

Dans le cas énoncé ci-dessus, on ne se retrouve avec aucune spécification. La supervision au fil de l’eau sans réflexion d’ensemble peut être adaptée à de petits contextes, mais devient vite caduque quand on augmente le nombre de machines ou la complexité des demandes de supervision.

Cas 2 : L’achat d’une solution propriétaire

Ce cas est aussi extrêmement fréquent. Les éditeurs vendent des solutions qui arrivent avec des packages de supervision en standard, qui incluent tous les indicateurs dont vous pouvez avoir besoin mais surtout beaucoup qui ne sont pas forcément utiles.

On se retrouve donc avec une console submergée d’alertes qu’on ne sait pas traiter, et la situation tourne vite au cauchemar, à savoir un impact réel sur la qualité de service, et l’impossibilité de faire appel au support de l’éditeur car ce paramétrage dépend d’un intégrateur qui n’est plus là.

Bilan : de l’argent dépensé et un résultat plus que douteux. Là encore, il manque le travail de spécifications qui reste spécifique sur bien des points au contexte du client.

Cas 3 : la migration entre 2 solutions

Cet exemple est particulièrement illustratif d’un point important à aborder : il ne faut pas confondre « remontées standards d’une solution éditeur » et spécifications.

Une société dotée d’un grand parc informatique avait pris le pari de migrer sa supervision de la solution d’un éditeur à celle d’un autre. Le choix technique avait été fait de cataloguer toutes les supervisions et remontées de la solution de l’ancien éditeur, et de faire le nécessaire pour retrouver toutes ces supervisions dans la solution de l’éditeur cible. Bilan :

  • 2 ans de projet.
  • Une supervision très mal adaptée à l’outil cible
  • 30 000 lignes de scripts en tout genre

Comme je le disais plus haut, ce n’est pas parce qu’un outil offre des supervisions qu’il faut les mettre en œuvre. Le premier travail consiste toujours à purger la supervision pour la limiter à l’essentiel : les spécifications.

Intérêt des spécifications

Malgré les messages passés au travers de ces exemples, je pense que vous ou vos managers avez du mal à valoriser le fait de « gâcher du temps » dans la réalisation de spécifications. C’est pourquoi il me semble important de détailler plus avant les apports, et surtout les intérêts connexes :

  • Mettre en place des spécifications, cela permet de maîtriser ce que l’on veut voir remonter et s’assurer que nos experts sauront quoi faire des alarmes produites
  • Mettre en place des spécifications, cela permet de disposer d’un catalogue de supervision qui pourra être enrichi par la suite.
  • Mettre en place des spécifications, cela permet d’impliquer les experts dans le processus de mise en supervision et c’est un facteur de succès pour une DSI
  • Mettre en place des spécifications, cela permet de garantir une réactivité optimale sur incidents
  • Mettre en place des spécifications, cela permet de diminuer le temps d’actions sans valeur ajoutée des pilotes.
  • Mettre en place des spécifications, cela permet de rassurer le client sur l’atterrissage de toute nouvelle application.

(à suivre : comment mettre en place des spécifications pertinentes)

0 réponses

Répondre

Vous souhaitez vous joindre à la discussion ?
N'hésitez pas !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *