鲁棒性和容错能力有什么区别？

系统/程序/分布式算法/ ...通常以谓词鲁棒或容错来描述。

有什么区别？

细节：

当我用Google搜索+健壮的+“容错”功能时，我只有两次点击，都无济于事。

当我用谷歌搜索术语时，我发现很多论文的标题中都有两个术语。不幸的是，它们并没有精确地定义术语：(但是由于它们同时使用了这两个术语，因此似乎没有一个暗示另一个。

两者都描述了应用程序行为的一致性，但是“健壮性”描述了应用程序对其输入的响应，而“容错”描述了应用程序对其环境的响应。

当应用程序可以与不一致的数据一致地工作时，它是健壮的。例如：当一个地图应用程序可以解析具有各种拼写错误的各种格式的地址并返回一个有用的位置时，它是健壮的。当音乐播放器在遇到格式错误的帧后可以继续解码MP3时，它是健壮的。当图像编辑器可以使用可能无法识别的嵌入式EXIF元数据修改图像时，它是健壮的，尤其是如果它可以在不破坏EXIF数据的情况下对图像进行更改时。

当应用程序可以在不一致的环境中一致地运行时，它就是容错的。当数据库应用程序在主数据库不可用时可以访问备用分片时，它是容错的。当Web应用程序可以继续处理来自缓存的请求时，即使API主机不可访问，它也是容错的。当磁盘成员脱机时，存储子系统可以返回根据奇偶校验计算的结果时，该存储子系统是容错的。

在这两种情况下，即使遇到错误，应用程序也有望保持稳定，行为统一，保持数据完整性并提供有用的结果。但是，在评估健壮性时，您可能会发现涉及数据的标准，而在评估容错性时，您会发现涉及正常运行时间的标准。

一个不一定会导致另一个。移动语音识别应用程序可能非常强大，具有不可思议的能力，能够以各种背景重音始终如一地识别语音，并带有大量的背景噪音。但是，如果没有快速的蜂窝数据连接就没有用，那就不是很容错了。同样，Web发布应用程序可以具有极大的容错能力，每个级别都有多个冗余，能够在不失败的情况下丢失整个数据中心，但是如果它删除了用户表并在某人第一次使用姓氏撇号进行注册时崩溃了，它一点也不健壮。

如果您正在寻找有助于描述这一区别的学术文献，那么您可能会寻找使用软件的特定领域，而不是一般的软件。分布式应用程序研究可能是容错标准的沃土，并且Google已发布了一些可能相关的研究。数据建模研究可能会解决鲁棒性问题，因为科学家对产生可再现结果的鲁棒性属性特别感兴趣。您可能会发现描述统计应用的论文，例如气候模型，RF传播模型或基因组测序，它们可能会有所帮助。您还会发现工程师在控制系统等方面讨论“稳健设计”。

Google文件系统白皮书描述了其解决容错问题的方法，该方法通常包含以下假设：组件故障是常规故障，因此应用程序必须适应这些故障：

• http://static.googleusercontent.com/media/research.google.com/en/us/archive/gfs-sosp2003.pdf（“我们的系统通过不断监控，复制关键数据以及快速自动恢复来提供容错能力。 ”）

罗格斯大学一个班级的这个项目支持面向“组件故障”的“容错”定义：

• http://www.ece.rutgers.edu/~parashar/Classes/03-04/ece572/papers/cristian93understanding.pdf（“某些系统设计为容错的：当出现以下情况时，它们要么表现出明确的故障行为组件故障或向用户掩盖组件故障…“）

有关“稳健建模XYZ”的论文很多，具体取决于您研究的领域。大多数人会在摘要中描述其“健壮”的标准，并且您会发现这与模型如何处理输入有关。

美国宇航局气候科学家的这份简介将稳健性作为评估气候模型的标准：

• http://www.giss.nasa.gov/research/briefs/schmidt_04/（“……稳健，因为它在很大程度上不依赖于参数化和空间表示的细节。”）

麻省理工学院研究人员的这篇论文研究了无线协议应用程序，容错和鲁棒性重叠的领域，但是作者使用“健壮”来描述应用程序，协议和算法，而他们使用“容错”来描述拓扑和组件：

• http://people.csail.mit.edu/grishac/papers/allerton.pdf（简而言之，这些用途需要即使在不可预测的条件下也始终能够正确运行的强大应用程序。）

我非常喜欢@johnnyb的答案，并对其清晰的定义表示赞同。但是，在该领域工作了几十年之后，我认识到了这些术语经常使用的另一种（远不那么正式和精确）的方式：

作为从“不可靠”到“完全可靠”的连续体的非正式要点。

没有任何系统，应用程序或服务可以保证它将永远永远工作（“连续可用”或“永久可用”）。长期以来，“容错”一直是“我们已经使用当前技术完成了人类可能做的一切，以确保此功能正常运行”的代名词。

诸如“健壮”，“硬化”和“高度可用”之类的词被用作朝着实现连续运行目标的较柔和的里程碑。它们反映出不断增加的努力，投资和信心。

因为这些术语是非正式使用的，所以没有完全规范的顺序。通常，“高度可用”是强烈要求的，仅在“容错”或“容错”之下。但是，“强化”胜于“健壮”吗？或相反亦然？这取决于上下文。这些还经常用作产品营销声明，并附带所有吹嘘和故意的不精确性。

通常，为实现这些目标而努力的组织具有自己内部认可的进度，通常至少与项目目标/可交付成果和外部指标（例如“三个九”或“六个九”）大致相关。

@johnnyb还涉及一个关键的区别：一方面是平台的启动/关闭状态（可用性），另一方面是算法，应用程序或服务属性之间的差异。

我之所以说“属性”，是因为有许多属性：性能，正确性和不可干扰性只是几个关键属性。如果系统仅以额定性能的10％运行，是否有意义且可用且正确？如果这是繁忙的季节，则不适合企业主！真正永不崩溃的系统并没有很大的优点，但是在大多数情况下，它还会给出错误的答案。最后，如果输入的0.2％变化给出3400％的不同答案，那么数据分析系统是否运行“正确”？也许...但是，对于许多人来说，这似乎是一个反复无常且令人不满意的模型。我不会遍历属性的扩展列表，但是数据完整性，数据安全性，数据隐私以及其他正确性和安全性是常见的问题。（如果您是大型组织或政府机构，您越来越担心不仅要保留几年或产品周期，还要保留几十年甚至几个世纪的属性。尚无成熟的架构，流程或方法来实现这一目标。）

在“启动和运行”与“做我们想做的事情”之间可能存在的差异，以及如何指定，测量和防止此类差异，长期以来一直是一个挑战，即使冗余，强化和其他解决故障的步骤也是如此。已经采取了宽容的态度。在非正式的用法中，“跑步”和各种形式的“像我想要的那样跑步”被混合在一起，而没有人们想要的所有明显区别。