La représentation traditionnelle d’un SI en supervision

Aujourd’hui, tous les systèmes de supervision représentent un système de supervision comme un ensemble de serveurs sur lesquels tournent des services. C’est une représentation technique des choses qui associe la notion de santé d’une système d’informations …. Beaucoup de clients aujourd’hui souhaitent vérifier le matériel, les processus,

Cette représentation traditionnelle d’un système d’informations, au moins dans le domaine de la supervision, semble de plus en plus poussée vers l’obsolescence dû à quelques évolutions majeures intervenues dans nos SI depuis 5 ans.

Quelques problèmes

• La redondance et la haute disponibilité qui rendent la représentation traditionnelle plus lourde à modéliser.
• La virtualisation massive des systèmes d’informations des entreprises, que ce soit avec Xen, VMware, KVM… amenant une distinction supplémentaire entre serveurs physiques et serveurs virtuels dépendant d’un serveur physique.
• Le Cloud qui est en train de faire exploser la notion même de matériel puisque vous ne savez plus à un instant temps « T » quels sont les composants de votre infrastructure qui sont sollicités.

Du coup, les systèmes de supervision actuels souffrent de plus en plus pour représenter la complexité des interactions entre serveurs actifs, non actifs, physiques, virtuels… Les conséquences en exploitation sont nombreuses avec des difficultés croissantes à pouvoir décider ce qui ressort d’un problème, d’un incident, ce qui devrait être notifié, escaladé. Certains nous promettent le nirvana (encore en portant la notion de corrélation à un niveau jamais atteint et difficilement exploitable. Ils nous fournissent des moteurs de corrélation de plus en plus complexe à paramétrer et configurer. Impasse ?

La représentation comportementale de votre SI

Les auteurs de Cucumber qui est à la base du plugin préfère ouvrir une autre voie en partant du principe qu’un système doit se comporter d’une certaine façon pour rendre le service attendu.

Quelques bénéfices

• Vous n’avez plus à modifier les paramètres de chaque sonde à chaque modification de votre infra. Le comportement observé devant en toute logique resté le même.
• Vous êtes directement orienté vers l’impact métier du problème.
• Vous n’êtes pas alerté au moindre problème, seulement pour ceux impactant l’activité ou le service rendu.
• Vous prenez en compte l’expérience utilisateur. C’est bien là le principal non ?

Les outils pour le faire

La trousse à outils pour arriver à ce type de supervision est train de se mettre en place au niveau du monde de la supervision Open Source et nous vous avons déjà présenté ici Watir et Cucumber, pierres angulaires de ce type de supervision à venir… ou non

Alors à vous de me dire si ces idées sont intéressantes et/ou se contentent de suivre une nouvelle mode comme nous en connaissons régulièrement. À vos commentaires

Mais il est aussi probable que l’absence d’évolutions réelles en 2009 sur le Nagios Core profite également à quelques concurrents qui ne sont pas restés sans rien faire de leurs côtés. Le plus « dangereux » pour Nagios étant Zabbix, qui a vraiment progressé en 2009 et offre aujourd’hui une alternative crédible à Nagios. Zabbix embarque désormais au moins autant de fonctionnalités que Nagios si ce n’est plus. Sans oublier Zenoss. C’est aujourd’hui certainement l’un des projets les mieux structurés au niveau communauté, business…. Le logiciel progresse et le fait qu’il soit en python et basé sur Zope pourrait tenter du monde. Python toujours avec Shinken qui pourrait être l’outsider de cette année. Ce jeune projet a sur le papier tout pour séduire, notamment sur le plan des performances et une architecture qui permet de l’adapter à de très grands environnements.

La balle est aujourd’hui clairement dans le camp de Ethan, qui se doit de réagir et d’envoyer quelques signes positifs à la communauté qu’il a un peu déserté ces derniers temps pour cause de démarrage de Nagios XI. Il doit réussir la triple équation évolution du code, développement du business et bien-être de la communauté pour garder le leadership sur la supervision Open Source. Quoiqu’il en soit, ce sera une belle année pour la supervision Open Source.

Le directeur du système d’information se fout un peu de savoir si le switch était disponible à 99,99% du temps. Comme il se fout de savoir si la base de données est optimisée et fonctionne efficacement. Ce qu’il lui importe est de savoir comment ces composant affectent le business.

Les bons systèmes de rapports incluent tous les incidents qui perturbe de n’importe quelle façon l’utilisateur des systèmes. Ils n’incluent pas les interruptions de service comme par exemple, un lien secondaire qui est mort. Bien sûr, le service informatique doit travailler pour résoudre ce genre d’incidents, mais vu qu’il n’affecte pas l’utilisateur final, c’est inutile de le consigner.

C’est une épée à double tranchant. Vous devez ne pas rapporter sur les choses qui n’affectent que les services IT; mais vous devez au contraire rapporter tout ce affecte l’utilisateur final. Beaucoup de services IT ne le font pas ainsi, et ils masquent soit ce qui pourrait être une nouvelle opportunité d’améliorer les services IT pour les utilisateurs; soit ce qui pourrait devenir une rébellion utilisateur.

Disons que votre console Nagios ou WhatsUp vous dit que votre serveur Exchange est up, up, up. Il est joignable par ICMP, et les transactions courtes sur chacun des services importants sont fonctionnelles. Pourtant, il y un problème qui est que les personnes connectées ne peuvent plus rien faire après 60 secondes de connexion. Interruption de service, non ? Interruption de service, OUI. Les dirigeants n’ont que faire que ce soit un problème lié au poste client, à l’application ou à l’infrastructure.

Il y a 15 ans, j’ai écrit de façon enthousiaste sur les systèmes de supervision. Et je continue à croire que les services IT en ont besoin. La gestion des infrastructures est une partie importante de la gestion des services. Mais dans un contexte orienté service, la supervision de la disponibilité n’est pas suffisante.

Votre centre de services doit être le point central de rapport des interruptions de services. Rapporter un uptime de « 99,99% » ne raconte pas toute l’histoire. Et franchement, vu que le centre de services est souvent conduit par une entité tierce à votre organisation, c’est une tierce partie qui peut aider pour savoir toute l’histoire vu du point de vue utilisateur final.

Comment commencer ? La plupart des centres de services vous permettent de classer les tickets comme incidents ou demandes. Pour augmenter la plus value du classement des incidents, vous pourriez les classer par niveau d’impact, (par exemple pas de service, interruption importante ou faible, intermittente) et le périmètre d’impact (par exemple entreprise, département, groupe de travail). Collecter des données multi-dimensionnelles vous permettra d’avoir une vue complète. De plus, la plupart des centres de services vous permettent de préciser le temps écoulé jusqu’à la clôture du ticket.

Ces dimensions vous permettront de présenter un rapport d’interruption de service qui veut dire quelque chose plutôt qu’un mumbo-jumbo d’uptime d’infrastructure qui ne dit pas toute la vérité.

Article repris et traduit depuis :
Infrastructure Uptime: A Useless Report par Jonathan Feldman