Excusez-moi, qu’est-ce qui vient de se passer ? La résilience est difficile lorsque votre échec est dû à une « séquence d’événements presque impossible à prévoir »

Fonctionnalité Lorsque nous concevons des systèmes sur lesquels nos entreprises s’appuieront, nous le faisons en gardant à l’esprit la résilience.

Il y a vingt-cinq ans, des technologies telles que RAID et la mise en miroir de serveurs étaient nouvelles et, à certains égards, non triviales à mettre en œuvre ; aujourd’hui, ce n’est plus le cas et c’est un réflexe de se procurer plusieurs serveurs, commutateurs LAN, pare-feu, etc. pour construire des systèmes résilients.

Bien entendu, cela ne nous garantit pas une disponibilité à 100 %. La loi de M. Murphy s’applique de temps en temps : si votre pare-feu principal subit une panne matérielle, il y a une chance infime, mais non nulle, que le secondaire s’effondre également avant que vous ayez fini de remplacer le principal.

Si vous avez une panne de courant, il existe une probabilité également micro-tangible que le générateur que vous avez testé chaque semaine pendant des années choisira ce moment pour tousser obstinément plutôt que de rugir dans la vie. À moins que vous ne soyez (ou, plus précisément, la nature de votre entreprise) si peu risquée que vous puissiez justifier des dépenses sur des niveaux de résilience plus élevés pour réduire encore plus le risque d’une panne (mais jamais, bien sûr, à rien).

Il y a des occasions, cependant, où la planification de l’échec devient difficile.

Prenons un exemple récent. En juillet 2020, la principale entreprise de télécommunications de Jersey a subi une panne majeure en raison d’un problème avec un appareil fournissant un service horaire au réseau de l’organisation. L’élément déclencheur de cet événement était que l’appareil défaillant n’a pas échoué de la manière dont nous sommes tous habitués – en faisant un bruit de “bang” et en émettant de la fumée; s’il l’avait fait, en fait, tout se serait bien passé car l’unité secondaire aurait pris le relais.

Impossible

Non, c’était un type de serveur de temps plus sournois qui n’a échoué qu’en partie. Il a continué à fonctionner mais a commencé à servir des temps d’environ 20 ans dans le passé (ce n’était pas du tout une coïncidence, c’était le réglage de l’heure par défaut), déroutant ainsi les périphériques d’infrastructure réseau et provoquant l’arrêt du trafic.

L’insatisfaction des clients était palpable, bien sûr, mais en tant qu’informaticien, il faut ressentir quelque chose pour l’équipe technique de l’entreprise : combien d’entre nous considéreraient comme un cas de défaillance possible quelque chose que le chef technique a décrit à juste titre comme un ” séquence d’événements qu’il était presque impossible de prévoir » ?

(Incidemment, dans une histoire un peu plus encourageante, en revenant un instant sur notre point sur les couches supplémentaires de résilience, la même entreprise avait déjà survécu à la coupure de trois câbles offshore… en en ayant un quatrième).

Des outils de surveillance auraient-ils pu être mis en place pour détecter de tels problèmes lorsqu’ils surviennent ? Oui, absolument, mais le fait est que pour ce faire, il faudrait d’abord identifier les scénarios comme quelque chose qui pourrait se produire. Au sens de la gestion des risques, ce type de défaillance – à très fort impact mais infiniment improbable – est la pire des formes possibles pour un gestionnaire de risques. Il existe des théories et des livres sur la manière d’envisager et de gérer de tels risques, dont le plus connu est probablement le livre de Nassim Nicholas Taleb Le cygne noir, qui ne parle que de ce type de risque, mais si vous voulez essayer de vous défendre contre l’inattendu, vous devez au moins vous asseoir avec un nombre important de personnes de manière très ciblée, de préférence avec un expert dans le domaine guider et modérer, et travailler à l’identification de tels événements possibles de « cygne noir ».

Bien que le concept du cygne noir soit très certainement une chose à garder à l’esprit, il existe en fait un problème beaucoup plus courant avec les systèmes que nous considérons comme résilients : l’incapacité à comprendre comment fonctionne la résilience.

Une installation particulière dans une entreprise avec un bureau et deux centres de données avait des liens point à point dans un triangle entre chaque site, et chaque centre de données avait une connexion Internet. Les deux pare-feu, un dans chaque centre de données, ont été configurés comme une paire résiliente et ont fonctionné ainsi pendant des années. Un jour, le service Internet est tombé en panne et l’enquête a montré que l’unité secondaire avait perdu la trace de l’unité principale et était devenue l’unité principale. Avoir deux primaires actives a causé des flux de trafic divisés, et donc une panne.

Prévisible

Avec le recul, c’était tout à fait prévisible. La façon dont la relation primaire/secondaire était maintenue entre les appareils était que le primaire envoie un signal de « battement de cœur » au secondaire toutes les quelques secondes ; si le secondaire ne parvenait pas à recevoir le rythme cardiaque trois fois, il se réveillait et faisait office de primaire. Étant donné que les appareils se trouvaient dans des centres de données distincts, ils étaient connectés via diverses technologies : un cordon de raccordement LAN à un commutateur, à un émetteur-récepteur à fibre optique, à une fibre de télécommunication, puis la même chose à l’envers à l’autre extrémité.

