livre blanc

L’organisation de la supervision [partie 4]

Cette partie clos l’organisation de la supervision en abordant le point des interactions entre équipes. N’hésitez pas à commenter.

Lien entre équipe supervision et les autres entités

La supervision est garante de la disponibilité de l’ensemble du SI, du coup elle est contrainte de travailler avec tout ce qui fait le SI. Et donc, d’intervenir avec les différentes entités, comme dit précédemment. Mais quels sont les liens qui existent entre ces entités et la supervision ? Comment se traduisent-ils ? Ci-dessous une représentation de ce qui peut/doit être fait, avec les apports de la liaison et les problèmes que peuvent poser l’absence de ces liens.

Les experts

Les experts, se sont toutes les ressources associées à du « niveau 3 » ou du « niveau 4 » qui interviennent en support sur les solutions qui composent le SI. Pour rappel, ce niveau de compétence est le dernier « rempart » avant de devoir faire appel au support de l’éditeur.

On trouve dans cette catégorie des experts réseau, des experts système, des experts stockage, ou des experts middleware, par exemple. Le travail de ces experts peut être multiple : ils peuvent intervenir dans la définition des standards du SI, tout comme ils peuvent être sollicités lors de la conception de l’architecture d’une application, ou intervenir en support sur un incident de production. Mais le rôle qui nous intéresse le plus ici est celui de porteur des préconisations de supervision sur leur périmètre. Etant donné qu’ils sont les personnes qui maîtrisent le plus le sujet et qui seront contactés lors d’un incident, il est normal qu’ils soient mis à contribution dans la définition des standards de supervision, qu’ils puissent aussi participer à la rédaction de consignes pertinentes (pour décharger autant que possible le niveau 2 d’exploitation), et qu’ils puissent déterminer quels éléments supplémentaires doivent être configurés afin de fournir l’information nécessaire et suffisante lors d’un incident pour accélérer sa résolution.

Lorsque l’équipe supervision travaille sans le concours de l’équipe d’expert, le résultat est forcément négatif. Car les experts n’ont pas au final les éléments suffisant pour leur permettre de résoudre un incident, ou alors l’alarming est soit peu précis, dérangeant pour des alertes sur lesquelles on ne peut rien faire, soit trop limité, ne permettant pas de détecter les incidents. Cette liaison est réellement indispensable.

Le pilotage

Le pilotage est composé des ressources qui, dans une DSI, sont en charge des actions de niveau 0 et niveau 1 sur l’exploitation. En général elles sont les premières utilisatrices des outils de supervision et des consignes, ainsi que des outils de gestion des incidents. Leur travail peut se réduire à un Lundi vendredi 9-17h, ou monter jusqu’à réaliser les 3*8 en 24/7 . Ce sont les personnes qui vont être amenées à « tester » les règles de supervision. Pour elles, toute règle mal renseignée est un casse-tête car elles ne savent pas comment traiter un incident et elles sont incapables de savoir quel impact pourra avoir l’incident. Il ne faut pas oublier que la connaissance dont elles disposent sur les applications et la criticité du SI n’est souvent que de l’ordre d’un vernis superficiel, et elles sont donc dépendante de la qualité de ce qui leur est fourni pour effectuer leur travail dans les meilleures conditions.

Le lien avec l’équipe supervision est évident. Les équipes du pilotage sont dans une boucle d’amélioration constante avec les équipes supervision quant à la qualité de ce qui est mis en place, et la qualité des consignes. C’est au prix d’échanges réguliers que la réactivité des équipes atteindra son maximum et que les périodes d’indisponibilités seront minimisées.

Il m’est arrivé de voir des sociétés ou les pilotes étaient considérés comme des exécutants, non inclus dans le dispositif. Non seulement ils étaient incapable de savoir quelle alarme était prioritaire sur une autre, mais en plus se retrouvaient avec des consignes bancales qu’ils exécutaient malgré tout car « on ne leur demandait pas leur avis ». Je vous laisse envisager l’impact pour une DSI.

Les conduites applicatives

Les conduites applicatives sont en charge de l’administration, du suivi et des mises à jour des applications à leur périmètre. Les équipes de conduite applicative sont contactées quand il y a un incident sur une application, ou quand il y a des modifications à apporter. Elles sont aussi dérangées quand il y a une astreinte. Ce sont donc ces équipes qui sont le plus sensibles à une bonne supervision de l’application, et doivent être impliquées dans la mise en place des supervisions.

Il existe beaucoup de sociétés ou le lien n’est pas établi car la supervision se limite à des indicateurs système : CPU, mémoire, disque… Pas d’indicateurs applicatifs, donc pas de suivi des logs ou de processus propriétaires, d’où pas de réelle nécessité de lien avec l’équipe supervision, car elle applique des templates standard sur tous les serveurs.

Le seul lien qui reste indispensable concerne les mises en supervision. Lorsqu’une application atterri en exploitation, à quel moment l’équipe supervision est mise dans la boucle, pour mettre en place les binaires et métriques nécessaires à superviser ; il existe plusieurs manière de faire :

  • Soit l’équipe applicative transfère les accès à l’équipe supervision lorsqu’elle récupère l’application
  • Soit l’équipe des administrateurs système a chargé les templates en « standard » lors de l’atterrissage de toute nouvelle machine
  • Soit l’équipe projet prend contact avec l’équipe supervision en avance de phase
  • Soit l’équipe des administrateurs système travaille avec l’équipe supervision qui déploie sur un nouveau serveur
  • Soit l’architecte est en relation avec l’équipe supervision.

Le lien avec l’équipe supervision peut « être » ou ne pas « être », selon l’organisation globale de la DSI.

Les équipes projet

Les équipes projet sont bien souvent en amont de l’exploitation. Elles travaillent à la conception et l’atterrissage des nouvelles applications en production. Ces équipes peuvent être des entités internes ou externes quand le développement est confié à une société extérieure. Elles interviennent lors de la phase de « BUILD », à la différence des équipes supervision qui interviennent lors de la phase de « RUN ».

Il n’existe pas de science exacte sur le lien entre les équipes projet et la supervision, mais pour ma part je milite depuis des années pour que, dans chaque entreprise, les équipes projet prennent en compte dès la conception de l’application les contraintes de supervision à mettre en œuvre.

Il n’est pas compliqué de réaliser une supervision basique : logs, process, filesystem… Mais réaliser une supervision « applicative », cela demande qu’elle ait été pensé dès la phase de conception de l’application, et que des messages claires, ainsi que des outils avancés aient été intégrés à l’application. On peut ensuite, bien sûr, avec des outils perfectionnés, notamment sur des architectures N-Tiers, s’insérer au cœur de l’application pour bénéficier de remontées. Seulement cela demande d’investir des centaines de milliers d’euros, un chiffre sans comparaison avec le faible coût qu’aurait entraîné la mise en œuvre de routines de supervision interne dans l’application.

Pour moi, donc, ce lien est indispensable. L’équipe supervision doit fournir des « prérequis » spécifiant ce qui doit être supervisé et ce qui ne doit pas l’être, et indiquant les bonnes pratiques (formalisme des logs, emplacement des fichiers, etc). Sans ce lien, la supervision restera toujours incomplète et limitée à l’infrastructure.

Les équipes « process ITIL »

