Mesure de la disponibilité d’un service

problème baie datacenterUn nouveau post (voir ce précédent billet) de la société Cloud Consultingpartenaire des IT souhaitant étudier leur migration vers le Cloud Computing qui nous propose cette fois d’étudier la mesure de la disponibilité d’un service. Même si en général il est préférable de comptabiliser les temps d’interruption, pour calculer le taux de disponibilité…Voici donc un article sur la discontinuitié d’un service et les méthodes permettant de la mesurer.

La discontinuité (également appelée interruption) de service dure généralement plusieurs heures et affecte la disponibilité de l’application, disponibilité qui peut se mesurer enpourcentage par an. Par exemple, une application disponible à 99% (un chiffre qui peut paraître élevé) souffre déjà d’environ 4 jours d’indisponibilité par an ! C’est un résultat souvent critique pour la bonne marche de l’entreprise (imaginez l’impact sur une société d’e-business privé de son site marchand pendant 4 jours…).



Il n’y a pas de seuil normé à partir duquel on peut considérer une application comme étant hautement disponible. En électronique militaire par exemple, les logiciels embarqués sont souvent développés et testés pour atteindre les « 5 neuf » : 99,999% de disponibilité, soit moins de 5 minutes d’indisponibilité par an ! A contrario, dans les systèmes d’information (moins critiques que le logiciel embarqué ou temps réel), les chiffres sont plus modestes, avec 2 chiffres maximum après la virgule.



On estime la disponibilité attendue du service (ESA) suivant la formule suivante :

ESA = MTBF / (MTBF + MTTR)

Où :

  • Le MTBF (mean time between failure) est la mesure du temps estimé (ou moyen) entre deux défaillances d’un système donné. Ceci reflète la fréquence de défaillance du système considéré.
  • Le MTTR (mean time to repair) est la mesure du temps estimé (ou moyen) pour réparer le système suite à une défaillance.

Le temps attendu de récupération du service est alors :charge serveur


ESRT = (deadtime/2) + EFT + ESST

Où :

  • Le deadtime, comme mentionné précédemment, est le délai spécifié avant de considérer qu’une application ne répond plus. S’il est réglé trop court, des faux positifs seront détectés (l’application sera déclarée défaillante alors qu’elle ne l’est pas). S’il est réglé trop long, un temps trop important sera nécessaire avant de détecter la défaillance d’une application.
  • L’EFT (expected fencing time) est le temps estimé pour détruire (proprement ou non) l’application crashée.
  • L’ESST (expected service start time) est le temps estimé pour redémarrer l’application.

Comme on le voit, établir un plan de HA prenant en compte tous ces paramètres peut être fastidieux. Dans ce cadre, Cloud Consulting peut aider une IT en l’intéressant aux promesses du Cloud Computing, qui fait de la HA un de ses fers de lance.





Si vous souhaitez plus d’informations sur ce sujet n’hésitez pas à contacter : cloudconsulting.fr.



Source :

Sur le même thème :

Leave a Reply