L’organisation de la supervision [partie 2]

Dans cette partie, nous présentons les différents rôles qui sont sous le périmètre de l’équipe supervision, et quel périmètre ces rôles couvrent. N’hésitez pas à commenter.

Les rôles de l’équipe supervision

L’équipe supervision intervient tout au long de la vie des applications. Dans votre organisation actuelle, vous ne couvrez pas forcément l’étendue des rôles, parce que le découpage organisationnel, comme expliqué en partie précedemment, n’a pas donné l’espace nécessaire à la supervision.

Ce même découpage a d’ailleurs peut-être scindé les activités d’APM des activités de supervision. Après plus de 10 ans d’exploitation dans la supervision, notamment, je peux dire que c’est un tort, et qu’à l’usage, il manquera forcément certaines interactions enrichissantes pour l’exploitation qui nuiront à l’efficacité de l’activité. Les intervenants métiers ont besoin d’être rassurés, de bénéficier d’indicateurs, et les indicateurs les plus pertinents sont ceux provenant de la supervision. D’ailleurs, des sociétés comme Merethis[1] l’ont bien compris, en ajoutant à leur catalogue la solution CENTREON BI[2], ou je peux aussi citer HP Software[3] et l’intégration de la solution SHR[4] qui fournit le même genre de service.

Je propose donc de s’attarder ci-dessous sur les différents rôles existants.

Le design de l’infrastructure de supervision

La supervision couvre un agrégat de solutions, ayant chacune leur périmètre de couverture, avec un niveau de finesse différent permettant de répondre aux besoins exprimés par le métier.

Pour chaque solution, on peut envisager différentes architectures, selon la réactivité attendue, et selon l’importance du parc informatique et sa complexité. Mettre en place une supervision adéquate, cela revient à monter un projet applicatif complexe.

Il n’est pas simple de choisir une solution parmi les différentes existantes (open-source, propriétaire …)

Une fois ce choix réalisé, la supervision n’étant qu’une maille dans l’écosystème de l’exploitation, il existe de nombreuses interfaces (avec la CMDB, avec la gestion des incidents, …) qu’il faut prendre en compte lors de sa modélisation : c’est un travail qui nécessite une expertise sur le produit retenu, car il ne peut être question d’une expertise supervision « générique » quand on souhaite mettre en œuvre une architecture de supervision pertinente.

Ce rôle est le premier dévolu à l’équipe supervision. Elle doit prendre en compte les nombreuses attentes, tout en garantissant une maîtrise du coût. Elle doit ingérer tous les éléments de son environnement, réfléchir aux besoins client, intégrer les contraintes internes (utilisation de souches, organisation réseau, …) ainsi qu’étudier les différentes solutions du marché afin de répondre au mieux à la demande. Cela demande des POC, des analyses techniques de propositions fournisseurs, des appels d’offres, une connaissance de l’état de l’art actuel, et enfin un véritable travail d’architecte afin de bâtir une solution optimisée.

La définition de supervision

Un deuxième rôle dévolu concerne la définition de la supervision.

Disposer d’une plateforme bien configurée est une base qui n’est d’aucune utilité s’il n’y a pas eu de travail sur les spécifications. Ce travail sous-entend de disposer de ressources qui connaissent d’une part les capacités de la solution de supervision, mais ont aussi un bon background dans le système, et sont capables de discuter avec des intervenants aux caractères divers : experts (oracle, système, réseau, middleware…) mais aussi pilotes d’applications, de façon notable. Ce thème « spécifications de supervision » ayant déjà été abordé en détails, je n’y reviendrais pas dans ce chapitre.

La mise en œuvre de supervision

Une fois les templates de supervision définis, un autre des rôles de l’équipe supervision consiste à appliquer ces templates, à définir et faire vivre le processus de mise en supervision interne, à s’assurer que celui-ci s’intègre bien dans les processus ITIL déjà mis en place au sein de la DSI. Ce rôle est opérationnel, et permet de garantir la qualité de service pour tout nouvel atterrissage d’une application au sein du Système d’Informations, mais aussi la maîtrise de ce qui est mis en place. Ce processus peut s’appuyer sur des outils qui permettent de gérer le cycle de vie (outil de gestion de cycle de vie comme TeeM Monitoring Lifecycle Management, outil de gestion des demandes) ou alors reposer sur des fichiers excels, des développements internes, des formulaires…

Le maintien en condition opérationnelle de la plateforme de supervision

Le maintien en condition opérationnelle comprend :

  • Toutes les opérations de maintenance de la plateforme
  • Toutes les mises à jour des solutions de supervision
  • Toutes les opérations de sauvegarde de la plateforme
  • Toutes les opérations de support de la plateforme