La supervision est un des éléments clés du SI, et doit donc être en lien étroit avec les équipes qui adressent les process ITIL de l’entreprise.

Je vais aborder ce point en précisant les interfaces entre les différents process :

  • Gestion des demandes

Il m’est arrivé de voir des entreprises dans lesquelles les demandes de mise en supervision ont été intégrées à la gestion des demandes. Ce choix permet d’éviter de générer un nouveau processus, et si l’outil est bien configuré, cela permet de borner le suivi et de tracer les actions. Ca n’est pas forcément indispensable, mais le lien peut être intéressant.

  • Gestion des changements

Le lien avec la gestion des changements est important pour tout ce qui concerne les « blackout » de la supervision. Lorsqu’une équipe intervient sur un serveur ou une application, il est important de mettre en place les désactivations de la supervision qui conviennent afin de ne pas noyer la supervision sous de fausses alarmes. Inclure dans le process de la gestion des changements les informations d’éléments devant être retirés de la supervision et la durée de l’intervention, ainsi que les éventuels tests à effectuer lors du retour à la normale présente un intérêt avéré afin d’optimiser le processus. Ce lien est malheureusement rare, avec tous les impacts spécifiés ci-dessus.

  • Gestion des incidents

Le lien avec l’équipe en charge de la gestion des incidents est celui qui a mon sens est le plus important à maîtriser.

J’ai vu des entreprises qui avaient mis en place un déversement automatique des alarmes critiques dans l’outil de gestion des incidents. Elles traitaient ensuite directement les incidents dans l’outil de gestion des incidents, faisant fi de la console de supervision. C’est à mon sens, une mauvaise idée. D’une part, les outils de supervision ont dans leurs fonctionnalités basiques des routines de « retour à la normale » qui n’existent pas dans la gestion des incidents. Un incident qui se résoudrait de lui-même serait résolu dans la supervision alors que le ticket d’incident serait encore ouvert. Mais il y a plus. Si on tient compte de l’évolution des outils de supervision, nous avons aujourd’hui dans les hyperviseurs de la corrélation, de l’analyse de la cause source d’un incident, des analyses de tendance qui permettent d’anticiper le problème à venir… Tous ces éléments ne rentrent pas dans la vue qu’offre une solution de ticketing, alors qu’ils ont vocation à accélérer et simplifier la résolution d’un problème. Il est donc important pour moi que la supervision reste réalisée au sein de l’outil de supervision.

Autre point, on s’appuie souvent sur la solution de ticketing pour calculer la période d’indisponibilité de l’application. Ça n’a pas de sens. Le ticket est bien souvent ouvert automatiquement, mais sa clôture est manuelle, et donc forcément peu représentative de l’instant réel de la clôture de l’incident, alors que la supervision est capable de mesurer cet instant avec un écart de moins de 5 minutes.

Par contre, le lien entre la supervision et la solution de gestion d’incidents est important, car il permet de tracer l’action des différentes équipes lors de la résolution de l’incident. Donc, en résumé, à chacun son outil, le suivi réel de l’incident et de ses impacts ne peut être réalisé que dans l’outil de supervision, mais le suivi de son traitement doit lui être réalisé dans l’outil de ticketing.

  • Gestion des problèmes

Comme précisé précédemment, l’équipe supervision est très liée à la gestion des problèmes : elle peut au travers de ses outils, et du reporting de ses outils, prévenir des incidents « récurrents » à traiter dans la gestion des problèmes, et fournir les courbes et les informations d’état au moment du problème afin de cerner l’intégralité des éléments nécessaire à la résolution du problème. Ce lien est malheureusement rare dans les entreprises, tout simplement parce que la gestion des problèmes est ce que l’on implémente en dernier dans une entité, car elle nécessite une gestion des incidents mature. Mais il est évident que l’équipe supervision doit être le premier interlocuteur de l’équipe de gestion des problèmes, avant même les experts, qui ont besoin de matière pour investiguer. Avant de se lancer dans une analyse profonde d’un incident, il est bon de se questionner sur la connaissance réelle que l’on a du problème et de ses impacts.

  • Gestion de la configuration

La gestion de configuration contient des informations vitales pour le SI, notamment toutes les informations d’inventaire serveur et réseau. Reposant bien souvent sur une CMDB, c’est la seule référence viable concernant le parc installé. Il est donc essentiel que les équipes supervision travaillent avec les équipes en charge de la gestion de configuration pour s’assurer d’une bonne couverture du parc. De plus, avec une CMDB, on est capable d’avoir un niveau d’information plus important : le type d’OS installé sur le serveur/ la machine virtuelle, les middleware mis en place…

Avec une bonne automatisation, il est alors possible de mettre en place des templates standard OS/Middleware garantissant une supervision minimale quelque soit le serveur une fois son intégration au parc. Somone a d’ailleurs déjà réalisé ce type d’action chez plusieurs clients.

Si la société ne dispose pas d’un référentiel interne, bien sûr, ce lien présente beaucoup moins d’intérêt. Mais la supervision peut alors servir elle même de base pour alimenter un inventaire, couplée à des outils propriétaires ou open-source (comme GLPI par exemple).

Le Reporting

Il est difficile de déterminer le positionnement du reporting dans une DSI. De tous les clients que j’ai pu visiter, aucun ne disposait d’une configuration similaire, c’est pourquoi ce paragraphe est délicat à traiter, et pourrait se perdre dans une étude de cas, et de l’organisation du reporting possible pour les DSI. Pour présenter ce qui est le plus courant :

  • Il n’existe pas d’équipe reporting dans la DSI, et chaque équipe réalise son reporting de son côté
  • Il existe une équipe reporting en charge d’un périmètre limité dans la DSI
  • Il existe une équipe reporting qui centralise toutes les demandes pour la DSI.

Quelle que soit votre organisation, il est évident que l’équipe supervision est le meilleur fournisseur de données pour une DSI. La supervision permet autant d’avoir une vue sur l’état des lieux du parc que de connaître les incidents qui s’y sont produit et leur fréquence. Idem, elle peut alimenter une météo du matin, autant qu’un état des lieux temps réel de l’état du SI. Ce lien est donc de première importance pour qui souhaite communiquer sur sa disponibilité.

Le pilotage des contrats d’infogérance

Quel peut être le lien entre les équipes en charge du pilotage des contrats d’infogérance et l’équipe supervision me direz-vous ?

Il en existe un simple, dans un cas particulier. Si vous disposez d’un infogérant qui a la charge d’une partie de votre parc, le fait de vous reposer sur les indicateurs remontés par la supervision vous permet de suivre l’activité de votre infogérant. La supervision permet en effet de calculer simplement la disponibilité de l’infrastructure, et ce point permet d’instancier le suivi contractuel de la performance de l’infogérant sur un indicateur fiable et pertinent.

Les interfaces client

Votre DSI dispose peut être de chargés de relation client, en contact direct avec les besoins du métier et ses difficultés. Réaliser un lien avec l’équipe de supervision permet au chargé de relation de mieux maîtriser ce qui peut être proposé, et à quel coût. Cela permet donc aussi de gérer plus finement la relation client. Avoir un retour régulier sur les faiblesses de la supervision de telle ou telle application peut aussi permettre de valoriser l’expertise de la DSI et montrer qu’elle peut être force de proposition pour le métier.

