L’organisation de la supervision [partie 3]

Dans cette partie, nous présentons les différents profils existant dans la supervision, ainsi que les organisations qui existent chez les clients.  N’hésitez pas à commenter.

Profils existants dans la supervision

Après la première phase qui a eu pour but de dresser la liste des tâches que l’on pouvait adresser au sein de l’équipe supervision, nous allons dresser la liste des profils que l’on peut communément trouver au sein d’une équipe supervision, ainsi que leur champ d’action (reprenant la section précédente).

Ces profils existent dans toutes les sociétés de service, et comme vous pourrez le voir, n’ont pas forcément les mêmes forces/faiblesses. Le cursus pour ces différents profils est bien souvent court : la montée en compétence dans le domaine de la supervision est assez rapide, et bien souvent une personne ayant 5 années d’expérience dans le domaine peut être qualifiée d’experte (à la différence d’autres thèmes plus complexes à appréhender). Il est par contre plus difficile de trouver des personnes « multi-casquettes », ayant l’expérience de différentes solutions de supervision.

C’est un des aspects qui valorise des sociétés comme Somone (non liée à un éditeur et multi casquettes), car elles disposent de nombreuses ressources dédiées à la Supervision, et qu’elles sont capables de mettre en face d’un besoin LA ressource qui maîtrisera le produit, à la différence de grands groupes dont ce n’est pas la spécialité.

Architecte

L’architecte supervision est une personne en général assez expérimentée, qui a déjà installé la solution chez plusieurs clients au préalable, afin d’avoir la connaissance des bonnes pratiques concernant cette solution. Elle est capable de déterminer quel espace est nécessaire (disque, mémoire, …) et quel OS est le plus approprié à la solution, afin de répondre aux contraintes posées (résilience, etc). Elle a déjà travaillé en exploitation, et donc connaît l’écosystème habituel de la supervision (CMDB, gestion d’incidents, etc.) et est capable de penser la solution de façon à tenir compte de ces contraintes. Elle est aussi souple, et capable de prendre en compte dans sa démarche les contraintes internes : type de VM autorisées, fréquence de sauvegarde, méthode… Bien souvent elle a joué un rôle d’expert système ou expert stockage avant de prendre le rôle d’expert supervision.

Un profil architecte est assez éloigné du récurrent, il fonctionne plus comme une personne travaillant en mode projet. Il se tient au courant des évolutions des solutions et prévoie les mises à jours à effectuer ainsi que leur impact. Dans la liste des rôles précités, il intervient en général :

  • Sur le design de l’infrastructure de supervision
  • Sur le maintien en conditions opérationnelles de la plateforme de supervision
  • Sur les évolutions de la plateforme

Expert supervision

L’expert supervision est une personne ayant plusieurs années d’expérience sur la solution (ainsi que, bien souvent, sur d’autres solutions du marché), préférant travailler sur le « run » que sur l’architecture. C’est en général le référent chez le client pour toute question portant sur la solution ou ses usages. C’est une personne qui s’implique beaucoup dans la solution, et connaît ses forces et ses faiblesses. Il peut ainsi très facilement détecter un fonctionnement anormal, ou orienter les gens sur les bons usages à mettre en œuvre pour tirer le meilleur parti de la solution. Il joue beaucoup le rôle de conseil, et est moteur dès qu’une évolution est à prévoir.

Il intervient sur les périmètres suivants :

  • Le design de l’infrastructure (il maîtrise bien les impacts des choix)
  • La définition de la supervision
  • La mise en œuvre de la supervision (et le processus)
  • Le maintien en condition opérationnelle de la supervision
  • Le conseil à la mise en supervision
  • L’apport d’éléments à la gestion de problèmes
  • Le reporting autour de la supervision
  • Les évolutions de la supervision

Il tient réellement le rôle de clé de voute de l’équipe, et de référent central. C’est lui qui assure la cohérence technique de la démarche, et le bon fonctionnement de l’ensemble.

Pilote de projet

