Le compliqué, le complexe et le simple

Le compliqué, le complexe et le simple

« Les choses devraient être faites aussi simples que possible, mais pas plus simples. »- Albert Einstein. Levons en premier l’ambiguïté entre compliqué et complexe car on mélange parfois à tort ces deux adjectifs. Une chose compliquée est embrouillée, difficile à faire ou à comprendre parce qu’elle a été conçue comme telle, alors qu’une chose complexe comporte en soi plusieurs éléments imbriqués, ce qui peut la rendre difficile à saisir. Une chose est compliquée parce qu’on l’a rendue compliquée, alors qu’elle aurait pu être simple. On dit souvent qu’on complique une chose pour rien. A l’inverse, une chose est intrinsèquement complexe, c’est à dire qu’elle est complexe en soi en raison de sa nature même et non par la faute de quelqu’un. Lorsqu’on s’apprête à étudier un système de grande taille, il faut procéder par étapes. Si le système est déjà existant, il faut d’abord faire la part entre le compliqué et la complexité du système. Améliorer ensuite le compliqué et le rendre plus simple. Puis définir la complexité du système résultant, c’est à dire définir tout ce qui englobe les différents éléments le composant et comment ils sont reliés entre eux. C’est à partir de cette définition que l’on peut dégager une simplicité d’utilisation. Autrement dit, la simplicité d’utilisation d’un système consiste à cacher la complexité de tout ce qui n’est pas nécessaire à l’utilisation de ce système. Dans cette thèse, nous nous intéressons aux systèmes informatiques actuels, qui, pour « compliquer » la chose, mélangent parfois le compliqué et la complexité.

Histoire de simplifications

Prenons quelques exemples historiques pour illustrer des étapes de simplification technologiques. Le premier concerne l’histoire de l’automobile. Ne serait-ce que le mot automobile contient déjà une étymologie qui rassemble « auto » (du grec autos qui veut dire soi-même) et « mobile » (du latin qui veut dire qui se meut), signifiant une simplification d’utilisation par automatisation du mouvement. Dans les années 1900, les automobiles devaient être manoeuvrées par des opérateurs-chauffeurs qualifiés pour contrôler la transmission manuelle à l’huile, ajuster les bougies et régler les différentes pressions. Un mécanicien compétent était requis car les pannes étaient très fréquentes. A partir des années 1930, les automobiles deviennent « utilisables » par des personnes non qualifiées et deviennent populaires, les infrastructures en réseaux de routes et en stations-service se développent fortement. C’est parce que l’interface d’utilisation a été grandement simplifiée et parce que la complexité de gestion a été maitrisée, que l’automobile devient de plus en plus sûre à utiliser et que la technologie se développe. En continuant dans les technologies du 19ème siècle, les premiers réseaux électriques incluaient leur propre générateur et s’étalaient sur quelques kilomètres. Par exemple, le premier réseau électrique de New York avait essentiellement pour but l’éclairage, découpé par quartiers, mais souffrait de nombreuses pannes. Ces réseaux sensibles et notamment ceux implantés dans de grandes entreprises, étaient à l’origine gérés par des « vice-président pour l’électricité », ces personnes étaient en général des séniors ayant une longue expérience dans le management. Une génération plus tard, l’accès au réseau électrique  est largement simplifié et automatisé et l’interface d’utilisation, la prise électrique, est omniprésente. Enfin, dans un passé plus proche, l’histoire des communications téléphoniques dans les années 1920 suit le même schéma. La demande pour des opérateurs de plus en plus formés dans les centres de commutation explose en même temps que l’utilisation de la téléphonie fixe. Ces opérateurs humains sont ensuite remplacés par des commutateurs automatiques et l’interface d’utilisation est elle aussi simplifiée, avec une numérotation standardisée pour joindre un correspondant plus facilement.

La dualité simplicité – complexité 