Que faire si je n’entre pas dans une de ces cases, ou si je me rends compte que certains points ne sont pas pris en compte dans mon organisation actuelle ?

Je vais commencer par m’excuser pour le cas où, bien malgré moi, je n’aurais pas dans mon inventaire atteint une exhaustivité suffisante pour couvrir tout ce qu’aujourd’hui votre organisation peut compter, où la manière dont elle est organisée. Cet article a pour vocation d’évoluer au fil des remarques, aussi je vous prierais de ne pas hésiter à m’envoyer un message.

Quand j’ai commencé à rédiger cet article, je m’étais mis comme contrainte : si je pouvais retourner en arrière, à l’époque où je dirigeais une équipe supervision, quels auraient été les éléments que j’aurais été heureux d’avoir ? Qu’est ce qui m’aurait permis de me positionner par rapport à d’autres sociétés, et me fournir des idées nouvelles pour étendre mon activité ? Alors j’ai décidé de faire un tour de ce qui a, d’après mon expérience, du sens. Ce qui permet d’aller plus loin. Ce qui peut remettre en cause une organisation qui semble figée dans le marbre, et surtout, ce qui peut servir de référence. J’aurais aimé à l’époque disposer d’un article comme celui-ci, que je puisse sortir à mon responsable en lui disant : « cet aspect, on ne l’a pas mis au périmètre. Mais ça a du sens, et s’il l’écrit, c’est que ça existe dans d’autres sociétés. On aurait tord du coup à pas essayer d’aller plus loin ». Bref, j’espère que ce document pourra vous servir à la façon d’une notice de montage pour une « bonne » supervision.

Que faire, donc, si jamais votre organisation actuelle ne prend pas en compte certains des points évoqués ? Ma première réponse serait d’évoquer en interne quel est l’impact du manque de ce point, et quel serait l’impact de sa mise en œuvre. Ensuite, si vous décidez de faire évoluer les choses, soit vous disposez en interne de ressources compétentes pour réaliser la mise en œuvre, soit ce n’est pas le cas, et vous pouvez faire appel à un partenaire qui a l’habitude de le réaliser pour ses clients.

Nous avons organisé chez Somone des sessions d’Audit, chez plusieurs clients, pour les aider à se positionner par rapport à l’état de l’art. Ces sessions ont permis de mettre en avant des faiblesses, mais aussi de valoriser le travail des équipes. N’hésitez pas à entamer ce genre de démarche, car pour un coût réduit, cela peut vous permettre d’améliorer le positionnement de votre équipe supervision au sein de la DSI.

livre blanc

Superviser un serveur OpenStack

Cet article est le premier d’une série orientée technique afin de montrer ce qu’il est possible de faire avec les outils de la communauté.

Remarque: Somone proposant une solution basée sur Centreon de la société Merethis, nous allons donc utiliser Centreon (CES [1]) pour cet article, cependant, il est applicable à d’autres solutions comme Zabbix.

 

Qu’est ce que OpenStack ?

Selon la définition Wikipedia :

OpenStack est un ensemble de logiciels open source permettant de déployer des infrastructures de cloud computing (Infrastructure as a service). La technologie possède une architecture modulaire composée de plusieurs projets corrélés (Nova, Swift, Glance…) qui permettent de contrôler les différentes ressources des machines virtuelles tels que la puissance de calcul, le stockage ou encore le réseau inhérent au datacenter sollicité.

De nombreuses entreprises ont rejoint la fondation OpenStack. Parmi celles-ci on retrouve :Canonical,Red Hat,SUSE Linux,eNovance,AT&T,Cisco,Dell,HP,IBM,Yahoo!,Oracle,Orange,Cloudwatt,EMC,VMware,Intel.

Architecture OpenStack :

Ci-dessous un schéma résumant l’architecture OpenStack et de ses principaux composants (description extraite de Wikipédia):

  • Compute : Nova (Hyperviseur)
  • Object Storage : Swift (stockage d’objet)
  • Image Service : Glance (service d’image)
  • Dashboard : Horizon (interface Web de paramétrage et gestion)
  • Identity : Keystone (gestion des utilisateurs, rôles et accès)
  • Network : Neutron (auparavant nommé Quantum) (gestion des réseaux à la demande)
  • Storage : Cinder (service de disques persistants pour les instances)

Remarque: ces composants ne sont (pour la plupart) que des couches d’abstraction à d’autres composants plus concrets comme un hyperviseur KVM ou Xen pour Compute, un stockage LVM ou Ceph pour Cinder ou Swift et un pont réseau Linux classique pour Neutron.

D’autres composants annexes comme une queue de messages RabbitMQ et une base de données MySQL sont requis.

Supervision OpenStack 1/3 (Composants de base):

La base d’OpenStack repose sur un certain nombre de processus et d’Endpoints HTTP :

– Exemple de supervision d’un processus via l’agent NRPE (ici nova-api):

[centreon-engine@ces3 ~]# /usr/lib/nagios/plugins/check_nrpe -H 10.0.3.1 -c check_procs -a « 1:10 » « 1:100 » nova-api
PROCS WARNING: 13 processes with args ‘nova-api’ | procs=13;1:10;1:100;0;

 

– Exemple de supervision d’un endpoint HTTP (ici l’API Keystone pour l’authentification):

[centreon-engine@ces3 ~]# /usr/lib/nagios/plugins/check_http -H 10.0.3.1 -p 5000 -u « /v2.0 » -e 200 -s stable
HTTP OK: Status line output matched « 200 » – 783 bytes in 0.006 second response time |time=0.005710s;;;0.000000 size=783B;;;0

 

Ce qui donnera une liste de modèles de services comparable à celle-ci (à adapter suivant votre convention de nommage):

  • OpenStack-Dashboard-Web-Server
  • OpenStack-Dashboard-NoVNC_Proxy
  • OpenStack-Block_Storage-Scheduler
  • OpenStack-Block_Storage-API
  • OpenStack-Block_Storage-Volume
  • OpenStack-Image_Service-API
  • OpenStack-Image_Service-Registry
  • OpenStack-Compute_Service-Compute
  • OpenStack-Compute_Service-Libvirtd
  • OpenStack-Identity-Service-Keystone
  • OpenStack-Network_Service-Network
  • OpenStack-Nova-API
  • OpenStack-Nova-Conductor
  • OpenStack-Nova-Scheduler
  • OpenStack-Nova-ConsoleAuth
  • OpenStack-Nova-EC2_Endpoint
  • OpenStack-Nova-Keystone_Endpoint

Les sous-composants mentionnés dans le chapitre précédent (kvm, lvm, etc.) ont généralement des indicateurs de supervision recommandés à mettre en place (non traité dans cet article).

Une supervision système correctement paramétrée est également nécessaire afin de s’assurer du bon fonctionnement de la plate-forme (CPU, Mémoire, SWAP, Espaces disques locaux et points de montage, I/O disques et réseaux, etc.).

Supervision OpenStack 2/3 (Logs et middlewares):

En complément des indicateurs mis en place ci-dessus, certains fichiers logs sont à surveiller:

  • Services OpenStack (Les API d’OpenStack étant au format HTTP, il faut rechercher les patterns qui ne contiennent pas “ status: 200 “)
