Ce que l'architecture peut nous apprendre sur les systèmes d'auto-guérison

Les équipes DevOps et les ingénieurs de fiabilité du site (SRE) traitent quotidiennement du code. Cela leur apprend à scruter leur monde, à faire des observations astucieuses et à établir des liens inattendus. Après tout, bien que de nature hautement logique et mathématique, le développement de logiciels est, au moins en partie, une forme d'art. 

Vous n'êtes pas convaincu par cette affirmation ? Considérez les parallèles entre les exploits architecturaux les plus remarquables de l'histoire et l'ingénierie logicielle moderne. C'est une comparaison pertinente : tout comme le génie logiciel, l'architecture utilise des calculs mathématiques complexes pour créer quelque chose de beau. Et dans les deux disciplines, une légère erreur de calcul peut entraîner des conséquences importantes. De manière fascinante, de nombreuses erreurs architecturales célèbres sont analogues aux problèmes rencontrés dans le code.

N'oubliez pas que l'inspiration est partout, tant que vous savez où chercher. Voici quelques leçons que les ingénieurs logiciels peuvent tirer des épiphanies architecturales à travers les siècles, en particulier en ce qui concerne l'avenir des systèmes d'auto-guérison.

Leçon 1 : Les cas Edge exploiteront toujours les vulnérabilités du système

La tour Citicorp - maintenant appelée 601 Lexington - a été construite à New York en 1977, date à laquelle elle était le septième plus haut bâtiment du monde. La conception ultramoderne du gratte-ciel comprenait trois échasses de plus de 100 pieds. C'était une merveille à la fin. Cependant, un étudiant de premier cycle a rapidement découvert quelque chose de choquant : des vents forts pourrait compromettre l'intégrité du bâtiment. Plus précisément, si de puissants vents de cantonnement frappaient les coins de la tour Citicorp, la structure était susceptible de s'effondrer - un littéral cas de bord.

La tour avait une chance sur 16 de s'effondrer chaque année. Ces chances peuvent attirer quelqu'un assis à une table de jeu, mais les perspectives étaient sombres pour les architectes et les ingénieurs en structure derrière la tour Citicorp. Heureusement, les techniciens ont pu renforcer les joints boulonnés du bâtiment. La catastrophe a été évitée.

Les ingénieurs en structure savaient que la tour Citicorp serait éventuellement confrontée à un vent suffisamment fort pour compromettre ses roulements. De même, les ingénieurs en logiciel chevronnés savent qu'une surveillance robuste des performances des applications (APM) et une gestion des événements ne suffisent pas à protéger un système des inévitables cas extrêmes. C'est parce que les systèmes statiques sans apprentissage automatique (ML) les capacités ne peuvent pas gérer de nouvelles situations inattendues et imprévues, telles que des vents de cantonnement. Lorsqu'il s'appuie uniquement sur des outils de surveillance, un administrateur humain doit déchiffrer les erreurs et faire remonter le processus de gestion des incidents.

Pour réduire le temps moyen de récupération (MTTR)/temps moyen de détection (MTTD), les équipes DevOps doivent accepter la forte probabilité de cas extrêmes et s'efforcer de déployer des solutions d'auto-apprentissage de manière préventive. Cette leçon va loin, car la prévoyance est essentielle en ingénierie.

Leçon 2 : "Construire l'avion en vol" crée un cycle sans fin

Des événements tragiques ont livré plusieurs de les leçons les plus importantes de l'histoire de l'aviation. Lorsqu'un avion a subi une immense décompression en plein vol et s'est écrasé en 1954, les ingénieurs ont constaté que les fenêtres carrées des passagers étaient un point de stress inutile. Désormais, les avions étaient équipés de hublots arrondis. Les incendies à bord ont conduit à de nouvelles dispositions de sièges privilégiant la facilité d'évacuation. Ces changements ont sauvé d'innombrables vies.

