Uptime : Mesure universelle ?
Il est admis que la mesure de base qui compte en supervision est le Uptime (temps de disponibilité d’un service et Nagios est prévu pour ce genre de réponse. Mais est-il intéressant, voir utile de rapporter à votre direction informatique sur ce type d’indicateur ? La réponse est clairement non.
Bien sûr, vos décideurs et autre managers sont intéressés de façon indirecte par l’uptime de votre infrastructure réseau. Mais ce qui compte le plus pour eux est la disponibilité de ces services aux personnes qui conduisent le business. Si la gestion des services nous a bien appris quelque chose, c’est bien que tout est service. Les informations techniques sont importantes, mais seulement pour le personnel technique.
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