2014-09-10 15:29:28.516 26742 INFO nova.api.ec2 [-] 0.605s 10.0.47.2 GET /services/Cloud None:None 400 [check_http/v1.4.16 (nagios-plugins 1.4.16)] text/plain text/xml
2014-09-10 15:29:28.517 26742 INFO nova.ec2.wsgi.server [-] 10.0.47.2 « GET /services/Cloud HTTP/1.1 » status: 400 len: 332 time: 0.0017200

 

  • MySQL
  • RabbitMQ
  • Systèmes (cron, etc.)

Remarque : la supervision de Log peut se faire de différentes manières via différents outils et pourrait faire l’objet d’un article à part entière. Ici, il est recommandé de procéder avec vos propres outils et à défaut, ceux-ci seront parfaits[2].

Au delà des logs, il est indispensable de mettre en place une métrologie (puis une supervision dans un second temps) sur MySQL[3]:

  • MySQL_Server-Qcache_Hitrate
  • MySQL_Server-Queries
  • MySQL_Server-Connection_Time
  • MySQL_Server-Slow_Queries
  • MySQL_Server-Threads_Connected
  • MySQL_Server-Innodb_Bufferpool_Hitrate
  • MySQL_Server-Databases_Size
  • MySQL_Server-MyISAM_Keycache_Hitrate
  • MySQL_Server-Uptime
  • MySQL_Server-Open_Files

ainsi que sur RabbitMQ[4]:

  • RabbitMQ-Aliveness
  • RabbitMQ-Connections
  • RabbitMQ-Objects
  • RabbitMQ-Overview
  • RabbitMQ-Partition
  • RabbitMQ-Server
  • RabbitMQ-Watermark

L’ensemble de ces indicateurs va  permettre de voir comment est utilisée la plate-forme ainsi que de placer / ajuster les seuils en fonction de l’utilisation. Ci-dessous, un exemple d’implémentation :

Bac à évènements part 1

Bac à évènements part 2

Supervision OpenStack 3/3 (Simulation d’une demande) :

Les indicateurs mis en place dans les chapitres précédents vont permettre d’identifier la cause du problème mais pas de détecter une panne du service car un indicateur peut passer CRITIQUE sans pour autant affecter le service.

Il faut donc simuler une demande d’utilisateur, soit en ligne de commande via la commande “nova”, soit via le portail Horizon.

La communication entre les différents composants se faisant par HTTP, il est en théorie possible de suivre cette demande de test de bout en bout puis réaliser une connexion SSH vers cette instance et enfin de la détruire.

Déroulement :

  • Création de l’instance via nova-manage
  • Attribution de l’adresse IP flottante (étape optionnelle)
  • Test de connexion en SSH
  • Restitution de l’adresse IP flottante (étape optionnelle)
  • Destruction de l’instance

Note: Ce scénario est à automatiser pour envoyer de manière passive le retour des différentes étapes.

Conclusion :

Superviser un serveur OpenStack n’est pas compliqué en soi, la documentation est très complète[5], de plus, la solution se base sur des composants connus et maîtrisés de longue date.

Il faut cependant ne surtout pas perdre de vue que ce sont les applications et leur disponibilité dans notre “cloud” qui sont prioritaires, l’infrastructure sous-jacente l’est moins.

Cet article a pour but de mettre en place une solution de monitoring simple afin de pouvoir déterminer rapidement la cause racine d’une dégradation de performance ou même d’un arrêt complet d’une ou plusieurs applications métier par exemple.

À l’exception de la dernière partie, les indicateurs utilisés peuvent remonter un certain nombre de faux positifs, il vous appartient maintenant d’améliorer ces indicateurs en les affinant ou en les remplaçant.

 

Notes :

[1] Centreon Entreprise Server (Centreon packagé par Merethis)

[2] TeeM Application Monitoring, Check_logfiles, Logstash, etc.

[3] https://forge.centreon.com/projects/centreon-plugins

[4] https://github.com/jamesc/nagios-plugins-rabbitmq

[5] http://docs.openstack.org/openstack-ops/content/logging_monitoring.html

 

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)

livre blanc

Les spécifications de la supervision [partie 2]

Cet article clos la partie spécifications de la supervision en vous présentant notre vision d’une mise en place de spécifications pertinentes. Encore une fois, n’hésitez pas à commenter.

Comment mettre en place des spécifications pertinentes ?

Ne perdez jamais de vue qu’il n’existe pas de spécifications universelles, mais des spécifications adaptées à votre contexte, et à votre organisation. Le but premier est que les supervisions qui découleront de ces spécifications satisfassent vos experts et leur permettent d’assurer un MTTR[1] optimal.

Travailler en Synergie

La définition des spécifications ne doit pas être le seul fait d’équipes de supervision ou d’un prestataire extérieur. La raison en est simple : les équipes qui seront impactées par les supervisions mises en place seront les équipes d’experts et de pilotes d’applications. Il faut donc s’assurer que ces intervenants seront en mesure d’intervenir pour chacune des alarmes définies. Si tel n’est pas le cas, l’alarme génèrera un bruit de fond (le fameux « pourquoi je me fais toujours déranger par cette alarme alors que j’ai déjà dit qu’on peut rien y faire ? ») qui pourra être réellement dommageable en période d’astreinte, nuire à la motivation et à l’efficacité du traitement. De plus ces alarmes perdureront dans la supervision, sans correction apportée.

Viser une couverture des alertes pertinentes uniquement

On peut vouloir être sûr à 100% que pour chaque incident d’exploitation, la supervision disposera de l’alerte qui va bien. On peut. Maintenant, dans les faits, faire de la « sur-qualité » a un impact énorme sur la supervision. La plupart des clients ne disposent pas de vue service, ni d’un hyperviseur. Ce qui signifie que la corrélation entre alertes, ce qui permet de n’afficher que les alertes pertinentes, n’est pas fonctionnelle. Donc à vouloir couvrir toutes les alertes, vous risquez de noyer l’information importante dans un flot de remontées inutiles, surtout dans le bac à événements. La manière la plus pertinente de travailler et de vous concentrer sur les alertes où vous maîtrisez l’impact (où tout du moins l’expert maîtrise l’impact).

J’ai vu des clients ou absolument tout était remonté parce que l’expert voulait avoir toutes les informations possibles sur les incidents. En fait, ils se servaient de l’outil de supervision comme outil d’expertise. Je préfère le dire de suite : ça n’a aucun sens. La supervision a pour objectif, je le rappelle, d’être efficace, et de réduire le temps d’intervention sur incident. Cela sous entend de réduire au maximum les informations qui s’y trouvent afin que les pilotes puissent traiter les incidents le plus rapidement possible et transférer leur résolution aux experts. Les experts ont leurs propres outils, mais ceux-ci ne doivent pas être le bac à évènements de la supervision. Avoir 99 alertes en permanence, pour une équipe de pilotage, ça n’est pas gérable. Appliquez le principe de Pareto[2], vous ne vous en porterez que mieux, et vos exploitants aussi.

Bâtir des templates

