99,9 % dans mes rêves

Tout d’abord, une conversion s’impose. Puisque l’année compte 8 760 heures (sauf les années bissextiles), un taux de 99 % signifie que le SI a été indisponible pendant 1 % du temps, soit 87 heures (vous me ferez grâce des virgules), ce qui représente tout de même plus de trois jours et demi. Avec 99,9 %, le nombre d’heures d’indisponibilité descend à 8 heures (soit moins d’une journée ouvrable si l’on inclut la pause de midi), à 50 minutes pour 99,99 % et à moins de 5 minutes d’arrêt par an pour 99,999 % (les fameux « cinq neuf »).

Ensuite, qu’entend-on exactement par « indisponible » ? Selon le point de vue de qui ? La DSI mesure le taux de disponibilité de l’infrastructure « à la sortie de la salle informatique », ce qui fait une belle jambe aux utilisateurs : si mon PC est planté, qu’importe que le prise RJ45 du datacenter fonctionne ! Bien entendu, il est compliqué de tenir compte des centaines ou des milliers de PC d’un parc, mais on comprend la complexité de la mesure. D’autant que dans un SI les éléments sont chaînés : le logiciel s’appuie sur l’infrastructure, elle-même composée de multiples éléments en ligne ou en cascade qui s’appuient à leur tour sur le réseau, etc.. Autant dire que la formule mathématique de calcul de la disponibilité de l’ensemble relève de la gageure.

Et indisponibilité de quoi ? Du réseau ? Des infrastructures système (serveurs, middlewares) ? Des progiciels métiers ? Pour information, il existe une métrique pour mesurer le taux de panne des composants unitaires tels que les disques durs ou les switchs : il s’agit du MTBF (Mean Time Between Failure), ou temps moyen entre deux pannes, donné par le constructeur. Mais aucune donnée factuelle et objective n’existe pour un composant complexe tel qu’une baie de disques ou une infrastructure de mutualisation. Même chose pour les progiciels métiers : rien sur le taux de disponibilité de la couche logicielle métier. Et pour cause : le bug est inhérent à l’informatique.

Pour finir, que mesure-t-on ? la durée maximale d’une panne (15 pannes plus courtes dans l’année sont donc jugées insignifiantes) ou le cumul des temps de panne (avec 479 pannes d’une minute, on reste alors dans les 99,9 %) ? Chacun sait que l’utilisateur est autant impacté par la durée d’une panne que par l’enchaînement des pannes. Seul un indicateur composite serait pertinent, mais il reste à imaginer et à construire.

Dernier exemple : si un DSI s’engage sur un taux de 99,9 %, la moindre panne de 8 heures absorbera tout son capital annuel. Et 8 heures passent vite, surtout la nuit ou le week-end, quand les équipes sont au mieux réduites à celles d’astreinte, que le DBA dort du sommeil du juste et que le spécialiste réseau est en congé thalasso. 

Conclusion : on peut à la limite s’engager sur un taux de disponibilité du réseau (les fils de cuivre et les équipements d’interconnexion), et encore. Au-delà – ou plutôt au-dessus dans le modèle OSI –, c’est la terra incognita.