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)

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 *