Cela peut paraître une évidence, et pourtant je rencontre encore des clients chez qui ce n’est pas fait. Quelle que soit la taille du parc informatique, afin d’optimiser la supervision, il est important de bâtir des templates. Cela aura plusieurs effets directs :

  • La typologie d’alarme sera limitée et donc la compréhension plus simple
  • Les seuils seront connus et donc maîtrisés
  • Vous aurez la garantie d’une supervision « minimum » pour tout produit ajouté à votre SI (par application du template)
  • Cela vous permettra de bâtir un catalogue de ce que vous pouvez superviser
  • L’équipe supervision aura beaucoup moins de mal à maintenir la plateforme.

Bref, le seul point négatif que l’on peut voir dans le fait de bâtir des templates, c’est de se dire que l’on ne peut pas toujours tout faire rentrer dans les templates, et qu’il faut les faire évoluer dans le temps.

Limiter les exceptions

Cette remarque vient à la suite de la précédente. Une exception, un seuil spécifique, c’est un peu de perte dans la maîtrise du SI. Les exceptions doivent être des supervisions qui le justifient réellement. En plus de cela, si vous mettez en place des templates et décidez (pour une raison bien justifiée) de ne pas les appliquer sur un serveur, deux ans plus tard, vous aurez toutes les difficultés du monde à vous rappeler pourquoi ce serveur était une exception. Et si un incident se déclenche du fait de la non application du template, on vous le reprochera. Les templates sont réfléchis en général, et sont là pour garantir la qualité de la supervision. Les exceptions se doivent de répondre à un besoin REELLEMENT unique, car si elles touchent plusieurs serveurs, il faut peut être se poser la question de l’utilité d’ajouter un nouveau template qui couvrira ce périmètre.

Bien répartir les responsabilités

Chez 90% des clients que j’ai croisé, il y a un fonctionnement non naturel qui est appliqué, que je connais bien – pour l’avoir vécu durant des années – et qui est source de tensions inutiles entre équipe de supervision et reste de l’exploitation. Il s’agit de la responsabilité de la définition des seuils de supervision pour une application. Pourtant les plaintes sont toujours les mêmes : « je t’avais dit de surveiller ce serveur, pourquoi cet incident s’est produit sans qu’on le détecte ? ».

Vous avez déjà entendu ce message ? Je parie que oui. Et on a beau jeu d’expliquer alors que les experts supervision ne PEUVENT pas être des experts réseaux/systèmes/applicatifs/stockage et j’en passe…  et qu’il est évident que les experts supervision n’ont pas la science infuse. En fait, le problème vient de l’aggrégation de deux faits spécifiés plus haut : le premier est qu’il faut absolument que des spécifications, des templates et un catalogue aient été réalisés et mis à disposition des équipes applicatives, après avoir été conjointement bâti avec les experts, et le second est que seules les équipes qui pilotent les applications savent ce qu’elles veulent voir supervisé sur ces applications, savent ce qui est essentiel. Alors si elles ne le précisent pas, les équipes supervision ne peuvent le deviner. Vous l’avez compris, la définition des supervisions à mettre en œuvre doit être de la responsabilité des équipes applicatives. A condition qu’on leur ait fourni les outils nécessaires, bien entendu.

Ne pas laisser d’alarmes orphelines

Depuis que j’ai commencé à faire de la supervision, en 2001, je me suis appuyé sur cette expression : « une alarme, une consigne ». Les intervenants du pilotage opérationnel sont bien souvent des personnes peu qualifiées, qui n’ont pas une grande expérience de l’exploitation mais à qui on demande de faire les 3*8. Ils ne peuvent donc savoir que telle alarme est liée au réseau et qu’il suffit de relancer le processus oracle quand il tombe pour cette application. Il faut que tout leur soit écrit, même si la consigne se limite à « transférer l’alarme au niveau 2 réseau ».

Définir des consignes de niveau 1 autant que possible pour décharger le support niveau 2

Beaucoup d’organisation limitent les actions du pilotage au niveau 0, c’est à dire que leur travail consiste à faire boîte aux lettres. « Une alarme ? Je contacte untel ». A mon avis, c’est une énorme erreur, et à plus d’un titre. Je peux commencer à citer le fait que de faire relais téléphonique, ça n’est pas motivant. Quand on ne sait pas ce que l’on fait ni l’impact que cela a, on le fait bien souvent mal, sans en saisir la portée. Dans une société pour laquelle j’ai travaillé plusieurs années, les personnes du pilotage demandaient en plus des consignes pour chaque alerte de disposer d’informations sur l’application, et sur son importance. Elles souhaitaient être impliquées dans le travail de la DSI, et je pense que c’est essentiel. En plus, toute action de niveau 1 que l’on a décrite et documentée permet soit de préparer une automatisation de la résolution de l’incident (gestion des problèmes) ou tout du moins d’éviter que cette action soit traitée par les experts du niveau 2, qui limitent alors leurs interventions à résoudre des incidents nécessitant réellement de la technicité. La charge de travail est allégée, d’une part, et la résolution de l’incident est accélérée, car les personnes du pilotage sont en première ligne sur tout incident, d’autre part.

Maintenir un référentiel

Le catalogue permet de définir ce qui peut être fait. Le référentiel permet de connaître les instanciations qui ont été faites du catalogue, et de maîtriser ce qui est supervisé et ce qui ne l’est pas au sein du SI. Le fait de ne pas disposer d’un référentiel rend très dépendant de l’installation qui a pu être faite par le passé (et donc du manque de maîtrise), car sans maîtrise de ce qui a été réalisé par le passé, il est impensable d’en faire évoluer le contenu.

Le référentiel doit être lié dynamiquement à la solution de supervision, afin de pouvoir être « sûr » de ce qui a été mis en place. Ce n’est pas chose simple, car bien souvent les équipes sont amenées à faire évoluer la supervision « dans l’urgence », sans que le référentiel soit mis à jour, avec le risque derrière de perdre de l’information au futur, et de ne plus se rappeler ce qui a été fait et à quelle date.

Dans la même veine, il peut être pertinent de maintenir les consignes dans un référentiel qui permettra un accès facile à celles-ci, notamment dans le cadre d’une exploitation courante, mais aussi dans le cadre de leur mise à jour par les équipes applicatives. Le mieux étant de s’affranchir du papier ou des consignes situées dans « des documents d’exploitation » pour viser l’efficacité, et l’usage d’un mediawiki relié en direct à la solution de supervision (les solutions TeeM Monitoring Work Orders et Merethis Centreon Knowledge Base sont bâties dans cet esprit).


[1] Mean Time To Repair, temps nécessaire à la remise en service d’une application

[2] http://fr.wikipedia.org/wiki/Principe_de_Pareto, ou encore loi des 80/20, phénomème empirique observé spécifiant que environ 80 % des effets sont le produit de 20 % des causes

livre blanc

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)

livre blanc

Une analyse des coûts de la supervision [partie 3]

Cet article clos notre analyse des coûts de la supervision sur un exemple… instructif.

Exemple

Une petite démonstration valant plus qu’un long discours, voici un petit exemple qui je l’espère vous permettra de vous mettre les idées plus au clair. Vous pouvez vous même remplacer les hypothèses prises par les informations réelles de votre entreprise, afin de vous faire un ordre d’idée de ce fameux coût réel de la supervision.

Hypothèse

Nous allons prendre le cas de la DSI d’un grand compte. Cette DSI héberge 2000 serveurs, pour la plupart virtualisés, pour environ 100 applications.

