L’organisation de la supervision [partie 1]

Cet article s’adresse avant tout aux responsables supervision des DSI ayant un parc, des enjeux, des contraintes suffisamment importants pour justifier de l’existence d’une « équipe » supervision en tant que telle, c’est-à-dire composée de plus d’une ressource qui travaille en dilettante sur le sujet.

Comme dans les sports collectifs, l’optimisation de cette équipe devient alors un atout pour la DSI, car d’elle dépendra :

  • Votre capacité à maintenir votre supervision dans le temps
  • Votre capacité à gérer efficacement de nouvelles demandes
  • Votre capacité à intégrer de nouveaux équipements à votre parc
  • L’image de maîtrise du SI qui pourra être perçue par votre client (donc l’image de la qualité du travail fourni par votre DSI, soit dit en passant).

Vous avez dû vous en rendre compte, ces cinq dernières années, beaucoup de choses ont changé dans la supervision :

  • les produits open-source ont commencé à remplacer les solutions propriétaires
  • la gestion fine des budgets est devenue essentielle, notamment la maîtrise des dépenses
  • les DSI ne sont plus aussi « autonomes » qu’elles l’étaient autrefois, leur fonctionnement étant inspecté de près par les clients ou les intervenants métier, qui eux portent beaucoup d’importance à savoir ce pourquoi ils payent et à avoir le plus de visibilité possible sur leurs applications.

L’exploitation, et la supervision, plus particulièrement, ont donc muté; et il faut une organisation forte pour pouvoir y faire face, pour pouvoir garantir une qualité de service qui repose avant tout sur :

  • des sociétés de service dont les marges vont décroissant[1], et qui ne peuvent plus se permettre de faire de la sur-qualité,
  • des solutions que les éditeurs essaient de positionner à tout prix (et qui dans ce cadre ont bien souvent signé des accords avec les sociétés de services précitées afin de pousser leurs solutions)

Nous verrons dans ce chapitre quelle est l’importance que peut avoir la supervision, quels sont les rôles dévolus à l’équipe supervision, quels sont les profils existants, les types d’organisations existantes, ainsi que les liens entre l’équipe supervision et son écosystème, afin de viser une proposition de valeur.

L’importance de l’équipe supervision

Quand je suis devenu manager de crise d’un grand groupe énergétique, je me suis rendu compte qu’en tant qu’ancien responsable de l’outillage d’exploitation, et plus particulièrement de la supervision/hypervision, j’étais l’une des personnes sans doute les mieux placées pour tenir ce rôle[2]. L’équipe supervision, si l’organisation est rationnelle, est vraiment au cœur de l’exploitation, et elle est amenée à interagir avec toutes les entités.

Si les experts supervision ne peuvent pas maîtriser toutes les disciplines, comme dit précédemment, leur rôle central leur permet d’acquérir des compétences suffisantes pour comprendre le fonctionnement de ces disciplines, que ce soit lors de mises en œuvre de supervision, ou alors en phase de résolution d’un incident d’exploitation.

Mais d’expérience, pour être intervenu dans de nombreuses DSI, la supervision n’est pas forcément considérée à sa juste valeur.

La preuve la plus pertinente concerne son positionnement. Si elle est rattachée à une entité d’expertise, qui elle même peut être rattachée à une entité qui est transverse à l’exploitation des applications, la supervision ne peut se positionner qu’en tant qu’ « exécutante » d’un schéma beaucoup plus large, et se positionne donc très loin des problématiques des responsables applicatifs ou des clients.

Et pourtant… La politique actuelle voulant que les personnes des équipes métiers, qui tiennent les cordons de la bourse, aient une visibilité sur l’exploitation de leurs applications, qu’ils soient rassurés et impliqués dans la démarche, les DSI gagneraient beaucoup à mieux positionner la supervision. Son rôle devrait normalement aller bien plus loin que le rôle qui est bien souvent dévolu aujourd’hui.

D’ailleurs, le titre de « supervision » est lui-même obsolète. On ne demande plus aux équipes de faire de la supervision, mais de faire de l’APM[3] au sens large, c’est à dire de garantir la performance applicative en positionnant des outils permettant de mesurer cette performance d’une part, mais aussi de garantir son maintien dans le temps, au travers de solutions de supervision bien paramétrées et d’une organisation interne qui accompagne les points de mesure mis en place, ce toujours dans l’idée de réactivité en cas d’incident :

  • limiter les indisponibilités
  • être capable de communiquer sur les incidents de manière précise
  • prendre des engagements sur les temps de remise en service

Je n’insisterais pas sur ce point, mais j’ai eu l’occasion de voir des entités où la gestion des performances était mise en avant, et il n’en est ressorti que du positif dans les relations avec le métier, qui est content d’avoir face à lui des intervenants qui ont une vue transverse, et qui sont en capacité de lui donner des indications de coûts pour une qualité de gestion de la performance souhaitée (car on ne déploie pas tous les outils de supervision, même au sein d’une DSI, pour toutes les applications, les outils retenus dépendant bien souvent des contraintes client et de son budget).

Certains outils sont très chers, parce qu’ils rendent un service à forte valeur ajoutée. Il m’est arrivé de devoir déployer un outil d’introspection pour une application critique du SI. Cet outil permettait autant de superviser en temps réel tous les composants JAVA et leur fonctionnement, et en même temps pouvait être utilisée pour débugger le code, trouver les bouts de codes cycliques…

Un tel outil coûtant plusieurs centaines de milliers d’euros pour une seule application, on imagine mal sa généralisation, et pourtant il répond à un besoin bien réel !

Je conclurais donc ainsi : l’équipe « supervision » doit d’une manière ou une autre disposer d’une passerelle vers les clients. Car le service qu’elle est en mesure de fournir répond aux questions que se posent les clients, bien plus que tous les jargons d’experts techniques qui leurs sont desservis aujourd’hui. De mes nombreuses expériences, je tire des retours similaires : les clients sont plus mécontents du fait d’être complètement écartés, lors de pannes concernant leurs applications, du flux d’informations concernant leur remise en service que de l’indisponibilité en elle-même. L’idée comme quoi le client confie les clés et ne souhaite pas voir ce qui se passe est au mieux dépassée, au pire dangereuse. La transparence permet de bâtir une relation saine et une communication claire. Il est beaucoup plus simple d’expliquer à un client qui est capable aujourd’hui de sentir les faiblesses de son système là où il doit investir, que de lui préconiser des choses sans lui donner de visibilité sur le fond du problème. Un lien avec l’équipe supervision et la mise en œuvre des outils adéquats, avec son accord, peut vraiment faire avancer les choses.

 

[1] Beaucoup d’entreprises fusionnent leurs contrats d’infogérance, et maintiennent une pression forte sur les TJM qui est difficile à tenir pour les fournisseurs.

[2] J’ai d’ailleurs publié une note en 2010 sur le manager de crise, présentant les compétences attendues pour le poste.

[3] Application Performance Management, supervision et gestion de la performance et de la disponibilité applicative (http://en.wikipedia.org/wiki/Application_performance_management)

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 *