Comme pour n’importe quelle application, l’équipe supervision a dans la liste des tâches qui lui sont dévolues la charge de garantir la disponibilité et les performances de la plateforme de supervision, qui permettra de superviser toutes les autres applications.

Le conseil à la mise en supervision

Quand on est responsable d’une application, il est souvent difficile de savoir ce que l’on doit superviser de ce que l’on ne doit pas superviser. On est souvent tenté de faire de la « surqualité », c’est-à-dire de superviser tout et n’importe quoi pour être sûr de ne rien manquer. On se retrouve alors à superviser des messages « warning » sur lesquels on n’a pas d’action, mais qui pourraient un jour nécessiter de réagir.

Et passent les premières semaines, où l’on se fait déranger toutes les heures, alors qu’il n’y a pas de problème, et où l’on passe ses astreintes à se faire appeler pour des alarmes sans actions. On peut alors être tenté de passer à l’extrémité inverse, et dans ce cas la supervision perd de son efficacité car elle n’offre plus la précision sur l’incident qu’elle pourrait apporter si elle était plus fine.

Ce curseur, c’est à l’équipe supervision de le fixer, conjointement avec les équipes applicatives. L’équipe supervision sait ce qui est mis d’ordinaire en supervision et ce qui ne l’est pas. Ce conseil rassure les équipes applicatives et leur permet, lors de l’atterrissage de leur application en exploitation ou tout au long de sa vie, d’être assuré de la performance de ce qui aura été défini comme supervision.

Mais ce conseil peut aussi monter d’un niveau. Comme exprimé précédemment, il n’existe pas une seule solution de supervision, mais plusieurs, plus ou moins fines et couvrant un périmètre plus ou moins large, même au sein d’une DSI. L’équipe supervision peut alors orienter le responsable applicatif sur ce qui peut être mis en œuvre selon ses impératifs et son budget. Il peut aussi être important de lui déconseiller certaines solutions qui risqueraient de faire de la surqualité alors que les impératifs clients (MTTR, RTO…) ne justifient pas un tel investissement.

L’apport d’éléments à la gestion des problèmes

Il s’agit là d’un rôle de la supervision qui est souvent « sous-exploité ». La gestion des problèmes repose bien souvent sur des recherches d’incidents récurrents dans la gestion des incidents. Or la supervision est la source première d’informations sur les alarmes : il est très simple alors de générer des « top 10 » permettant de connaître les incidents se produisant de manière la plus fréquente, et statuer ensuite s’il s’agit ou non de problèmes. L’analyse de la supervision est ce qui permet de générer le plus grand gain en terme d’optimisation applicative, en remontant mensuellement des « top » et en analysant et traitant les retours.

D’une autre manière, pour un problème en cours d’analyse, les données incluses dans la supervision permettent de remonter au moment de l’incident et de voir tous les effets connexes à l’incident. La supervision « centralise » des informations à forte valeur ajouter, et l’un des rôles de l’équipe supervision est aussi d’accompagner la gestion des problèmes.

Le reporting autour de la supervision

La supervision, comme dit dans le chapitre précédent, regorge d’informations à forte valeur ajoutée.

Ces informations peuvent facilement être utilisées au travers d’une solution de reporting pour alimenter différents comités :

  • Les différents TOP 10 (serveurs en erreur, applications en erreur, erreurs les plus fréquentes…) alimentent des comités d’amélioration continue
  • Les informations de disponibilité infrastructure, ou de disponibilité applicative (récupérée grâce aux robots) permettent d’alimenter des comités de suivi clients
  • Les différentes courbes (mémoire, CPU, disque) peuvent alimenter un capacity planning.

Le reporting peut donc être une tâche à part entière de la supervision et occuper un pant de l’activité de l’équipe supervision.

Les évolutions de la plateforme

Comme toute application, la supervision vit.

Chaque année de nouvelles versions des produits apparaissent, de nouvelles fonctionnalités, et même parfois de nouvelles solutions qui viennent faciliter le quotidien.

Un rôle de l’équipe supervision inclus d’une part de faire de la veille technologique sur les nouvelles sorties, et d’autre part, un vrai travail de fond sur l’inclusion ou non des évolutions sur la plateforme existante, la remise en cause permanente de l’existant au cas où cela pourrait en valoir la peine, et le traitement des différents correctifs apportés.

Ce rôle est très important car il peut avoir de lourds impacts financiers dans les deux sens (le passage du propriétaire au libre retenu par certaines sociétés qui étaient très liées aux éditeurs par exemple)

[1] www.merethis.com, société intervenant dans le libre et créatrice de la solution CENTREON

[2] http://www.centreon.com/Content-Products-Commercial-Products/bi-open-source-and-reports-centreon

[3] www.hp.com, fournisseur notamment de la solution HP OM de supervision/hypervision

[4] http://www8.hp.com/us/en/software-solutions/software.html?compURI=1173047

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 *