Cette DSI a fait le choix d’une solution de supervision propriétaire, et a mis en place de la supervision et de l’hypervision, ce qui représente un coût important, mais les attentes de ses clients lui demandent tout un tas de garanties qui font qu’elle a préféré s’appuyer sur un éditeur pour avoir une garantie de support.

Elle a aussi fait le choix de mettre en place des scénarios de supervision applicative sur 10 de ses applications critiques, en passant aussi par la solution d’un éditeur.

Les équipes de supervision de cette DSI sont constituées de 5 personnes à temps plein, deux assurant le récurrent, un travaillant sur la partie robots, un responsable de l’équipe qui tient aussi le rôle de pilote de l’amélioration continue et un profil d’architecte qui gère aussi l’hyperviseur.

Les experts quant à eux sont composés de 4 experts réseaux (Deux sites et une DMZ), de 5 experts système (pour supporter les souches unix et windows), et de 4 experts middleware (dont 2 pour oracle, et 2 pour les solutions Web). La DSI n’a pas fait le choix de SAP.

Les applications sont réparties par groupe représentant des clients. 4 équipes gèrent la totalité, et on compte en tout 8 pilotes d’applications.

Le pilotage fait du 3*8 et est composé de 7 personnes, qui ont en charge la gestion des incidents (outils de ticketing) et le suivi de la supervision.

Voilà qui définit le contexte de notre client imaginaire.

Passons maintenant au détail de l’analyse financière.

Coûts de licences

L’entreprise a pris une solution de supervision propriétaire

Coût d’acquisition 100 K€, 20K€ de maintenance par an

Elle a aussi investi dans les solutions d’hypervision de cet éditeur

Coût d’acquisition 250 K€, 50K€ de maintenance par an

Elle a fait l’acquisition de robots pour superviser ses applications critiques

Couts d’acquisition 100K€, maintenance 20 K€ /an

Coûts de l’équipe de supervision

L’équipe est présente toute l’année. Les profils sont trois profils consultants, un profil consultant sénior, un profil chef de projet.

Le coût d’un consultant standard est évalué à 100 K€ par an. Celui d’un architecte et d’un chef de projet à 150 K€.

Coût par an des ressources supervision : 600K€.

Coût des équipes d’exploitation

Sur les 7 ressources affectées au pilotage, 5 d’entre elles ont la supervision comme outil de travail quotidien.

Une ressource de pilotage est estimée à 80 K€ par an.

Coût par an des ressources d’exploitation : 400K€

Coût des infrastructures de supervision

L’infrastructure qui permet de réaliser la supervision est composée de 5 VM hébergeant du Linux ; l’hypervision rajoute une VM supplémentaire. Les robots quand a eux occupent 5 VM différentes.

L’infrastructure globale de supervision occupe donc 11 VMs[1].

Le coût d’hébergement estimé d’une VM est de 1500€/mois[2].

Coût par an de l’infrastructure : 200 K€

Coût de la charge transverse

Les diverses demandes de mise en supervision, les suivis de nouvelles corrections et les évolutions de scénarios suite à des mises à jour entraînent une charge équivalente à un ETP dans les équipes applicatives.

La définition des alarmes, les dérangements suite à alarmes non maîtrisées, le maintien d’un catalogue et les évolutions suite aux évolutions des solutions des éditeurs entraînent un équivalent de charge d’un ETP côté experts système et côté experts middleware.

Soit un coût de 110K€+180K€*2= 470 K€

coût par an de la charge transverse : 470 K€

Bilan

Un simple graphe devrait donc permettre de comprendre ou se situent les coûts réels de la supervision :

cout annee 1

Coût total année 1 : 2,1 M€

Sur la première année, les licences représentent 21% du coût, et les charges humaines 57%.

Dès la seconde année, l’écart s’aggrave :

cout annee 2

Coût total année 2 : 1,7 M€

Le volet humain représente 68% de la charge, alors que celui des licences ne représente plus que 5%.

Un dernier mot pour finir cette section ;

Il est amusant de voir que dans beaucoup d’organisations, les seuls coûts de licences et de ressources supervision seront pris en compte quand on tentera d’évaluer le coût de la supervision.

On aura donc un coût évalué en année 1 de 1,05 M€ et un coût évalué ensuite de 0,69 M€, soit une estimation fausse à chaque fois qui prend en compte à chaque fois moins de la moitié  du coût réel.

Pensez-vous toujours que les licences, si elles sont un levier d’économies, sont réellement le cœur du problème ? Peut être que l’optimisation des ressources en améliorant la qualité de la supervision aura un impact bien supérieur…


[1] Cette infrastructure correspond à ce que j’ai pu voir, au fil des audits, chez plusieurs clients.

[2] J’ai conservé d’un ancien poste une matrice devis qui donnait ce chiffre, en ajoutant les coûts d’hébergement, d’exploitation, de licences et de renouvellement de l’infrastructure.

livre blanc

Une analyse des coûts de la supervision [partie 2]

Voici la seconde partie de notre article, qui présente cette fois le détail des coûts.

Quels gains pour quelle supervision ?

Nous allons aborder plus loin la question du coût réel de la supervision. Mais avant cela, pour poursuivre sur le point précédent, je pense qu’il est important de détailler plus avant les bonnes questions à se poser lorsque l’on décide de mettre en place une solution de supervision pour garantir l’application d’un client. Parce qu’à l’heure où tout le monde resserre les budgets, il serait malavisé de définir une solution « unique » pour toutes les applications. Cela permettrait sans doute de baisser le coût à l’application, mais cela aurait un impact évident sur le coût global.

Voici la méthodologie que je propose, qui repose sur plusieurs points.

La plateforme de supervision modulaire

Il existe différents outils, et tous ne s’appliquent pas à tous les besoins clients. Si la plateforme de supervision « standard » présente un intérêt à être mise en œuvre pour tous les clients, il n’en va pas de même pour tous les outils qui l’entourent.

Définissez donc votre supervision comme suit :

  • Une supervision standard pour toutes les applications (système, middleware, réseau…)
  • Une supervision applicative pour les applications qui demandent une investigation plus pointue,
  • Des robots réservés aux clients ou il y a soit un besoin « d’étalon », soit un besoin de réactivité, soit une demande express client
  • Des analyseurs de performance pour les applications critiques qui le nécessitent.

A quel besoin client répondre ?

Le client souhaitera par nature la meilleure des supervisions pour le coût le moins élevé possible. Il n’est un secret pour personne que lors des spécifications, pour un client tout est nécessaire, et lorsqu’on passe à la facture, en général on se rend compte que certains besoins ont été surévalués. Pour vous aider dans votre choix, voici une liste de questions à vous poser à chaque fois qu’une application doit être mise en supervision :

  • Quel est le coût réel d’une indisponibilité de l’application ?
  • A partir de combien de temps d’indisponibilité la solution mise en place sera-t-elle rentabilisée ?
  • Quelle est l’importance de l’application pour le client ?
  • L’application fait-elle partie d’une chaîne ayant un engagement de service restrictif ?
  • L’indisponibilité de l’application peut-elle être néfaste à l’image du client ?
  • Sur quel niveau d’engagement le client est prêt à investir pour cette application ?
  • Ce niveau d’engagement est-il justifié ? (surqualité / prise de risque)
  • Le client a-t-il besoin d’un « juge de paix » sur les temps de réactivité de son application ?
  • La stabilité de l’application justifie-t-elle de mettre en place des outils de mesure de la performance ?
  • La fréquence des mises en production et les surcoûts engendrés peuvent ils entraîner la mise en place d’outils de mesure de la performance ?
  • Que suis-je prêt à partager avec le client en retour de son investissement (consoles…)
  • Les outils dans lesquels le client me demande d’investir me permettent-ils de mesurer les SLA demandés et de garantir la disponibilité de l’application ?

