La métrologie de la résilience

Jusqu’à présent, nous avons présenté la résilience dans différentes branches de l’informatique, nous avons vu quelles pouvaient être les conséquences en cas de dysfonctionnements ainsi que les pratiques courantes pour les minimiser et remettre les systèmes en marche rapidement. Pour ce dernier article, nous allons voir quelles mesures peuvent être réalisées pour quantifier la résilience d’un système informatique.

L’ENISA a présenté une analyse sur les challenges dans la mesure de la résilience dans le domaine des réseaux. Il est difficile de définir des indicateurs pour mesurer la résilience et surtout de mettre en place les mesures correspondantes, plus le système étudié est complexe et moins les mesures effectuées sont efficaces. De plus, parmi les acteurs de l’industrie concernés, chacun utilise sa propre approche et il n’existe pas de standards ou de frameworks d’évaluation utilisables à l’échelle globale.

Parmi les recommandations émises, le rapport de l’ENISA suggère la mise en place d’une base commune pour la mesure de la résilience, celle-ci s’appuierait sur une représentation bi-dimensionelle pour classer nos métriques de résilience (sur un axe une classification suivant les incidents et sur un autre une classification suivant les domaines).

Il faut tout d’abord distinguer ce que l’on pourrait appeler les métriques d’impact et les métriques de résilience, Les métriques d’impact servent à mesurer les perturbations sur les services proposés suite à une ou plusieurs défaillances, ces mesures sont très importantes dans l’équation permettant d’établir le degré de résilience du système.

On peut citer comme métrique d’impact:
-le nombre d’utilisateurs impactés par la défaillance.
-le nombre d’éléments du réseau affectés par la défaillance.
-la zone géographique affectée par une défaillance.
-l’impact financier (coût, perte de parts de marché).
-l’impact sur l’image de l’entreprise.

Concernant les métriques de résilience, les étudiants en SI reconnaîtront des métriques définies lors de la présentation des processus ITIL ( Mean down time par exemple). On peut les représenter sous la forme d’une matrice suivant le domaine duquel dépend la métrique, ainsi que sur l’instant dont dépend la métrique. Par exemple certaines métriques de résiliences sont pertinentes dans l’attente d’une défaillance (audit de sécurité), d’autres lorsque le système est opérationnel et qu’une défaillance peut survenir (temps moyen entre les défaillances), tandis que d’autres métriques caractérisent les réponses apportées aux pannes (temps moyen pour réparer).

Nous vous proposons une partie de la représentation proposée dans le rapport, qui montre un grand nombre de métriques, afin de vous donner un aperçu puis nous en expliciterons certaines, qui nous paraissent essentielles. L’idée est plus que vous puissiez vous faire votre propre idée sur les différentes métriques existantes et la facçon dont elles sont décrites.

Pour représenter une métrique, on utilise une syntaxe précise qui permet d’accéder rapidement aux objectifs de la métrique, la façon dont on la calcule, la fréquence à laquelle elle doit être calculée, etc..
Nous allons vous présenter une métrique en utilisant ce système de représentation:

Nom de la métrique MTBF : Mean Time Between Failures
Source: Cette métrique est définie à partir d’un ouvrage
Description: Le MTBF est un indicateur basique de la fiabilité du système face aux incidents.
Le MTBF met en avant le temps moyen prévu entre des défaillances consécutives, une défaillance correspond à une transition entre un état nominal du système et un état dégradé voir critique.
Méthode de calcul: Le MTBF se définit comme la valeur moyenne de l’intervalle de temps entre deux défaillances. On le calcul comme le rapport entre la somme des périodes d’activité du système et le nombre de défaillances observées sur une même durée. A noter que la durée de la défaillance n’a aucun impact.
Fréquence: Il peut être intéressant de visualiser cette indicateur en temps réel
Valeur Cible: La valeur critique à atteindre dépend énormément de la criticitédu système, on peut tolérer que des systèmes soient couramment interrompus par des défaillances, alors que d’autres doivent l’être le moins possible.

Vous pouvez consulter le rapport si vous saouhaitez une liste plus exhaustive des différentes métriques ainsi que leurs caractéristiques respectives.

Il faut également savoir que chaque système comprenant une application spécifique peut avoir besoin d’une métrique qui lui est propre afin de visualiser l’évolution de la qualité du service. Si par exemple vous développez uen application qui nécessite la géolocalisation du terminal, vous pouvez choisir de créer une métrique correspondant au temps où le signal GPS est suffisant pour déterminer une position par rapport au temps total d’utilisation de l’application. Ce qui est primordial ce n’est pas tant d’avoir des indicateurs par dizaines, mais surtout de bien avoir à l’esprit les réalités qu’il représente.

Le but de cet article était de sortir de l’aspect théorique de la résilience, et d’essayer de voir comment la résilience était abordée et évaluée dans des systèmes existants. Si vous êtes amenés a concevoir, ou même à gérer l’évolution d’un système informatique vous repenserez peut-être à ces quelques billets et essaierez de mettre en place un suivi de quelques métriques afin de vous assurer d’avoir un système résilient, et donc une offre de service permanente.

Sources:
Rapport technique de l’ENISA sur les métriques de résilience
Communique de presse ENISA

Licence Creative Commons

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>