Single point of failure : point de dé­fail­lance unique

Un point de dé­fail­lance unique (« single point of failure » ou SPOF en anglais) cor­res­pond à une vul­né­ra­bi­lité d’un système ma­té­ria­li­sée par un seul et unique composant. Si le composant fait défaut, le système dans sa totalité échoue. Quels sont les dif­fé­rents types de SPOF et comment peut-on réduire le risque de voir des SPOF se produire ?

Un Single point of failure (SPOF) décrit un type de vul­né­ra­bi­lité au sein d’un système. On parle de SPOF lorsque la dé­fail­lance d’un seul composant provoque l’échec d’un système entier. Plusieurs modes d’échec existent. Ceux-ci se divisent en trois grandes ca­té­go­ries :

1. Talon d’Achille ou « maillon le plus faible de la chaîne » : la perte d’un seul composant entraîne l’arrêt du fonc­tion­ne­ment du système entier.
2. Réaction en chaîne ou « effet domino » : l’échec d’un composant entraîne l’échec con­sé­cu­tif d’autres com­po­sants, ce qui conduit à l’échec du système dans sa totalité.
3. Em­bou­teil­lage : un composant agit comme un facteur limitant du système dans son ensemble. Si le composant limitant est détérioré, les per­for­mances du système sont réduites à la hauteur des capacités du composant.

Les SPOF ont fré­quem­ment lieu au sein des systèmes complexes composés des com­po­sants in­ter­con­nec­tés en plusieurs couches. En fonction de la structure du système, l’échec d’un composant critique provoque l’échec du système dans sa totalité. Le single point of failure prend la forme d’un composant critique.

La com­plexité d’un système à plusieurs couches peut rendre difficile le fait de détecter les SPOF. Il n’y a pas de manière simple d’iden­ti­fier les in­te­rac­tions des com­po­sants in­di­vi­duels. Les défauts ou les problèmes sont dif­fi­ciles à repérer. Par principe, chaque composant non-redondant critique pour le fonc­tion­ne­ment devrait être traité comme un single point of failure.

Prenez le corps humain, par exemple. Nous ne disposons que d’un seul cœur ou d’un seul cerveau ; les organes vitaux n’ont pas été conçus en plusieurs exem­plaires. Si l’un de ces organes défaille, le corps dans son ensemble défaille. Le cœur et le cerveau sont des SPOF. Par contraste, les yeux, les oreilles, les poumons, et les reins existent en double. Si né­ces­saire, le corps compense la dé­fail­lance de l’un d’eux et continue à fonc­tion­ner avec une ef­fi­ca­cité réduite.

Au sein d’un centre de données, tous les com­po­sants critiques pour le fonc­tion­ne­ment cons­ti­tuent des SPOF po­ten­tiels. Par con­sé­quent, les serveurs sont en général équipés de con­nexions re­don­dantes au réseau élec­trique. Le stockage de masse est fourni de manière re­don­dante via des RAIDs ou des tech­no­lo­gies si­mi­laires. Le but étant de garantir le fait que le système continue à fonc­tion­ner même si un seul composant critique fait défaut.

Il existe de nombreux types de single points of failures. Après tout, les SPOF affectent bien plus que les systèmes d’in­for­ma­tion. Jetons un œil à quelques exemples.

Dans la célèbre saga « Star Wars », un point de dé­fail­lance unique conduit à la des­truc­tion de la terrible « Étoile de la Mort ». L’unique missile à proton tiré par le héros atteint un point critique au sein du réacteur. L’explosion provoque une réaction en chaîne dé­vas­ta­trice qui réduit l’Étoile de la Mort à néant.

En 2021, le porte-con­te­neurs « Ever Given » s’est retrouvé coincé dans le Canal de Suez. Le bateau s’est échoué à hauteur d’une section critique du canal qui se trouvait être la seule voie d’eau ac­ces­sible à cet endroit. Le blocage a paralysé le trafic maritime le long du canal entier. Le single point of failure, dans ce cas, était la voie d’eau non re­don­dante.