Le point commun de ces histoires de simplifications vient du fait qu’à l’origine, toutes les sortes de technologies ont un besoin en investissement humain important. Les nouvelles technologies ou les technologies émergentes sont typiquement destinées à des spécialistes expérimentés. Elles font appel à un besoin d’expertise pointu pour l’installation, le démarrage et la maintenance des nouveaux systèmes. En général, le travail humain est considéré comme requis par défaut au premier abord, notamment pour ses qualités de flexibilité et d’adaptabilité. Au démarrage de ces nouvelles technologies, ce travail humain est donc toujours supérieur aux éventuelles alternatives. Au final, lorsque la technologie arrive à maturation, les humains sont complètement supplantés ou en grande partie remplacés par une technologie devenue simple (pour les humains) et standardisée. Cela permet notamment d’élargir l’adoption de cette technologie (électricité, automobiles), de réduire les coûts et d’augmenter les ventes (révolution industrielle, agriculture) ou de permettre une performance accrue dépassant les capacités humaines actuelles (conquête spatiale). La simplification de l’utilisation de la technologie est très souvent liée à une complexification globale du système. En effet, les différentes tâches humaines nécessaires au commencement d’une technologie sont remplacées par des petits systèmes de contrôle, se rajoutant au système global. Il reste à savoir si c’est une règle universelle : c’est à dire si la simplicité d’usage engendre inévitablement un système complexe sur lequel s’appuyer.

Les défis de la complexité grandissante

A partir des années 2000, en parallèle de l’explosion des technologies de l’information et de la communication, on assiste à une forte demande en administrateurs humains dans les systèmes informatiques. On parle souvent de « responsable des technologies de l’information et de la communication », ce qui fait penser aux « vice-président pour l’électricité » évoqués précédemment. Encore aujourd’hui, cette demande en administrateurs humains ne semble pas faiblir. C’est en 2001 que le responsable des laboratoires de recherche d’IBM, Paul Horn, a déclaré : « le niveau de complexité atteint par l’informatique a engendré une crise qu’il n’est plus possible de surmonter qu’en réalisant un immense travail collectif de recherche » [1]. En effet, les systèmes informatiques modernes se complexifient par l’ajout récurrent de nouvelles briques technologiques et l’émergence de grands systèmes imbriquant de multiples éléments communicants. L’administration de ces systèmes est d’autant plus problématique que l’adoption de ces nouvelles technologies par le grand public est beaucoup plus rapide (de l’ordre de quelques années) que les technologies évoquées précédemment (automobile, électricité sur plusieurs dizaines d’années…). Le nombre d’outils et de matériels communicants ne cesse de croître et l’informatique mobile augmente en étendant ses technologies de communication. Pour les particuliers, les ordinateurs portables, PDAs, smartphones ou téléphones portables, ainsi que l’évantail des technologies sans fils utilisées rend la gestion et le contrôle manuels des systèmes de plus en plus difficiles. Pour les industriels, les nouveaux serveurs et services connectés ne cessent de se diversifier. Ce volume et cette complexité sont actuellement gérés par des humains hautement qualifiés, augmentant ainsi le coût de gestion. De plus, le contrôle manuel de ces systèmes prend beaucoup de temps et engendre un grand risque en terme d’erreurs humaines. Le problème général de ces systèmes informatiques modernes est que leur développement est freiné à cause de leur complexité et en particulier à cause de la complexité de leur gestion.

D’après une étude sur les tendances technologiques menée à l’université de Berkeley en 2002 [2], les industries du domaine de l’information et de la technologie sont appelées à délivrer des services de plus en plus rapidement et à un coût moindre. Ces services doivent être intégrés dans des infrastructures déjà existantes, augmentant ainsi la complexité résultante. Le coût de gestion humain de ces infrastructures dépasse maintenant le coût des équipements matériels et logiciels. Ce coût multiple par un facteur allant de 3 à 18 le coût global d’investissement dans l’infrastructure informatique. De plus, le budget dépensé pour prévenir ou réparer les pannes varie dans une proportion allant d’1/3 à 1/2 du budget total du domaine, dépendant du type de système utilisé.

Les objectifs de la thèse : l’auto-gestion – « Self-management »

En anglais, le préfixe « self » s’applique aux actions s’effectuant elles-mêmes. On parle de système informatique « self-* » ou encore de « selfware » à l’image des « software ou « hardware ». C’est en 1995 que Wooldridge et Jennings [3] identifient les propriétés fondamentales des « self-* » en introduisant les premiers systèmes multi-agents :
– autonomie : les agents opèrent sans intervention directe humaine et ont un contrôle interne de leurs actions pour mener à bien une tâche définie.
– abilité sociale : les agents interagissent entre eux (et avec les humains) via des langages et des protocoles de communication inter-agents.
– réactivité : les agents perçoivent l’environnement qui les entoure et répondent aux changements de cet environnement.
– proactivité : les agents ne répondent pas seulement aux changements de l’environnement mais peuvent aussi prendre des initiatives suivant des politiques ou des stratégies. Cette approche est une des solutions à la gestion de la complexité.