Toutes ces questions devraient permettre de renseigner suffisamment une application pour choisir les outils de supervision adaptés au contexte, et éviter les dépenses inutiles.

Les différents coûts de la supervision

Il n’y a pas un coût de la supervision, mais des coûts de supervision. Je vais aborder ci-après un à un les postes de coûts de la supervision en vous les détaillant. On retrouve :

  • Les licences, le support
  • Les ressources des équipes supervision
  • Les ressources des équipes d’exploitation
  • Les infrastructures de supervision
  • La charge générées dans les autres équipes d’exploitation (experts, équipes applicatives,…)

Licences et support

Je suis presque sûr que quand on aborde avec vous le thème des coûts de la supervision, dès lors que vous avez des solutions propriétaires, ce qui vous vient en premier à l’esprit c’est le poste « licences ».

Les licences de supervision des éditeurs sont coûteuses, leur mode  de licencing change régulièrement, et les produits évoluant et se dirigeant vers la « fin de vie », vous vous retrouvez souvent contraints de racheter des licences qui incluent des fonctionnalités supplémentaires, dont vous pensez ne pas avoir le besoin, mais qui sont obligatoires si vous souhaitez continuer à bénéficier du support. Ce mode « captif » des clients a tendance à accroître cette image négative de la supervision, d’autant plus depuis que sur les couches dites « basses », les solutions libres offrent une alternative convaincante aux solutions propriétaires, pour un coût de licence moindre.

Un second point à analyser, et le fait que, même sans parler du libre, selon le service rendu, les coûts de licences sont vraiment différents. Certains outils atteignent des coûts de licences « démentiels », je veux parler des outils d’introspection ou d’analyse de trames réseau, qui peuvent atteindre jusqu’à des millions d’euros d’acquisition.

Mais, une fois de plus, il faut mettre le coût du produit en face du besoin. Si vous gagnez des centaines de millions d’euros sur une application, et qu’une indisponibilité peut entraîner une perte sévère, alors le coût somme toute élevé, sera à mettre en face d’une éventuelle indisponibilité, et du manque à gagner généré.

Équipes de supervision

Un second coût qui est mis en avant et bien souvent celui des équipes supervision. Les produits étant souvent complexes d’utilisation, on se retrouve rapidement à des équipes d’administration, d’architectes et de support avec des coûts par ressource de l’ordre de 100 K€ à l’année. Le fait est que les produits du marché sont livrés bruts de fonderie, et qu’il faut beaucoup de monde pour parvenir aujourd’hui à en réaliser un usage correct. Par exemple, lorsque vous prenez une solution du marché de supervision de base, vous avez à définir vous même quels paramètres superviser (ou ne pas superviser), toute la documentation qui va avec la supervision, toute l’organisation de la supervision, et pour peu que vous ayez un hyperviseur, il y a aussi le travail de corrélation des remontées à réaliser, qui lui est encore plus complexe ! Les solutions de supervisions ne sont que des outils, plus ou moins aboutis, et qui nécessitent donc beaucoup de travail pour s’adapter à votre organisation.

Je profite d’ailleurs de cette section pour présenter un autre fait avéré qui n’est malheureusement que rarement pris en compte dans les entreprises :

Le libre coûte beaucoup plus cher qu’on le pense.

Les solutions libres sont en général plus ouvertes, donc nécessitent plus de ressources pour les administrer, et surtout des ressources qui savent ce qu’elles veulent faire ! Le support n’est pas fourni par un éditeur, ce qui sous entend des investissements supérieurs pour corriger des problèmes, et le fait de dépendre d’une communauté, certes active, mais pas dédiée à résoudre VOTRE problème. Par conséquent, si on reprend mon échelle de 100 k€ la ressource, on se rend vite compte que le fait de partir sur du libre de manière non réfléchie peut s’avérer plus coûteux que de prendre des solutions propriétaires.

Les équipes d’exploitation

Le troisième coût représentatif est celui porté par les équipes d’exploitation. Ce coût est rarement associé au coût de supervision, et pourtant, à mon sens, il lui est directement lié :

  • Si vous avez plusieurs outils de supervision, cela vous donne à traiter plusieurs consoles et donc multiplier les ressources pour assurer  leur suivi
  • Si votre supervision n’est pas mature, cela entraîne plus d’alarmes et donc plus de ressources pour les traiter
  • Si votre supervision n’est pas industrialisée, vous avez beaucoup de gestes manuels à accomplir qui vont eux aussi nécessiter beaucoup de ressources pour les traiter.

Ainsi les coûts d’équipes d’exploitation sont directement liés à la maturité de la solution de supervision et aux investissements réalisés au préalable afin d’optimiser. Comme je le disais, vous devez entrer vos coûts d’équipes d’exploitation dans le calcul global du coût de votre supervision, tout du moins sur la partie sur laquelle ils sont amenés à intervenir.

Infrastructure

Les coûts d’infrastructures de supervision sont bien souvent négligés, et c’est un tort. L’infrastructure des outils de supervision est bien souvent complexe, s’appuyant sur des relais, stockant les informations dans des bases de données, ayant besoin de portails web…

Selon l’importance que l’on accorde à l’infrastructure, il peut aussi y avoir de la redondance, ainsi que des capacités de bascule entre sites. Si le SI est composé de plusieurs DMZ, c’est autant de serveurs passerelles qui devront être installés afin de relayer l’information de supervision sans porter atteinte aux contraintes de sécurité.

Toujours dans la liste des coûts, même si dernièrement les éditeurs ont commencé à prendre le tournant linux, historiquement, les plateformes étaient avant tout composées de plateformes propriétaires (SUN et IBM) qui revenaient très cher à l’achat et à la maintenance.

Impacts d’autres équipes

Dernier coût mais pas des moindres, celui de l’impact des autres équipes d’exploitation dans le coût de la supervision. La supervision n’est pas magique. Il ne suffit pas de dire « mettez moi en place la supervision » pour avoir un résultat de qualité qui satisfera autant les responsables des applications que les clients. Les équipes supervision ne sont pas dans le contexte du client, et ne peuvent pas de fait inventer les supervisions à mettre en œuvre. Elles peuvent aussi se baser sur des templates, mais il faut que ces templates aient été créés par des personnes maîtrisant le sujet.

Que se passe-t-il quand on laisse des personnes qui ne maîtrisent pas le domaine mettre en œuvre la supervision sans les accompagner ? Deux choses bien souvent :

  • Soit on a une plateforme de supervision qui est trop « light », et des clients qui se plaignent que les incidents se produisent et que personne ne les remarque.
  • Soit on a une plateforme de supervision noyée sous les incidents, dans laquelle les équipes reçoivent des messages « polluants » qu’elles ne savent pas traiter. La console reste alors en permanence avec une centaine d’incidents pas importants, ce qui empêche toute réactivité sur incident.