Un défaut sur l’un de ces éléments pourrait amener les périphériques réseau à reconfigurer leur topologie pour basculer les données dans l’autre sens autour du triangle de fibre – le changement provoquant un blip de réseau suffisamment long pour laisser tomber trois battements de cœur. En fait, la seule configuration approuvée pour l’interconnexion primaire/secondaire était un câble Ethernet croisé d’un appareil à l’autre : le code de basculement a été écrit en supposant que, mis à part peut-être un défaut soudain de cordon de raccordement hautement improbable, le primaire devenant invisible au secondaire signifiait que le premier était mort.

Beaucoup d’entre nous ont rencontré des cas similaires, où quelque chose que nous nous attendions à basculer ne l’a pas fait. Il est également courant de rencontrer des cas où le basculement fonctionne correctement, mais il y a ensuite des problèmes avec le basculement, qui peuvent être tout aussi problématiques. Je me souviens d’un WAN mondial sur lequel j’ai travaillé une fois où, pour une raison quelconque, les basculements du primaire au secondaire étaient si rapides que vous n’avez remarqué aucune interruption (le seul indice était l’alerte de la console de surveillance) mais il y a eu une pause de plusieurs secondes lors de la restauration.

Dans l’exemple du pare-feu, même lorsque la connectivité était restaurée, les périphériques ne se resynchronisaient pas sans redémarrage : rappelez-vous, le seul scénario d’échec pris en charge était la mort complète du principal, ce qui signifiait que ce n’était qu’au démarrage qu’il vérifiait rôle que jouait son partenaire pour qu’il puisse agir en conséquence. Jusqu’à ce que quelqu’un l’éteigne et le rallume, il n’y avait aucune chance que le problème disparaisse.

Pour rendre nos systèmes résilients vraiment résilients, nous devons donc faire trois choses.

Tout d’abord, nous devrions réfléchir à ces événements de « cygne noir ». Il se peut que nous ne puissions pas nous permettre des masses de temps et d’efforts pour considérer des risques aussi peu probables, mais à tout le moins nous devrions prendre une décision consciente sur combien ou combien peu nous ferons à cet égard : la gestion des risques est une question de raisonnement et prendre des décisions conscientes comme ça.

Compétence

Deuxièmement, si nous n’avons pas connaissance du fonctionnement précis de nos systèmes et de leurs mécanismes de basculement, nous devons engager des personnes qui le font et bénéficier de leur expertise et de leur expérience… et pendant que nous y sommes, nous devrions lisez le manuel : neuf fois sur dix il nous dira comment configurer les choses, même s’il n’explique pas pourquoi.

Enfin, cependant, nous devons tester les choses – de manière approfondie et régulière. Dans notre exemple de pare-feu, tous les modes de défaillance potentiels auraient dû être pris en compte : si la défaillance d’un composant parmi une poignée de composants pouvait provoquer une panne, pourquoi ne pas tous les tester ? Et lorsque nous testons, nous devons le faire pour de vrai : nous ne testons pas seulement le basculement en laboratoire puis installons le kit dans une armoire de production, nous le testons une fois qu’il est dedans aussi.

Cela peut nous obliger à persuader l’entreprise que nous avons besoin d’un temps d’arrêt – ou du moins d’un temps d’arrêt potentiel pour faire face à l’échec du test – mais si la direction a du bon sens, elle sera persuadée qu’une panne approuvée pendant une fenêtre de temps prévisible avec l’équipe technique se tenir prêt et regarder comme des faucons est bien mieux qu’une panne inattendue mais tout à fait prévisible lorsque quelque chose se brise pour de vrai et que la résilience s’avère ne pas fonctionner.

Essai

Oh, et lorsque vous testez le basculement et la restauration, exécutez-vous pendant plusieurs jours dans un état de basculement si vous le pouvez : de nombreux problèmes ne se manifestent pas instantanément, et vous en apprendrez toujours plus dans un basculement sur plusieurs jours que dans celui qui ne dure que quelques minutes. Gardez également à l’esprit le mot « régulièrement » que j’ai utilisé à côté de « à fond ». Même si nous savons qu’il n’y a eu aucun changement à un composant particulier, il peut bien y avoir un effet d’entraînement d’un changement à quelque chose d’autre. Quelque chose qui était auparavant résilient est peut-être devenu moins résilient ou même non résilient parce que quelque chose d’autre a changé et nous n’avons pas réalisé l’implication – des tests de résilience réguliers sont donc absolument essentiels.

Parce que si quelque chose n’est pas résilient, ce ne sera généralement pas à cause d’un mode de défaillance potentiel ésotérique qui est presque impossible à anticiper et/ou difficile ou impossible à tester. La plupart du temps, ce sera parce que quelque chose s’est mal passé – ou quelque chose a été mal configuré – d’une manière que vous auriez pu imiter dans un test. ®