L’auto-gestion – « Self-management »

C’est en appliquant les propriétés des « self-* » pour les systèmes informatiques que Kephart et Chess [4] ainsi que Brantz [5] définissent en 2003 les quatre paradigmes devant être implémentés au minimum dans de tels systèmes pour qu’ils deviennent auto-gérés ou « self-managed » : « self-configuration », « self-optimization », « self-healing » et « selfprotection ». Dans cette thèse, nous suivons une démarche qui apporte des contributions dans ces quatre problématiques, chaque aspect étant nécessaire pour la création d’un système informatique qui fait face à la gestion de la complexité grandissante :
1. Auto-guérison – self-healing : Un système est qualifié de « self-healing »  quand il peut maintenir son activité en surmontant les événements routiniers ou extraordinaires dus aux dysfonctionnements de ses éléments. Il peut se surveiller, détecter les erreurs ou les situations qui peuvent se manifester plus tardivement comme des erreurs. Il peut initier une réparation par lui-même et ce de manière à ce que son activité soit la moins perturbée possible. On parle aussi de la gestion des pannes : les pannes sont très fréquentes dans un environnement composé de centaines voire de milliers de machines et d’entités logicielles. Il existe deux types de panne : la panne matérielle et la panne logicielle. La gestion des pannes consiste à détecter la défaillance d’une machine ou d’un logiciel en vue de permettre aux administrateurs de ramener le système dans un état opérationnel.
2. Auto-protection – self-protection : la « self-protection » d’un système lui permet d’ajuster son comportement pour assurer sa survie, ainsi que pour la confidentialité et la protection de ses données. Cet « instinct de conservation » doit aussi lui permettre de réagir à des attaques de toutes sortes, en anticiper les menaces et lui permettre de prendre les mesures adéquates. On parle aussi de la gestion de la sécurité : cette gestion peut être décomposée en deux vues : la protection interne et la protection externe. La protection interne apporte une cohérence globale au système à tout instant (c’est à dire maintient le système dans un état cohérent) et la protection externe contre les événements dit exogènes gère les attaques malicieuses, les infiltrations et autres infections par des virus.
3. Auto-configuration – « self-configuration » : La propriété de « self-configuration » permet à un système de s’installer, de se paramétrer et de se mettre à jour tout seul. La manière d’installer et de paramétrer les éléments dépend des besoins du système mais aussi des utilisateurs. Si certains éléments sont configurés ou installés manuellement par un humain, le système en comprend les implications et s’y adapte. On parle aussi de la gestion du déploiement : cette fonction est subdivisée en plusieurs tâches à savoir : la configuration, l’installation, le démarrage, la désinstallation, la mise à jour et l’arrêt des éléments d’un système ;
4. Auto-optimisation – « self-optimisation » : La propriété de « self-optimization » permet au système d’utiliser au mieux et en toutes circonstances toutes ses ressources. Cette optimisation doit s’effectuer dans le respect des critères définis dans la politique de gestion. Par exemple, une politique de gestion avec un compromis entre énergie électrique consommée et performance. On parle aussi de la gestion de performance : cette fonction consiste à assurer que le système reste dans un état dans lequel sa performance est la plus proche de l’optimal. L’environnement à administrer doit être adapté aux différentes variations de performance et aux pics de charge. Cela peut être, par exemple dans le cas d’un serveur, l’augmentation du nombre de requêtes clients à traiter .

Nous développerons à travers quatre chapitres distincts les contributions sur ces quatre propriétés fondamentales du « self-management ».

Table des matières

