La disponibilité est définie comme le rapport entre le temps pendant lequel un équipement est opérationnel et l’intervalle de temps de la mesure¹.

Une disponibilité de 20/24^ième par exemple, exprime qu’un équipement quelconque, que ce soit du matériel, un programme ou la combinaison des deux, était utilisable 20 heures sur un jour. Typiquement, les objectifs de disponibilité sont spécifiés sous forme d’un nombre décimal, comme 0,9998 ou, le plus souvent, en pourcentages, comme 99,98%, qui représentent le pourcentage du temps pendant lequel l’équipement a été disponible sur un an. D’un point de vue mathématique, il s’agit en fait d’une moyenne mobile, appelée aussi moyenne glissante, sur un intervalle de temps d’un an.

Les objectifs de disponibilités peuvent être modulés en fonction des exigences des utilisateurs. Tous les systèmes ne demandent pas une disponibilité 24 heures sur 24 et 365 jours par an. De nombreuses applications, par exemple, ne sont utilisées que pendant les heures ouvrées et l’on peut alors parfaitement se contenter d’une disponibilité 5 jours sur 7 et de 7 à 19 heures. La mesure de la disponibilité se fera alors uniquement pendant les périodes correspondant aux objectifs.

Il est aussi envisageable de définir des objectifs différents suivant les périodes. Par exemple, 99,99% pendant la journée et 99,95% la nuit. Cette pratique entraîne néanmoins un accroissement de la complexité.

Généralement, le terme « temps d’arrêt » auquel on préfèrera le mot anglais «downtime» fait référence à la période de temps durant laquelle un système est indisponible. Son opposé, l’«uptime» est la mesure du temps pendant lequel un système a été fonctionnel, accessible aux utilisateurs. Ainsi, un système pour lequel on garanti un downtime maximal de 52 minutes par an aura une garantie de disponibilité de 99,99%.

Par un raccourci typique en informatique, la disponibilité d’un système peut aussi être définie en 9. Cinq neufs signifie 99,999% de disponibilité, ce qui traduit un downtime maximal d’un peu plus de cinq minutes par an. Bien que fréquente, cette notation est déconseillée car finalement peu souple puisqu’elle omet toutes les valeurs qu’il peut y avoir entre, par exemple, 99,99% et 99,9%. Cette réalité amène alors bien des auteurs à jongler avec deux notations différentes au sein d’un même document, les pourcentages et les « 9 » alors que le pourcentage suffit.

La formule synthétisant le calcul de la disponibilité est la suivante :

Et enfin, le tableau suivant est le grand classique qui reprend les downtimes maximum admissibles par an en fonction des exigences de disponibilité.

Il ne faut cependant pas perdre de vue que les downtimes admissibles sont calculés sur une base d’un an complet, soit 8760 heures. Cela signifie que si l’on envisage un système dont l’objectif de disponibilité est basé sur une ou plusieurs périodes plus restreintes, les donwntimes devront être adaptés. Ainsi, pour un système dont on attend au minimum 99,99% de disponibilité, 12 heures par jour au lieu de 24, le donwntimes maximum admissible sur un an ne sera plus que de 26 minutes au lieu de 52.

Bien que souvent admises telles quelles par le monde ICT, ces définitions d’une simplicité séduisante, n’en sont pas moins simplistes. La réalité se révèle souvent plus complexe.

Une des hypothèses de ce modèle est que dix interruptions d’une minute ont le même effet sur l’utilisateur qu’une unique panne de dix minutes, ce qui n’est en général pas le cas. Si le système connaît des interruptions répétées, l’utilisateur peut à juste titre supposer qu’il n’est pas fiable. Pour illustrer ce propos, il suffit de se demander comment un utilisateur considérerait un système en panne une minute toutes les semaines: comme un système ayant une disponibilité de 99,99% (52 fois une minute de downtime par an) ou comme un système sans aucune fiabilité? Poser la question, c’est y répondre…

Autre exemple: un utilisateur qui a un travail basé sur des cycles d’une journée pourrait considérer une panne d’une minute comme un downtime d’une journée, vu que son travail quotidien n’a pu être fait. Dans le même temps, un constructeur informatique pourrait voir la même panne comme une interruption d’une minute.

