Systeme / Programme / verteilte Algorithmen / ... werden häufig mit dem Prädikat robust oder fehlertolerant beschrieben .
Was ist der Unterschied?
Einzelheiten:
Wenn ich nach + robust + "fehlertolerant" google, erhalte ich nur zwei Treffer, die beide nicht hilfreich sind.
Wenn ich für die Begriffe googlescholar bin, finde ich viele Papiere, die beide Begriffe in ihrem Titel haben. Leider definieren sie die Begriffe nicht genau :( Aber da sie beide Begriffe verwenden, scheint keiner den anderen zu implizieren.
Antworten:
Beide beschreiben die Konsistenz des Verhaltens einer Anwendung, aber "Robustheit" beschreibt die Reaktion einer Anwendung auf ihre Eingabe , während "Fehlertoleranz" die Reaktion einer Anwendung auf ihre Umgebung beschreibt .
Eine App ist robust, wenn sie mit inkonsistenten Daten konsistent arbeiten kann. Beispiel: Eine Kartenanwendung ist robust, wenn sie Adressen in verschiedenen Formaten mit verschiedenen Rechtschreibfehlern analysieren und einen nützlichen Ort zurückgeben kann. Ein Musik-Player ist robust, wenn er eine MP3-Datei nach einem fehlerhaften Frame weiter decodieren kann. Ein Bildeditor ist robust, wenn er ein Bild mit eingebetteten EXIF-Metadaten ändern kann, die er möglicherweise nicht erkennt. Dies gilt insbesondere dann, wenn das Bild geändert werden kann, ohne die EXIF-Daten zu beschädigen.
Eine App ist fehlertolerant, wenn sie in einer inkonsistenten Umgebung konsistent funktionieren kann. Eine Datenbankanwendung ist fehlertolerant, wenn sie auf einen alternativen Shard zugreifen kann, wenn der primäre nicht verfügbar ist. Eine Webanwendung ist fehlertolerant, wenn sie weiterhin Anforderungen aus dem Cache verarbeiten kann, auch wenn ein API-Host nicht erreichbar ist. Ein Speichersubsystem ist fehlertolerant, wenn es aus der Parität berechnete Ergebnisse zurückgeben kann, wenn ein Plattenmitglied offline ist.
In beiden Fällen wird erwartet, dass die Anwendung stabil bleibt, sich einheitlich verhält, die Datenintegrität beibehält und nützliche Ergebnisse liefert, selbst wenn ein Fehler auftritt. Bei der Bewertung der Robustheit können jedoch Datenkriterien und bei der Bewertung der Fehlertoleranz Verfügbarkeitskriterien auftreten.
Eins muss nicht zum anderen führen. Eine mobile Spracherkennungs-App kann sehr robust sein und eine unheimliche Fähigkeit bieten, Sprache in einer Vielzahl regionaler Akzente mit enormen Hintergrundgeräuschen einheitlich zu erkennen. Aber wenn es ohne eine schnelle zellulare Datenverbindung nutzlos ist, ist es nicht sehr fehlertolerant. Ebenso kann eine Web Publishing-Anwendung äußerst fehlertolerant sein, mit mehreren Redundanzen auf jeder Ebene, und ganze Rechenzentren verlieren, ohne dass dies fehlschlägt. Wenn jedoch eine Benutzertabelle gelöscht wird und bei der ersten Registrierung mit einem Apostroph im Nachnamen ein Absturz auftritt Es ist überhaupt nicht robust.
Wenn Sie nach wissenschaftlicher Literatur suchen, um die Unterscheidung zu beschreiben, suchen Sie möglicherweise in bestimmten Bereichen, in denen Software verwendet wird, und nicht allgemein nach Software. Die Forschung zu verteilten Anwendungen könnte ein fruchtbarer Grund für Fehlertoleranzkriterien sein, und Google hat einige relevante Forschungsergebnisse veröffentlicht. Datenmodellierungsforschung befasst sich wahrscheinlich mit Fragen der Robustheit, da Wissenschaftler besonders an den Eigenschaften der Robustheit interessiert sind, die reproduzierbare Ergebnisse liefern. Möglicherweise finden Sie Artikel, die statistische Anwendungen beschreiben, die hilfreich sein könnten, z. B. bei der Klimamodellierung, der RF-Ausbreitungsmodellierung oder der Genomsequenzierung. Dort finden Sie auch Ingenieure, die über "robustes Design" in Sachen Steuerungssysteme diskutieren.
Das Whitepaper zum Google-Dateisystem beschreibt die Vorgehensweise bei Fehlertoleranzproblemen, bei der im Allgemeinen davon ausgegangen wird, dass Komponentenfehler Routine sind und die Anwendung sich daher an sie anpassen muss:
Dieses Projekt für eine Klasse bei Rutgers unterstützt eine "Komponentenfehler" -orientierte Definition von "Fehlertoleranz":
Abhängig von dem von Ihnen untersuchten Gebiet gibt es jede Menge Artikel zum Thema "Robustes Modellieren XYZ". Die meisten beschreiben ihre Kriterien für "robust" in der Zusammenfassung, und Sie werden feststellen, dass alles damit zusammenhängt, wie das Modell mit Eingaben umgeht.
Dieser Bericht eines NASA-Klimaforschers beschreibt Robustheit als Kriterium für die Bewertung von Klimamodellen:
Dieser Artikel eines MIT-Forschers untersucht drahtlose Protokollanwendungen, eine Domäne, in der sich Fehlertoleranz und Robustheit überschneiden. Die Autoren verwenden jedoch "robust", um Anwendungen, Protokolle und Algorithmen zu beschreiben, während sie "Fehlertoleranz" in Bezug auf die Topologie verwenden und Komponenten:
quelle
Ich mag die Antwort von @ johnnyb sehr und unterstütze sie für ihre klaren Definitionen. Nachdem ich einige Jahrzehnte auf diesem Gebiet gearbeitet habe, erkenne ich eine andere (viel weniger formale und präzise) Art und Weise, wie diese Begriffe häufig verwendet werden:
Als informelle Punkte entlang eines Kontinuums von "unzuverlässig" bis "absolut zuverlässig".
Es gibt kein System, keine Anwendung oder keinen Dienst, der garantiert, dass es immer und für immer verfügbar ist ("ständig verfügbar" oder "ständig verfügbar"). "Fehlertolerant" ist seit langem ein Ersatz für "Wir haben mit der aktuellen Technologie alles Menschenmögliche getan, um sicherzustellen, dass dieses Ding weiterhin ordnungsgemäß funktioniert."
Wörter wie "robust", "gehärtet" und "hochverfügbar" werden als weichere Meilensteine für dieses Ziel des kontinuierlichen Betriebs verwendet. Sie spiegeln den zunehmenden Aufwand, die Investitionen und das Vertrauen wider.
Da diese Begriffe informell verwendet werden, gibt es keine vollständig kanonische Reihenfolge. "Hochverfügbar" ist normalerweise eine starke Behauptung, nur unter "ausfallsicher" oder "fehlertolerant". Aber ist "gehärtet" besser als "robust"? Oder umgekehrt? Es kommt auf den Kontext an. Diese werden auch häufig als Produktmarketingansprüche verwendet, mit allen damit verbundenen Prahlereien und absichtlichen Ungenauigkeiten.
In der Regel haben Organisationen, die auf diese Ziele hinarbeiten, einen eigenen intern vereinbarten Fortschritt, der zumindest grob mit den Projektzielen / -ergebnissen und externen Metriken wie "Drei Neunen" oder "Sechs Neunen" verknüpft ist .
@johnnyb berührt auch eine kritische Unterscheidung: Der Unterschied zwischen dem Status der Plattform (Verfügbarkeit) auf der einen Seite und den Attributen von Algorithmen, Anwendungen oder Diensten auf der anderen Seite.
Ich sage "Attribute", weil es viele gibt: Leistung, Korrektheit und Unerschütterlichkeit sind nur einige Schlüssel. Ist ein System sinnvoll verfügbar und korrekt, wenn es nur mit 10% der Nennleistung betrieben wird? Nicht laut Geschäftsinhabern, wenn es die arbeitsreiche Jahreszeit ist! Es gibt keine große Tugend in einem System, das wirklich nie zusammenbricht, das jedoch häufig auch falsche Antworten liefert. Läuft schließlich ein Datenanalysesystem "richtig", wenn eine Abweichung von 0,2% bei der Eingabe eine zu 3.400% unterschiedliche Antwort ergibt? Vielleicht ... aber es wird vielen ein ziemlich launisches und unbefriedigendes Modell erscheinen. Ich werde die erweiterte Liste der Attribute nicht durchgehen, aber Datenintegrität, Datensicherheit, Datenschutz und andere Fragen der Korrektheit und Sicherheit sind häufige Probleme. (Wenn Sie eine sehr große Organisation oder Regierungsbehörde sind, Sie sorgen sich zunehmend darum, diese Attribute nicht nur über einige Jahre oder Produktzyklen, sondern über Jahrzehnte oder möglicherweise sogar Jahrhunderte hinweg zu bewahren. Es gibt noch keine bewährten Architekturen, Prozesse oder Ansätze, um dies zu erreichen.)
Diese möglichen Abweichungen zwischen "in Betrieb" und "tun, was wir wollen" - und wie solche Abweichungen spezifiziert, gemessen und verhindert werden - waren lange Zeit eine Herausforderung, selbst wenn Redundanz, Härten und andere Schritte in Richtung Fehlerursache Toleranz genommen wurden. Und im informellen Sprachgebrauch verschmelzen "Laufen" und verschiedene Formen von "Laufen, wie ich es möchte", ohne alle klaren Unterscheidungen, die man sich wünschen würde.
quelle