Comme on peut le voir, l’équilibre n’est pas simple à mettre en œuvre, et seul un engagement des différentes équipes concernées ou l’appui de sociétés externes ayant de la maturité sur le sujet (et quand je parle de maturité, je ne parle pas de personnes qui se limitent à vous vendre la formation de leurs équipes, mais de réelles sociétés vous apportant de la valeur ajoutée avec des installations pré-packagées par exemple) vous permettra d’avoir un résultat de qualité.

Les équipes autres impactées sont donc nombreuses. Selon l’organisation, on peut citer : les personnes en charge des applications, les experts système, les experts réseau, les experts middleware…

(à suivre …. exemple)

livre blanc

Une analyse des coûts de la supervision [Partie 1]

Au travers de ce retour, nous lançons notre section de retours « à forte valeur ajoutée » pour nos clients. N’hésitez pas à nous faire part de vos remarques, elles sont bienvenues.

Définition: la supervision informatique

La « supervision informatique » pouvant désigner bien des choses, je pense qu’il est judicieux de préciser ce que j’entends par « supervision informatique » avant d’aller plus loin. Dans le cadre de cet article, La supervision informatique est traitée au sens large, incluant les diverses couches pouvant être supervisées, les différents outils pouvant être utilisés, l’hypervision et le reporting. Le schéma ci-dessous précise mon propos :

supervision global

Vue de la supervision au sens large

Donc quand je vous parle de supervision informatique, en terme d’outillage et de couverture, je fais référence au périmètre précisé ci-dessus. Mais là encore, ça n’est pas tout. Parler de supervision informatique, c’est aussi parler de processus, d’organisation, de ressources, et de prise en compte du contexte.

 supervision_perimetre

Périmètre de la supervision

Mon propos portera donc sur la globalité de ce périmètre, et vous apportera un éclairage selon l’angle que je jugerais pertinent à sa compréhension.

Coût de la Supervision

La supervision, ça coûte cher!

Cette phrase, j’ai dû l’entendre au moins une fois chez chacun des clients pour qui la supervision avait de l’importance.

Je mets de côté les entreprises où la disponibilité des applications n’est pas au cœur de l’activité, parce que bien souvent dans celles-ci la supervision est réalisée sur un coin de bureau (avec aucune ressource dédiée), avec un Nagios paramétré pour assurer le service minimum (et qui répond aux attentes). Je parle ici des entreprises où la supervision est un enjeu, quelle qu’en soit la raison :

  • La société rend un service à des clients exigeants,
  • La société doit rendre des comptes sur sa disponibilité à un organisme tiers,
  • L’indisponibilité de l’outil informatique a un impact direct sur le chiffre d’affaire de la société,

La supervision dans le cadre défini ci-dessus est évidemment un enjeu d’importance, mais elle est bien souvent perçue comme très/trop coûteuse. Le fait est qu’il est difficile d’évaluer le ratio apports/coûts de la supervision. Le but de cet article est de lister les « coûts/apports » de la supervision afin de vous aider à en maîtriser les enjeux.

Apports de la supervision

La supervision n’est pas un organe critique de la chaîne applicative de l’entreprise.

L’indisponibilité de la supervision n’entraîne pas de facto l’indisponibilité des applications. Elle est par contre un élément majeur de l’exploitation. Si l’on prend la définition de wikipedia : « L’exploitation informatique est l’activité qui consiste à maintenir opérationnel de manière stable, sûre et sécurisée un outil informatique dans un environnement de développement, de qualification, de formation, ou de production, dans ses parties matérielles et logicielles. »

Or comment peut-on imaginer maintenir un outil informatique si l’on n’est pas en capacité de connaître son état ? C’est là le rôle essentiel de la supervision. Et ce rôle essentiel est perçu différemment selon les attentes que portent les applications supervisées ; si l’indisponibilité de votre application, comme pour le cas d’un site marchand par exemple, entraîne une perte financière directe, vous avez tout intérêt à être réactif dans la résolution d’un incident afin de minimiser la perte. Ce ne sera pas forcément la même chose pour une application qui est utilisée 1 mois par an et qui ne présente pas d’impact financier.

Peut-on alors considérer cette « économie » comme un « gain » ?

Il y a peu encore, un responsable d’exploitation me disait : « mon meilleur outil de détection d’incidents, c’est mon client. Il sera toujours plus réactif que les outils de supervision à détecter un problème, parce que lui est en 24/7 devant sa console et qu’il m’avertit directement du moindre dysfonctionnement. » J’avoue que sur le moment sa remarque m’avait choqué, sans que j’ai le temps de lui formuler une réponse correcte afin de lui prouver ses torts. Et pourtant, la réponse était évidente ! bien sûr, le client est le premier à pouvoir détecter un incident, mais ça n’est pas suffisant, car ce qui intéresse réellement ce n’est pas de détecter un problème, mais c’est d’être en mesure d’en connaître la cause rapidement, afin de limiter l’indisponibilité. Au vu de la complexité des applications d’aujourd’hui, bâties sur de nombreuses couches et reposant sur des progiciels qui se complexifient d’année en année, rien n’est moins simple.

C’est la qu’intervient la supervision, qui non seulement est capable d’alerter sur un incident, mais permet aussi d’aller directement au cœur du problème, de pouvoir mobiliser au plus vite les bons intervenants et de limiter ainsi les temps d’indisponibilité.

La supervision, parce qu’elle permet d’identifier un incident de manière claire et précise permet donc de facto de réaliser des économies conséquentes sur les temps d’indisponibilité des applications.

Ces économies sont à mettre en face des besoins, car c’est là bien souvent qu’il y a mélange des genres. Bien que ce ne soit que rarement le message porté par les éditeurs (qui préfèreraient évidemment que vous investissiez dans toute leur suite sur tout votre périmètre), il n’existe pas une seule supervision mais bien des usages de la supervision, et tout comme vous n’apportez pas le même niveau d’engagement pour une production que pour une intégration, il n’y a pas de raison que vous apportiez le même niveau de supervision pour toutes vos applications. La supervision doit être elle aussi adaptable au contexte, aux besoins, aux impératifs clients.

La supervision est un ensemble de briques qu’il est possible de choisir et de paramétrer selon ses besoins. L’homogénéisation des supervisions mise en place est une contrainte plus souvent apportée par l’organisation interne et le souci d’industrialisation que par les solutions fournies par les éditeurs.

Les outils de supervision peuvent d’ailleurs aller très loin. Lorsque vous souhaitez définir des SLA pour une application, aujourd’hui, vous pouvez avec justesse faire reposer ces SLA sur des outils de type « robots » (ip-label newtest, BMC TMART, sikuli, …) plutôt que sur la capacité du client à remonter les indisponibilités (en mettant de côté celles qu’il aurait pu ne pas voir), ce qui met en avant un autre rôle dans la maîtrise du SI apporté par la supervision :

Elle permet de garantir un terrain neutre d’analyse de la disponibilité des applications entre les clients et l’exploitation informatique (rôle de « tiers de confiance »).

Donc, pour conclure cette section, la supervision peut être vectrice de gains financiers si elle est bien réalisée, elle doit être adaptée au besoin, et elle permet d’assurer un pont « neutre » entre l’exploitation et les clients.

(suite: coût de la supervision)