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

0 réponses

Répondre

Vous souhaitez vous joindre à la discussion ?
N'hésitez pas !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *