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)