Dans de nombreux secteurs, y compris l'aviation, il n'existe aucun moyen de soumettre un produit à des tests de résistance exhaustifs. Comme mentionné précédemment, les cas extrêmes sont inévitables. Le plus gros point à retenir ici est que les ingénieurs logiciels doivent tenir compte des vulnérabilités de leur système lorsqu'elles se présentent. A partir de là, ils doivent les traiter rapidement. Pour ce faire, il faut deux choses : (1) identifier et suivre les bons indicateurs de performance clés (KPI) et (2) investir du temps et des ressources dans l'amélioration des systèmes en fonction de mesures pertinentes.

L'équipe d'ingénierie moyenne investit dans 16 à 40 outils de surveillance, mais elle manque souvent la cible sur laquelle les mesures démontrent le succès. Moins de 15 % des équipes suivent le MTTD, elles manquent donc 66 % du cycle de vie des incidents. Et un quart des équipes déclarent manquant leurs accords de niveau de service (SLA) malgré un investissement important dans le suivi de la disponibilité. Cela nous indique que la collecte de données nécessite une analyse approfondie et systématique pour y parvenir – les solutions ponctuelles ne suffisent plus.

Les ingénieurs logiciels, les équipes DevOps et les SRE doivent donner la priorité aux processus et aux outils qui tirent de la valeur des quantités écrasantes d'informations sur la disponibilité. Au lieu de simplement observer une erreur critique, ils doivent prendre une page du livre d'un ingénieur aéronautique et prendre des décisions critiques, rapidement. Le secret pour y parvenir réside dans l'IA.

Leçon 3: L'IA est un élément fondamental des systèmes d'auto-guérison

Un système entièrement autonome, parfaitement fonctionnel et auto-réparateur est idéal pour tout ingénieur logiciel. Les systèmes qui se corrigent eux-mêmes sont bons pour la satisfaction des clients, car ils éliminent les temps d'arrêt coûteux pour les consommateurs. De plus, ils sont extrêmement bénéfiques pour les fonctions de gestion des services informatiques (ITSM), car ils réduisent considérablement le besoin d'une gestion fastidieuse des tickets. La construction d'un tel système nécessite plusieurs composants, dont beaucoup sont actuellement hors de portée. Mais nous sommes plus proches d'une réalité d'auto-guérison que certains ne le pensent.

Le manque d'adoption généralisée de l'IA reste le plus grand obstacle auquel les systèmes d'auto-guérison sont confrontés aujourd'hui. Bien que de nombreuses entreprises aient adopté des outils rudimentaires basés sur l'IA ou le ML, l'intégrité de ces outils est discutable. C'est-à-dire que de nombreux ingénieurs s'occupent de intelligence artificielle pour les opérations informatiques (AIOps) qui suivent une logique d'automatisation basée sur des règles au lieu d'algorithmes d'IA autonomes. La distinction peut sembler infime, mais en pratique, c'est la différence entre les heures de productivité perdue et les millions de pertes possibles.

Le fait est que les outils AIOps basés sur des règles analysent les interactions entre des solutions ponctuelles disparates et peuvent probablement identifier les erreurs de données courantes. Mais les systèmes basés sur l'automatisation ne peuvent pas traiter l'évolution d'erreurs entièrement nouvelles au fil du temps, ni prédire de nouveaux dysfonctionnements dans les données. En effet, les administrateurs humains qui codent ces fonctions demandent au système de suivre une si ceci, alors cela modèle logique. Des outils AIOps véritablement efficaces atténuent les erreurs qui surviennent aux quatre points de télémétrie classiques - de la détection à la résolution - en classant les modèles nouveaux et problématiques avant même que les techniciens humains ne soient conscients de leur existence. 

Pendant que nous attendons le imminente troisième vague d'IA, cette version d'AIOps est la plus proche que nous ayons des systèmes d'auto-guérison. Il sera intéressant de suivre comment les applications AIOps actuelles se répercutent sur l'avenir de l'IA, qui comprendra une automatisation pleinement réalisée et des possibilités de pensée indépendantes. Peut-être alors que les ingénieurs en structure récolteront eux aussi les fruits d'un système d'auto-guérison basé sur l'IA.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• Platoblockchain. Intelligence métaverse Web3. Connaissance Amplifiée. Accéder ici.
• La source: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/