1 Introduction
1.1 Motivation principale : la gestion de la complexité grandissante
1.1.1 Le compliqué, le complexe et le simple
1.1.2 Histoire de simplifications
1.1.3 La dualité simplicité – complexité
1.2 Problématiques soulevées par la thèse
1.2.1 Les défis de la complexité grandissante
1.2.2 Les objectifs de la thèse : l’auto-gestion – « Self-management »
1.2.3 L’auto-gestion – « Self-management »
1.2.4 Le besoin de généricité
1.3 Vue globale de la thèse
2 État de l’art
2.1 L’informatique autonomique ou « Autonomic Computing »
2.1.1 Automatique, Autonome et Autonomique
2.1.1.1 Différence entre automatique et autonome
2.1.1.2 Différence entre autonome et autonomique
2.1.2 La vision de l’informatique autonomique : historique et inspiration biologique
2.1.3 La gestion autonomique
2.2 La boucle de contrôle autonomique
2.2.1 La boucle MAPE-K
2.2.1.1 Le gestionnaire autonomique
2.2.1.2 L’observation ou « monitoring »
2.2.1.3 L’analyse
2.2.1.4 La planification
2.2.1.5 L’exécution
2.2.1.6 La base de connaissances
2.3 Contexte de l’étude et définitions
2.3.1 Grappes de machines ou « Clusters »
2.3.2 Grilles informatiques
2.3.3 Centres de calcul et de traitement des données « Data centers » et nuages informatiques « clouds »
2.3.4 Réseaux de capteurs
2.3.4.1 Exemple : les SunSPOTs
2.3.5 L’intergiciel XSStreaMWare de gestion des réseaux de capteur
2.3.5.1 Présentation globale d’XSStreaMWare
2.3.5.2 Hiérarchie du modèle générique XSStreaMWare : le DATAMODEL
2.3.6 Les logiciels patrimoniaux existants
2.3.7 L’application DIET
2.3.8 Les applications de simulation électromagnétiques
2.3.8.1 Les sciences CEM : TLM et SCT
2.3.8.2 L’application YatPac
2.4 Positionnement par rapport à l’existant
2.4.1 Degré d’autonomicité et degré de généricité
2.4.2 Exemples d’approches existantes
2.4.2.1 Niveau 1 : Gestion intégrée spécifique à une application
2.4.2.2 Niveau 2 : Gestion appliquée à un domaine de compétences
2.4.2.3 Niveau 3 : Gestion générique par API avec modification des logiciels
2.4.2.4 Niveau 4 : Gestion générique sans modification des logiciels patrimoniaux
2.4.2.4.1 Le concept d’encapsulation, modèle à composants Fractal
2.4.2.4.2 DeployWare
2.4.2.4.3 Adage
2.4.2.4.4 JADE
2.5 Présentation du système pour l’intégration des contributions
2.5.1 Le système de gestion autonomique TUNe : Toulouse University Network
2.5.2 Les phases d’administration autonomique dans TUNe
2.5.3 Vocabulaire du triangle TUNe et fonctionnement global
2.5.4 Etapes de construction d’une gestion autonomique avec TUNe
2.5.4.1 1ère étape : description de l’infrastructure matérielle
2.5.4.2 2ème étape : description de l’infrastructure logicielle
2.5.4.3 3ème étape : définition de l’encapsulation des logiciels
2.5.4.4 4ème étape : définition des règles de configuration
2.5.4.5 Vue globale de la construction d’une gestion autonomique avec TUNe
2.5.4.6 Introduction d’une dénomination
2.6 Etat de l’art : synthèse
3 Auto-guérison – « Self-healing »
3.1 Introduction
3.2 Méta-modélisation des diagrammes de spécification de politiques de gestion
– « Policy Description Diagrams » (PDD)
3.2.1 Forme MOF « Meta-Object Facility » et forme EBNF « étendue de Backus-Naur »
3.2.2 Méta-modèle des PDD
3.2.2.1 Méta-modèle de la partie graphique sous forme MOF
3.2.2.1.1 Le stéréotype Action
3.2.2.1.2 Le stéréotype Control
3.2.2.2 Méta-modéle de la partie syntaxique sous forme EBNF
3.3 Validation
3.3.1 Description des expériences
3.3.1.1 Cadre matériel de l’expérience
3.3.1.2 Cadre logiciel de l’expérience
3.3.1.2.1 Expérience sans agrégation des événements
3.3.1.2.2 Expérience avec agrégation des événements
3.3.2 PDD utilisés pour les expériences
3.3.2.1 PDD utilisés pour la phase de démarrage
3.3.2.2 PDD utilisés pour les reconfigurations durant la phase de gestion
3.3.2.2.1 PDD pour le « self-healing » des LA
3.3.2.2.2 PDD pour le « self-healing » des SEDs
3.3.2.3 Temps de réparation du cluster
3.4 Conclusion
4 Conclusion

Lire le rapport complet