[Tech] Perturber le SI pour tester sa résilience

Pour les entreprises dont l'activité repose entièrement sur les outils informatiques, les pannes peuvent rapidement devenir catastrophiques. Face à ce risque, deux types de réponses sont possibles : soit construire une infrastructure infaillible, soit faire en sorte que les incidents, acceptés, n'aient pas d'effet visible sur les opérations.
La première est, typiquement, celle qui est adoptée depuis toujours par les institutions financières. Netflix, distributeur de vidéos à la demande, donne un exemple extrême de la seconde, qui pourrait constituer une source d'inspiration, en particulier par les organisations qui s'intéressent au "cloud computing".
En effet, le "nuage" informatique impose de sérieux changements de perspective : si les grandes entreprises qui gèrent leurs propres infrastructures peuvent se permettre de coûteux investissements pour garantir un fonctionnement "sans faille" de leurs applications, les fournisseurs de "cloud" choisissent au contraire des composants standards à bas coût, dont les pannes sont inévitables. Dans ce cas, il faut donc prévoir dès l'origine les mécanismes qui permettront aux logiciels de "survivre" aux incidents.
Pour ce faire, Netflix estime que rien ne vaut l'expérience, de préférence permanente. C'est la raison de l'existence de Chaos Monkey, un outil qu'elle vient de mettre à la disposition de la communauté. Comme l'indique son nom, le but de ce petit logiciel est de semer le chaos dans les serveurs de l'entreprise, qui sont (depuis 2010) dans le "cloud" d'Amazon .
Concrètement, un service autonome va couper, de manière aléatoire, des instances d'applications fonctionnant en production. Si l'architecture du système est bien conçue, ces interruptions sont transparentes mais si, à l'inverse, des problèmes plus sérieux surviennent, les ingénieurs doivent rétablir le service et faire en sorte que la correction soit, à l'avenir, automatique.
L'idée sous-jacente de Netflix est que, les pannes étant inexorables, il est préférable de les provoquer à un moment où les compétences requises pour en corriger les conséquences sont présentes et en alerte, plutôt qu'en pleine soirée de week-end (par exemple). Et si le "Chaos Monkey" fonctionne en permanence (aux heures ouvrées, donc), c'est parce que les configurations des systèmes évoluent avec le temps et que ce qui donne satisfaction un jour donné peut ne plus fonctionner le lendemain.
Cette approche radicale est un véritable modèle, qui mérite d'être évalué par toutes les entreprises qui envisagent d'adopter le "cloud" pour des applications critiques, que ce nuage soit interne ou externe. Car le risque qu'elle adresse représente une des clés de la réussite d'une orientation "cloud" du Système d'Information (SI) de l'entreprise et représente un défi majeur pour les architectes habitués aux méthodes conventionnelles.
Mais il est aussi possible de projeter ce modèle encore plus loin... Par exemple, dans un SI traditionnel, le coût de l'infaillibilité des infrastructures mises en place est colossal alors que, chacun le sait, un incident important reste toujours possible (bien que sa probabilité soit très faible). Peut-être serait-il plus raisonnable, dans ce cas également, de minimiser les coûts d'implémentation et d'investir plutôt sur une architecture résiliente par sa capacité à absorber (toutes) les pannes ? En vérifiant en permanence son efficacité, bien sûr !
Dans un autre registre, les mêmes principes pourraient aussi être appliqués dans le domaine du développement logiciel (comme je l'ai déjà évoqué par le passé) et, probablement, d'autres encores...