En 2018 et 2019, deux crashs aériens du « Boeing 737 MAX » ont eu lieu, ce qui a causé la perte de centaines de vies. La cause de ces crashs était un capteur unique qui envoyait des données erronées. Le système de pilotage au­to­ma­tique n’a pas fonc­tionné cor­rec­te­ment, puisqu’il se basait sur les données du capteur, et a fi­na­le­ment conduit les avions à leur perte. Plusieurs erreurs y ont concouru, mais le point de dé­fail­lance unique était le capteur.

Même les systèmes conçus pour la haute dis­po­ni­bi­lité ne sont pas par­fai­te­ment protégés contre les SPOF. Ces dernières années, certains services de Cloud majeurs ont rencontré, à plusieurs reprises, de graves dé­fail­lances. La plupart du temps, le point de dé­fail­lance unique était humain. Les mauvaises données de con­fi­gu­ra­tion peuvent vite paralyser un système de pro­duc­tion entier, même si ses com­po­sants sont conçus de manière re­don­dante.

Votre appareil est connecté au Wi-Fi, mais le na­vi­ga­teur Web ne fonc­tionne pas. Puis l’horloge commence à régler le temps au­to­ma­ti­que­ment. Ça vous dit quelque chose ? À ce stade, on peut déjà commencer à s’arracher les cheveux, mais l’ex­pli­ca­tion est simple :

Le slogan « C’est toujours le DNS » peut faire sourire, mais il décrit sé­rieu­se­ment le potentiel d’erreur du DNS (Domain Name System). Après tout, lorsque les serveurs DNS ne répondent pas, les sites Internet et les services peuvent défaillir de plusieurs manières dif­fé­rentes. L’effet est le même que si on vous coupait la connexion Internet. Néanmoins, le trafic de paquets entre les adresses IP fonc­tionne toujours dans ce cas.

En général, les erreurs DNS se pro­dui­sent côté uti­li­sa­teur si les serveurs DNS stockés dans le système ne sont pas ac­ces­sibles. Une bonne pratique consiste donc à stocker deux adresses de noms de serveurs. Si le premier serveur est in­dis­po­nible, le second est utilisé. Ceci crée de la re­don­dance et résout le point de dé­fail­lance unique.

Souvent, les deux serveurs DNS ap­par­tien­nent à la même or­ga­ni­sa­tion. Si l’un d’eux échoue, il y a une forte pro­ba­bi­lité pour que l’autre soit également affecté. Pour être tran­quille, vous pouvez stocker les adresses de deux noms de serveurs issus de dif­fé­rentes or­ga­ni­sa­tions. On retrouve la com­bi­nai­son populaire 1.1.1.1 et 9.9.9.9 de Cloud­flare et Quad9, res­pec­ti­ve­ment serveurs DNS primaire et se­con­daire.

Fin 2021, un grand nombre de services Web basés sur Java furent affectés par la vul­né­ra­bi­lité Log4Shell. Le single point of failure était une bi­blio­thèque de jour­na­li­sa­tion intitulée Log4J. Le cas le plus grave eut lieu lorsqu’une attaque système conduisit à la prise de contrôle d’un système vul­né­rable dans sa totalité.

En général, pour éviter les SPOF, mieux vaut prévenir que guérir. Par dé­fi­ni­tion, un single point of failure conduit un système dans sa totalité à cesser de fonc­tion­ner. Une fois que cela arrive, il est en général trop tard. La seule option qu’il vous reste est alors de limiter les dégâts.

C’est la raison pour laquelle les mesures pré­ven­tives et le fait d’anticiper les urgences cons­ti­tuent une meilleure stratégie. Vous pouvez imaginer des scénarios d’échec crédibles et analyser les risques et les mesures de pro­tec­tion possibles. Dif­fé­rents types de points uniques de dé­fail­lance peuvent être évités par certaines fonc­tion­na­li­tés d’un système :

Les systèmes critiques bien préparés sont soumis à une su­per­vi­sion en continu pour détecter les erreurs le plus tôt possible et les corriger si né­ces­saire.