Le pilote de projet est un rôle « passerelle » dans une équipe de supervision. Il sert de relai avec toutes les entités, grâce à son talent oratoire, et sa capacité à formaliser les échanges et les besoins. C’est un chef de projet : il sait s’appuyer sur les ressources pour obtenir les informations nécessaires, et a suffisamment d’expérience pour calibrer en termes de temps et de complexité les actions à mener. Ce rôle convient bien à des profils ayant démontré des compétences « humaines » et « organisationnelles ». C’est un rôle qui présente beaucoup de valeur ajoutée, car il garantit au client une maîtrise de la réalisation de ses demandes, et un suivi de qualité.

Son périmètre d’action concerne :

  • Le design de l’infrastructure de supervision (il est le garant du planning)
  • La définition de la supervision (il est le relais avec les autres entités, et le formalisateur)
  • La mise en œuvre de la supervision (C’est lui qui définit les temps de réalisation de chaque action et qui formalise le processus)
  • Le maintien en condition opérationnelle de la supervision (il est l’interlocuteur privilégié en cas d’incident sur les temps de remise en service)
  • L’apport d’éléments à la gestion de problèmes (il formalise la méthodologie et les standards)
  • Le reporting autour de la supervision (c’est lui qui porte les rapports dans les comités et analyse les retours)
  • Les évolutions de la supervision (il réalise le planning de prise en compte des améliorations)

C’est le profil le plus dans l’exploitation, il est en relation avec son responsable et les différentes entités, pour lesquelles il joue le rôle d’interlocuteur privilégié.

Consultant

Le consultant est le bras armé de l’équipe supervision. C’est une personne qui au travers de son action journalière accroit son expérience sur le produit, qui est émergente (une formation préalable, quelques installations de produits…). Il est en charge de toutes les actions à mener : application de procédures, mise en place de nouvelles supervisions, fourniture de rapports, …

C’est une ressource qui monte en compétence petit à petit en gérant les problèmes rencontrés, et qui est beaucoup sollicitée dans le day-to-day. Son périmètre d’intervention est le suivant :

  • La mise en œuvre de la supervision (application quotidienne)
  • Le maintien en condition opérationnelle de la supervision (réalisation des actions)
  • L’apport d’éléments à la gestion de problèmes (fourniture des éléments).
  • Le reporting autour de la supervision (génération des rapports)

 

Types d’organisation existantes

Il n’y a pas un seul modèle d’organisation. Les modèles sont bien souvent influencés soit par un historique, soit par l’organisation globale de la société. Par exemple si l’organisation sépare tout ce qui est « projet » de ce qui est « run », alors il y a des chances que cette ligne de démarcation soit reportée jusque dans votre équipe supervision. Voici donc différents types d’organisation, ainsi que l’explicitation de plusieurs points « forts » et points « faibles ». A vous de réfléchir ensuite dans quelle situation vous vous trouvez aujourd’hui, et de voir si une évolution de l’organisation, quand elle est possible, ne pourrait pas être bénéfique, selon vos objectifs.

 

Organisation Centralisée

L’organisation centralisée et celle que j’ai eu le plus souvent l’occasion de voir. Dans cette organisation, tous les rôles et toutes les solutions de supervision sont réunis au sein d’une même équipe. Le gros point fort de cette organisation est la synergie qui s’en dégage. Les choix de solutions sont fait dans un esprit d’homogénéité du résultat final, et les opérations menées le sont en symbiose, à savoir que l’équipe « build », l’architecte avant tout, fonctionne bien en phase avec l’équipe « run », chargée du récurrent. Le problème que j’ai pu observer dans cette organisation portait sur la capacité de celle-ci à être en phase avec les règles définies au niveau de l’entreprise. L’organisation des DSI définit bien souvent des règles d’architecture très strictes, et le fait de positionner l’architecte supervision en dehors de l’entité des architectes impose de rajouter un architecte « autorisé » au projet, et complique l’organisation en termes d’évolution.

Par contre un énorme avantage de tout centraliser se trouve dans la gestion des clients. Comme le guichet est unique, pour chaque besoin de supervision, il y a une prise en compte centralisée et donc une seule réponse apportée au client, qui couvre son besoin. Cette organisation, pour peu que l’équipe supervision soit située au bon niveau de management, peut permettre de définir des standards à forte valeur ajoutée pour l’entreprise.