Pour compliquer encore un peu une notion qui promettait pourtant d’être simple, dans les services ICT, le downtime est le plus souvent divisé en deux catégories selon qu’il est planifié ou non. Le point de vue du client est plus radical puisqu’il additionne les deux chiffres pour connaître la disponibilité globale d’un système. Cette dernière position est judicieuse dans la mesure où, d’un point de vue ICT, un système en maintenance 100% du temps aura un uptime de 100% ce qui est un non-sens. Cette distinction entre « planifié » ou non est donc à bannir dans le calcul de disponibilité. Le fait qu’une interruption soit planifiée permet simplement de la rendre plus admissible par le client qui peut alors s’y préparer, voire en choisir le moment en fonction des ses priorités. Le fait de planifier un downtime et donc de l’annoncer, est finalement plus une question de courtoisie et d’image envers le client que de disponibilité: de toutes façons, ce downtime en restera un et sera débité de l’uptime.

Un autre mythe à briser est celui qui prétend que la disponibilité globale d’un système est égale à celle de son élément le plus faible. Ce n’est définitivement pas exact.

En effet, même si tous les éléments d’une chaîne ont la même disponibilité, la disponibilité résultante globale sera toujours moins bonne. Par exemple, si quatre éléments connectés en série mentionnent dans leurs caractéristiques une disponibilité de 99,99% sur un an et que tous atteignent leur downtime maximum, mais à des moments différents, cela va finalement représenter quatre fois 52 minutes (0,01% d’une année) d’indisponibilité ce qui correspond à une disponibilité globale de 99,96% (100%-4×0,01%), malgré le fait que le client final paie quatre fois le prix pour 99,99%. Pire, la probabilité d’atteindre un aussi mauvais résultat est grande si les quatre fournisseurs ne synchronisent pas leurs fenêtres de maintenance.

Ceci tend à montrer que la tendance actuelle à scinder un programme en de multiples entités isolées (multi-tiers, SOA, etc), si elle n’est pas contrôlée, peut avoir un effet négatif sur la disponibilité globale offerte aux clients de ce programme. De même, l’éclatement des responsabilités entre de multiples équipes est tout aussi nocive pour la disponibilité. Ainsi une plateforme composée d’un ordinateur, d’un disque SAN et d’une connexion réseau aura une disponibilité de 99,97% si la responsabilité de chacun de ses éléments constitutifs est donnée à une équipe différente ayant séparément un objectif de disponibilité de 99,99%. On ne peut donc multiplier les équipes sans pénaliser la disponibilité globale ou exiger de la part de chaque équipe séparément une disponibilité meilleure que ce qu’elle était quand la responsabilité ne dépendait que d’une équipe unique. Donc, une décision qui pourrait n’apparaître qu’organisationnelle – scinder une équipe – comporte clairement un impact majeur quant au risque d’indisponibilité.

Il existe encore une zone grise entre « disponible » et « indisponible », quand un système fonctionne mais ne délivre pas le service comme attendu. Par exemple, si le système est trop lent ou perd des connexions, etc. Malgré le fait que le système fonctionnait, ce temps de mauvais fonctionnement peut être vu par le client comme de l’indisponibilité. Toutefois, les limites de cette responsabilité sont souvent difficiles à établir. Une question récurrente est de savoir ce qui cause l’indisponibilité et qui en est responsable.

Par exemple, d’un point de vue infrastructure, la qualité du programme importe peu. En effet, le programme est imposé par le client et sa qualité est sous son entière responsabilité. Seul incombe à l’infrastructure ICT de lui fournir un environnement qui puisse le faire tourner dans de bonnes conditions de disponibilité, performances et sécurité. Trivialement dit, si le programme se « plante », tant que ce n’est pas dû à l’indisponibilité de l’infrastructure, ce n’est pas l’affaire du responsable de l’infrastructure. Mais que se passe-t-il s’il se plante faute de ressources? Il n’aurait pas du se planter, mais signaler le manque de ressource. Le client avait-il clairement dimensionné le système lors de sa demande? Et il est possible de continuer ainsi sans fin…

Ceci met en lumière le fait que client et fournisseur doivent se mettre très clairement d’accord sur ce qu’est un système fonctionnel, sur les services qu’il doit rendre, avec quelles performances et dans quelles conditions.

¹ US Federal Standard 1037C, Glossary of Telecommunications Terms, https://its.ntia.gov/research-topics/federal-standard-1037c/