L’une des re­com­man­da­tions visant à con­tre­car­rer les SPOF est de cons­truire des re­don­dances. Plusieurs instances d’un composant critique (par ex., l’ali­men­ta­tion en élec­tri­cité, la connexion réseau, le serveur DNS) fonc­tion­nent en parallèle. Si l’un deux fait défaut, le système continue à fonc­tion­ner sans perte de per­for­mance.

La re­don­dance évite également de nombreux SPOF côté logiciel. On peut, par exemple, citer l’op­po­si­tion entre mi­cro­ser­vices po­pu­laires d’un côté et logiciel mo­no­li­thique de l’autre. Un système composé de mi­cro­ser­vices est découplé et moins complexe, ce qui le rend plus robuste contre les SPOF. Étant donné que les mi­cro­ser­vices sont lancés en tant que con­te­neurs, cela facilite la cons­truc­tion de re­don­dances.

Mais de quelle manière la re­don­dance protège-t-elle un système exac­te­ment ? Utilisons l’es­ti­ma­tion de fiabilité d’un système, aussi connue sous le nom de « Loi de Lusser » pour l’illustrer. Voici un exemple de réflexion :

Con­si­dé­rons qu’un système dispose de deux con­nexions in­dé­pen­dantes et pa­ral­lèles à une source d’élec­tri­cité. Con­si­dé­rons également que la pro­ba­bi­lité que la connexion échoue dans un laps donné est de 1%. Dès lors, la pro­ba­bi­lité d’une dé­fail­lance complète du rac­cor­de­ment à l’élec­tri­cité peut être calculée en tant que produit des deux pro­ba­bi­li­tés :

1. Pro­ba­bi­lité d’échec d’une instance :

1% = 1 / 100 = 1 / 10 ^ 2 = 0.01

1. Pro­ba­bi­lité que deux instances fassent défaut l’une après l’autre :

1% * 1% = (1 / 10 ^ 2) ^ 2 = 1 / 10 ^ 4 = 0.0001

Comme vous pouvez le voir, la pro­ba­bi­lité qu’un SPOF ait lieu n’est pas divisée par deux lorsque deux instances sont exécutées, mais réduite de deux puis­sances de 10. Il s’agit d’une amé­lio­ra­tion con­si­dé­rable. Si trois instances sont exécutées en parallèle, une dé­fail­lance du système dans son ensemble devrait être quasi-im­pos­sible.

Mal­heu­reu­se­ment, la re­don­dance n’est pas la panacée. On peut plutôt dire qu’elle protège un système contre les SPOF dans les limites de certaines hy­po­thèses. Pour commencer, la pro­ba­bi­lité qu’une instance fasse défaut doit être in­dé­pen­dante de la pro­ba­bi­lité de dé­fail­lance de l’instance ou des instances re­don­dantes. Ce n’est pas le cas lorsque l’échec est dû à un événement extérieur. Si un data center prend feu, les com­po­sants re­don­dants échoue­ront ensemble.

Outre la re­don­dance des com­po­sants déployés, la ré­par­ti­tion de certains com­po­sants est critique pour atténuer les SPOF. La ré­par­ti­tion géo­gra­phique du stockage des données et des in­fras­truc­tures in­for­ma­tiques protège de toute ca­tas­trophe naturelle. De plus, viser une certaine hé­té­ro­gé­néité ou diversité des com­po­sants critique d’un système s’avère souvent payant. La diversité réduit la pro­ba­bi­lité que des instances re­don­dantes fassent défaut.

Il­lus­trons l’avantage de la diversité à l’aide de l’exemple de la cy­ber­sé­cu­rité. Imaginez un centre de données avec des ré­par­ti­teurs de charge re­don­dants conçus exac­te­ment sur le même modèle. Une vul­né­ra­bi­lité de sécurité dans l’un des ré­par­ti­teurs de charge se pré­sen­tera également dans les instances re­don­dantes. Dans le pire des cas, une attaque pa­ra­ly­sera toutes les instances. En utilisant dif­fé­rents modèles, le système dans son ensemble aura de meil­leures chances de continuer à fonc­tion­ner à un niveau de per­for­mance réduit.

