Articles

livre blanc

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.

livre blanc

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

livre blanc

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)

news

News du mois de Mai

 

Sorties

Informations

Lectures

TeeM Monitoring Lifecycle Management, et son module d’industrialisation

TeeM Monitoring Lifecycle Management permet entre autre l’industrialisation de la configuration de la supervision et l’insertion en masse d’équipements ou objets de supervision.

Avec TeeM MLM (Module d’industrialisation), les exploitants de la supervision évitent le travail manuel de première configuration de la supervision,notamment par le biais de l’outil d’inventaire “GLPI”. TeeM MLM (Module d’industrialisation) permet d’importer en masse les équipements et applications de l’outil d’inventaire vers la solution de supervision.

TeeM MLM (Module d’industrialisation) aide aussi au maintien en condition opérationnelle et mise-à-jour de la solution de supervision. En effet, grâce à un système de gestion des changements, les exploitants de la supervision peuvent recharger la configuration pratiquement en temps réel.

Le projet TeeM MLM (module d’industrialisation) a démarré en Mai 2010 quand des scripts d’industrialisation ont été développés pour le compte d’un client en utilisant une première API de Centreon CLAPI. Équivalent à une version alpha, d’énormes efforts ont été consenti pour le debuggage en collaboration avec Merethis. Ces scripts ont donné naissance à l’actuel TeeM MLM (Module d’industrialisation).

Avec ces scripts, nous passions d’un fichier CSV à de la configuration Nagios. Suite a cela, nous avons voulu utiliser ces scripts avec comme source de données l’inventaire du client via GLPI, pour créer les hôtes dans un premier temps, puis leur assigner des services templates en utilisant les applications connues dans GLPI. Dans les spécifications, nous devions avoir une étape intermédiaire que le client validait. Cela se traduisait par un fichier Excel.

Toutes ces actions étaient regroupées dans un Job Talend en deux parties. La première partie consiste à générer un fichier Excel à partir d’une liste de serveurs (Input : liste de serveur en CSV, Talend : CSV => SQL, Talend : vues SQL => plusieurs CSV, Perl : CSVs => Excel). Puis, s’en suivait une étape de validation client faite à partir du fichier Excel généré. Enfin la seconde partie du Talend était lancée (Input : Excel, Perl : Excel => CSVs, Perl : CSVs => Clapi).

Quelques temps après, suite à une volonté de rationaliser et de simplifier «l’industrialisation», toute la mécanique a été reprise dans un unique script, utilisant comme brique les classes python développées chez le client pour accéder à CLAPI. Suite à cela, les options de TeeM MLM (Module d’industrialisation) ont été simplifiées pour faciliter son utilisation.

A. BUFFET

Events

Meetup #6

Le prochain meetup Paris Monitoring sera le
mercredi 18 mai 2016
et a pour thème
Collecte, stockage et manipulation de métriques/séries temporelles

L’événement se déroulera dans les locaux de Logmatic.io
130 Rue de Lourmel, 75015, Paris

Agenda :
– à partir 18h50 accueil des participants
– 19h10 mot d’accueil + mot de bienvenue des sponsors
– 19h15 à 20h40, talks 50 mins + 30 mins
– 20h40 pizzas et discussions jusqu’à la fin

Talks :

Not Your Father’s Monitoring
Mathias Herberts – @herberts, Co-Founder and Chief Technology Officer @CityzenData, former Big Table Site Reliability Engineer

« Mathias reviendra sur l’évolution des pratiques de monitoring et sur la tendance actuelle à l’instrumentation et à la collecte de séries temporelles. Il présentera également la plate-forme Open Source Warp 10 qui permet de collecter, stocker et analyser des métriques pour faire passer vos propres pratiques de monitoring en hyperespace ! »

Gnocchi: metric as a service
Par Julien Danjou – @juldanjou, Principal Software Engineer at Red Hat

« La présentation sera autour du projet Gnocchi : pourquoi, comment il fonctionne et ce qu’il offre. Gnocchi est un projet de base de données de time series que j’ai démarré dans le cadre d’OpenStack. »

L’inscription se fait sur la page de l’événement

Meetup #6 Collecte, stockage et manipulation de métriques/séries temporelles

Wednesday, May 18, 2016, 7:00 PM

Logmatic.io
130 Rue de Lourmel 75015, Paris, FR

11 Membres Attending

Notre prochain meetup Paris Monitoring aura lieu le mercredi 18 mai à 19h dans les locaux de Logmatic.io !(ce meetup n’est pas encore annoncé)Cet événement est sponsorisé par Logmatic.io et Ikoula : Logmatic.io nous accueillera dans ses locaux et Ikoula nous permettra de nous restaurer.Agenda :- à partir 18h50 accueil des participants – 19h10…

Check out this Meetup →