Les systèmes / programmes / algorithmes distribués / ... sont souvent décrits avec le prédicat robuste ou tolérant aux pannes .
Quelle est la différence?
Détails:
Quand je google pour + robuste + "tolérant aux pannes", je ne reçois que deux hits, tous deux inutiles.
Quand je googlescholar pour les termes, je trouve beaucoup d'articles qui ont les deux termes dans leur titre. Malheureusement, ils ne définissent pas précisément les termes :( Mais puisqu'ils utilisent les deux termes, il semble que ni l'un ni l'autre n'implique l'autre.
Réponses:
Les deux décrivent la cohérence du comportement d'une application, mais la «robustesse» décrit la réponse d'une application à son entrée , tandis que la «tolérance aux pannes» décrit la réponse d'une application à son environnement .
Une application est robuste lorsqu'elle peut fonctionner de manière cohérente avec des données incohérentes. Par exemple: une application de cartes est robuste lorsqu'elle peut analyser des adresses dans différents formats avec différentes fautes d'orthographe et renvoyer un emplacement utile. Un lecteur de musique est robuste lorsqu'il peut continuer à décoder un MP3 après avoir rencontré un cadre mal formé. Un éditeur d'image est robuste lorsqu'il peut modifier une image avec des métadonnées EXIF intégrées qu'il pourrait ne pas reconnaître - surtout s'il peut apporter des modifications à l'image sans détruire les données EXIF.
Une application est tolérante aux pannes lorsqu'elle peut fonctionner de manière cohérente dans un environnement incohérent. Une application de base de données est tolérante aux pannes lorsqu'elle peut accéder à un autre fragment lorsque le serveur principal n'est pas disponible. Une application Web est tolérante aux pannes lorsqu'elle peut continuer à traiter les demandes du cache même lorsqu'un hôte API est inaccessible. Un sous-système de stockage est tolérant aux pannes lorsqu'il peut renvoyer des résultats calculés à partir de la parité lorsqu'un membre de disque est hors ligne.
Dans les deux cas, l'application devrait rester stable, se comporter de manière uniforme, préserver l'intégrité des données et fournir des résultats utiles même en cas d'erreur. Mais lors de l'évaluation de la robustesse, vous pouvez trouver des critères impliquant des données, tandis que lors de l'évaluation de la tolérance aux pannes, vous trouverez des critères impliquant la disponibilité.
L'un ne mène pas nécessairement à l'autre. Une application de reconnaissance vocale mobile peut être très robuste, offrant une capacité étonnante de reconnaître la parole de manière cohérente dans une variété d'accents régionaux avec d'énormes quantités de bruit de fond. Mais s'il est inutile sans une connexion de données cellulaire rapide, il n'est pas très tolérant aux pannes. De même, une application de publication Web peut être extrêmement tolérante aux pannes, avec plusieurs redondances à chaque niveau, capable de perdre des centres de données entiers sans échec, mais si elle supprime une table utilisateur et se bloque la première fois que quelqu'un s'enregistre avec une apostrophe dans son nom de famille , ce n'est pas du tout robuste.
Si vous recherchez de la littérature savante pour aider à décrire la distinction, vous pouvez chercher dans des domaines spécifiques qui utilisent des logiciels, plutôt que largement des logiciels en général. La recherche sur les applications distribuées pourrait être un terrain fertile pour les critères de tolérance aux pannes, et Google a publié certaines de leurs recherches qui pourraient être pertinentes. La recherche sur la modélisation des données aborde probablement les questions de robustesse, car les scientifiques sont particulièrement intéressés par les propriétés de robustesse qui donnent des résultats reproductibles. Vous pouvez probablement trouver des articles décrivant des applications statistiques qui pourraient être utiles, comme dans la modélisation du climat, la modélisation de la propagation RF ou le séquençage du génome. Vous trouverez également des ingénieurs discutant de la «conception robuste» dans des domaines tels que les systèmes de contrôle.
Le livre blanc de Google File System décrit leur approche des problèmes de tolérance aux pannes, qui implique généralement l'hypothèse que les défaillances des composants sont routinières et que l'application doit donc s'y adapter:
Ce projet pour une classe chez Rutgers prend en charge une définition orientée "panne de composant" de "tolérance aux pannes":
Il existe de nombreux articles sur la «modélisation robuste XYZ», selon le domaine que vous étudiez. La plupart décriront leurs critères de «robustesse» dans l'abstrait, et vous constaterez que tout cela a à voir avec la façon dont le modèle traite les entrées.
Ce mémoire d'un climatologue de la NASA décrit la robustesse comme critère d'évaluation des modèles climatiques:
Cet article d'un chercheur du MIT examine les applications de protocole sans fil, un domaine dans lequel la tolérance aux pannes et la robustesse se chevauchent, mais les auteurs utilisent «robuste» pour décrire les applications, les protocoles et les algorithmes, tandis qu'ils utilisent la «tolérance aux pannes» en référence à la topologie et composants:
la source
J'aime vraiment la réponse de @ johnnyb et l'approuve pour ses définitions nettes. Mais ayant travaillé dans le domaine pendant quelques décennies, je reconnais une autre manière (beaucoup moins formelle et précise) que ces termes sont fréquemment utilisés:
En tant que points informels le long d'un continuum «non fiable» à «parfaitement fiable».
Aucun système, application ou service ne peut garantir qu'il sera toujours et pour toujours au travail ("disponible en permanence" ou "disponible en permanence"). "Tolérant aux pannes" est depuis longtemps un substitut à "nous avons fait tout ce qui était humainement possible avec la technologie actuelle pour nous assurer que cette chose continue de fonctionner correctement."
Des mots comme «robuste», «durci» et «hautement disponible» sont utilisés comme jalons plus doux vers cet objectif de fonctionnement continu. Ils reflètent des niveaux croissants d'efforts, d'investissement et de confiance.
Parce que ces termes sont utilisés de manière informelle, il n'y a pas de classement entièrement canonique. «Hautement disponible» est généralement une affirmation forte, juste sous «résistant aux pannes» ou «tolérant aux pannes». Mais est-il «durci» mieux que «robuste»? Ou vice versa? Ça dépend du contexte. Celles-ci sont également fréquemment utilisées comme allégations de commercialisation de produits, avec toute la vantardise et l'imprécision intentionnelle que cela implique.
Habituellement, les organisations travaillant vers ces objectifs ont leur propre progression convenue en interne, généralement au moins à peu près liée aux objectifs / produits livrables du projet et aux paramètres externes tels que «trois neuf» ou «six neuf».
@johnnyb touche également à une distinction critique: la différence entre l'état de montée / descente de la plate-forme (disponibilité) d'une part, et les attributs d'algorithme, d'application ou de service d'autre part.
Je dis «attributs» car ils sont nombreux: performances, justesse et imperturbabilité ne sont que quelques-uns des éléments clés. Un système est-il réellement disponible et correct s'il fonctionne à seulement 10% des performances nominales? Pas selon les propriétaires d'entreprise si c'est la saison chargée! Il n'y a pas de grande vertu dans un système qui ne tombe jamais en panne, mais cela donne aussi souvent des réponses incorrectes. Enfin, un système d'analyse de données fonctionne-t-il "correctement" si une variation de 0,2% de l'entrée donne une réponse différente de 3 400%? Peut-être ... mais cela va sembler un modèle plutôt capricieux et insatisfaisant pour beaucoup. Je ne passerai pas en revue la liste étendue des attributs, mais l'intégrité des données, la sécurité des données, la confidentialité des données et d'autres problèmes d'exactitude et de sécurité sont des préoccupations courantes. (Si vous êtes une très grande organisation ou une agence gouvernementale, vous vous inquiétez de plus en plus de préserver ces attributs non seulement sur quelques années ou cycles de produits, mais sur des décennies, voire des siècles. Il n'y a pas encore d'architectures, de processus ou d'approches éprouvés pour y parvenir.)
Ces écarts possibles entre «en marche» et «faire ce que nous voulons» - et comment spécifier, mesurer et empêcher de tels écarts - ont longtemps été un défi, même une fois que la redondance, le durcissement et d'autres étapes vers la panne - la tolérance a été prise. Et dans un usage informel, «courir» et diverses formes de «courir comme je le veux» sont confondus, sans toutes les distinctions claires que l'on voudrait.
la source