La re­don­dance ne suffit pas toujours à éviter les SPOF. Et certains com­po­sants ne peuvent être élaborés de manière re­don­dante. Lorsque l’option de créer de la re­don­dance n’est pas dis­po­nible, d’autres stra­té­gies peuvent être adoptées.

L’approche « défense en pro­fon­deur » est bien connue en cy­ber­sé­cu­rité. Celle-ci implique de tracer plusieurs cercles de pro­tec­tions in­dé­pen­dants autour d’un système. Ces derniers devront subir des brèches les uns après les autres avant que le système ne finisse par s’effondrer. Les pro­ba­bi­li­tés qu’un système complet s’effondre à cause d’un seul composant s’en trouvent réduites.

En ce qui concerne les systèmes digitaux, il existe des langages de pro­gram­ma­tion dotés d’une tolérance aux pannes intégrée. L’exemple le plus connu est le langage « Erlang » développé à la fin des années 1980. Ac­com­pagné de l’en­vi­ron­ne­ment d’exécution associé, ce langage convient à la création de systèmes hautement dis­po­nibles et tolérants aux pannes.

Le triomphe du World Wide Web à l’échelle mondiale et la diffusion du dé­ve­lop­pe­ment Web ont fait émerger un nouveau défi. Les pro­gram­meurs ont été forcés de dé­ve­lop­per des sites Internet qui fonc­tion­ne­raient sur un grand nombre d’appareils. L’approche de base utilisée dans ce processus est appelée « dé­gra­da­tion gracieuse ». Si un na­vi­ga­teur ou un appareil n’est pas com­pa­tible avec une tech­no­lo­gie en par­ti­cu­lier sur une page, celle-ci est rendue aussi bien que possible malgré tout. Il s’agit d’une approche de « panne douce » :

N’attendez pas que le système s’effondre pour iden­ti­fier tout point de dé­fail­lance unique au sein de votre système. Vous devrez procéder de manière proactive dans le cadre d’une stratégie de gestion des risques. On utilisera des analyses tirées de l’in­gé­nie­rie de la fiabilité telles que des arbres de dé­fail­lance et d’évé­ne­ments. Des analyses des modes de dé­fail­lance, de leurs effets et de leur criticité (AMDEC) seront menées pour iden­ti­fier les sources de dé­fail­lance les plus critiques.

L’approche générale pour iden­ti­fier les single points of failure dans l’in­for­ma­tique d’en­tre­prise est de mener une es­ti­ma­tion des risques des trois prin­ci­pales di­men­sions :

• Ma­té­rielle
• Lo­gi­cielle / services / four­nis­seur
• Per­son­nelle

Commencez par créer une check-list d’analyse SPOF pour exposer les domaines généraux né­ces­si­tant une analyse plus poussée. Puis, une analyse SPOF détaillée des domaines in­di­vi­duels sera effectuée :

• Les appareils non su­per­vi­sés au sein du réseau
• Les systèmes logiciels ou matériels non-re­don­dants
• Les employés et pres­ta­taires ne pouvant être remplacés en cas d’urgence
• Toutes données non incluses dans des sau­ve­gardes

Pour chaque composant du système, l’effet négatif d’une dé­fail­lance est analysé. De plus, la pro­ba­bi­lité ap­proxi­ma­tive d’un échec ca­tas­tro­phique est estimée. Les résultats sont in­cor­po­rés dans un plan global de « ré­cu­pé­ra­tion en cas de désastre » pour assurer la sécurité du centre de données.

À titre de mesure de base pour éviter les SPOF, la re­don­dance du stockage de données et des capacités in­for­ma­tiques devrait être assurée à trois niveaux :

• Au niveau serveur à travers des com­po­sants matériels re­don­dants
• Au niveau du système à travers le clus­te­ring, càd l’uti­li­sa­tion de plusieurs serveurs
• Au niveau du centre de données en utilisant des sites d’ex­ploi­ta­tion répartis géo­gra­phi­que­ment