Organisation Répartie

Les organisations réparties sont de plusieurs sortes. Je peux citer les organisations segmentées, où l’on sépare la partie « build » de la partie « run », comme cité ci-dessus, mais aussi les organisations où l’on sépare la partie supervision de base, incluant les couches infrastructures, de la partie supervision applicative qui inclus tout ce qui est robots, simulations utilisateurs, ou recopie de l’expérience utilisateur réelle (avec des outils venant se placer en recopie des trames circulant au sein des équipements réseau). Cette séparation diminue de facto le poids de l’équipe supervision, qui ne devient alors :

  • Que le reflet de l’infrastructure (bref un rôle exécutif)
  • Que le porteur de l’état de l’application (sans pouvoir savoir quelle en est la cause).

Ce dernier type d’organisation relègue presque toujours l’équipe supervision à un rôle d’exécutant subalterne, coupant toute possibilité de valeur ajoutée. Les choix reviennent alors soit au responsable de l’exploitation, qui alloue des crédits selon sa vision, soit aux intermédiaires clients, qui n’ont malheureusement bien souvent pas la visibilité sur la potentialité réelle de la supervision pour la valoriser convenablement.

La majeure partie des DSI n’accordent pas beaucoup d’importance à la supervision, la reléguant à un outil comme toutes les solutions d’expertise infrastructure. Comme je l’ai déjà dit, c’est un tort, car les clients sont aujourd’hui en attente d’informations sur l’état de leurs applications qui vont plus loin que « ça marche » « ça ne marche pas », et pourraient valoriser la mise en visibilité du travail de la DSI. L’ère de la confiance aveugle est dépassée, maintenant les métiers, ceux qui détiennent l’argent, veulent un contrôle sur cette boîte noire qu’est le SI; la supervision représente cette fenêtre.

Donc, pour en revenir à mon échange, une organisation où l’on sépare les différents métiers de la supervision n’a aucune chance de sortir de ce schéma « d’éxécutant », et c’est dommageable.

Je peux tourner le problème autrement : que se passe-t-il quand on sépare la responsabilité d’une application entre différentes entités ? Il y a dilution des responsabilités, donc impossibilité de prise réelle de position qui pourrait changer les choses, et en général, cela fonctionne mal. Il ne peut y avoir qu’une tête au dessus d’une application, et de la même manière, il ne peut y en avoir qu’une au dessus de la supervision. Autant que cette personne maîtrise le sujet, et puisse être moteur de l’ouverture du SI vers le client.

Organisation distribuée

L’organisation distribuée a été une surprise pour moi, la première fois qu’il m’a été donné de la rencontrer. Pour expliquer la chose : il s’agit d’une organisation où chaque entité est responsable de la supervision de son périmètre. Bien souvent, l’ingénierie et le choix des solutions est centralisée, mais par contre, la mise en supervision, le suivi au quotidien, et la gestion de chaque périmètre est confié à l’équipe applicative. Chaque personne est donc formée à l’usage de la solution de supervision, et fait le nécessaire pour déployer sur son périmètre.

Et ma surprise est venue du fait que cette organisation existe dans plusieurs sociétés, même de très grands comptes, et cela fonctionne ! Les gens sont responsabilisés, et porteurs de leur application, donc il est dans leur intérêt que la supervision soit efficace. C’est en fait l’équipe architecture qui tient les clés de l’infrastructure et décide des solutions à mettre entre les mains des équipes.

Petit bémol à cette organisation : elle demande que tous les intervenants soient formés à la solution de supervision. Donc si l’on fait appel à un extérieur, la facture peut vite monter (il ne faut pas des responsables applicatifs, mais des responsables applicatifs formés à la supervision, ce qui est plus dur à trouver). De plus, cette organisation ne peut pas tenir si on a un fort turn-over. Le retour a une organisation centralisée est souvent difficile : les gens vivent mal la perte de responsabilité, et dans ce cas, elle est réelle.

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 *