Articles

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

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.