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.