失败是必然的，所以要接受它：理解软件中的故障安全和快速失败策略

软件系统中的故障是不可避免的。如何处理这些故障会严重影响系统性能、可靠性和业务的底线。在这篇文章中，我想讨论失败的好处。为什么你应该寻求失败，为什么失败是好事，为什么避免失败会降低应用程序的可靠性。我们将从快速失败与故障安全的讨论开始；这将带我们进入关于一般故障的第二次讨论。

附注：如果你喜欢这篇文章和本系列的其他文章，请查看我的调试书，涵盖了这个主题。如果你有朋友正在学习编码，我将非常感激你参考我的Java 基础书籍。如果你过一段时间想回到 Java，可以看看我的Java 8 至 21 书。

快速失败

快速故障系统旨在在遇到意外情况时立即停止运行。这种立即故障有助于尽早发现错误，使调试更加简单。

快速失败方法可确保立即捕获错误。例如，在编程语言领域，Java 通过在遇到null值时立即生成NullPointerException 、停止系统并清除错误来体现这种方法。这种即时响应可帮助开发人员快速识别和解决问题，防止问题变得更加严重。

通过尽早发现并阻止错误，快速故障系统可以降低连锁故障的风险，即一个错误会导致其他错误。这样可以更轻松地在问题蔓延到整个系统之前控制和解决问题，从而保持整体稳定性。

为快速失败系统编写单元测试和集成测试很容易。当我们需要了解测试失败的原因时，这种优势就更加明显。快速失败系统通常会直接指出错误堆栈跟踪中的问题。

然而，快速失败系统也有其自身的风险，特别是在生产环境中：

• 生产中断：如果生产过程中出现错误，可能会立即造成严重的中断，可能影响系统性能和业务运营。
• 风险偏好：快速失败系统需要工程师和高管都具备一定的风险承受能力。他们需要做好快速处理和解决故障的准备，通常要平衡风险承受能力与潜在业务影响。

故障安全

故障安全系统采用不同的方法，旨在即使在意外情况下也能恢复并继续运行。这使得它们特别适合不确定或不稳定的环境。

微服务是故障安全系统的典型示例，通过其架构实现弹性。断路器（无论是物理断路器还是软件断路器）可断开故障功能以防止连锁故障，从而帮助系统继续运行。

故障安全系统可确保系统即使在恶劣的生产环境中也能生存，从而降低发生灾难性故障的风险。这使得它们特别适合关键任务应用，例如硬件设备或航空航天系统，在这些应用中，顺利从错误中恢复至关重要。

然而，故障安全系统也有缺点：

• 隐藏错误：通过尝试从错误中恢复，故障安全系统可能会延迟问题的检测，使其更难追踪，并可能导致更严重的级联故障。
• 调试挑战：错误的延迟性质会使调试复杂化，需要花费更多的时间和精力来查找和解决问题。

在快速失败和安全失败之间做出选择

很难确定哪种方法更好，因为两种方法各有优点。快速故障系统可立即调试，降低连锁故障风险，并更快地检测和解决错误。这有助于尽早发现和解决问题，防止问题蔓延。

故障安全系统能够妥善处理错误，使其更适合关键任务系统和不稳定环境，因为在这些环境中，灾难性的故障可能会造成毁灭性的后果。

平衡两者

为了充分利用每种方法的优势，采取一种平衡的策略是有效的：

• 本地服务的快速失败：调用数据库等本地服务时，快速失败可尽早发现错误，防止级联故障。
• 远程资源的故障安全：当依赖远程资源（例如外部 Web 服务）时，故障安全可以防止因外部故障造成的中断。

平衡的方法还需要在编码、审查、工具和测试过程中清晰一致地实施，确保无缝集成。快速失败可以与编排和可观察性很好地集成。实际上，这将故障安全方面转移到 OPS 的不同层，而不是开发人员层。

一致的图层行为

这就是事情变得有趣的地方。这不是在故障安全和快速故障之间做出选择的问题。而是为它们选择正确的层。例如，如果使用故障安全方法在深层处理错误，则不会注意到它。这可能没问题，但如果该错误产生不利影响（性能、垃圾数据、损坏、安全性等），那么我们以后就会遇到问题，而我们却一无所知。

正确的解决方案是将所有错误处理在一个层中，在现代系统中，最顶层是 OPS 层，这是最有意义的。它可以将错误报告给最有资格处理错误的工程师。但他们也可以提供即时缓解措施，例如重新启动服务、分配额外资源或恢复版本。

重试并非万无一失

最近，我参加了一场讲座，演讲者列出了他们更新的云架构。他们选择使用允许他们在发生故障时重试的框架来走微服务的捷径。不幸的是，故障并不像我们想要的那样。你不能仅通过测试就完全消除它。重试并不是万无一失的。事实上，它可能意味着灾难。

他们测试了他们的系统，并且“它工作正常”，即使在生产中也是如此。但假设确实发生了灾难性情况，他们的重试机制可能会对他们自己的服务器发起拒绝服务攻击。像这样的临时架构可能失败的方式数量令人难以置信。

当我们重新定义失败时，这一点尤其重要。

重新定义失败

软件系统中的故障不仅仅是崩溃。崩溃可以看作是一种简单而直接的故障，但还有更复杂的问题需要考虑。事实上，容器时代的崩溃可能是最好的故障。系统可以无缝重启，几乎没有中断。

数据损坏

数据损坏比崩溃更为严重和隐蔽。它会带来长期后果。损坏的数据可能导致难以修复的安全性和可靠性问题，需要大量返工，并且可能无法恢复数据。

云计算催生了防御性编程技术，如断路器和重试，强调全面测试和日志记录，以便从容地捕获和处理故障。在某种程度上，这种环境让我们的质量倒退了一步。

数据级别的快速故障系统可以阻止这种情况发生。解决错误不仅仅是简单的修复。它需要了解其根本原因并防止再次发生，延伸到全面的日志记录、测试和流程改进。这确保错误得到充分解决，从而降低其再次发生的可能性。

不要修复 Bug

如果这是生产中的错误，那么如果您无法立即恢复生产，则可能应该恢复。这应该始终是可能的，如果不可能，那么您应该努力解决。

在进行修复之前，必须充分了解故障。在我自己的公司中，我经常因为压力而跳过这一步，在小型初创公司中，这是可以原谅的。在大公司中，我们需要了解根本原因。汇报错误和生产问题的文化至关重要。修复还应包括流程缓解，以防止类似问题进入生产。

调试失败

快速失败系统更容易调试。它们本质上具有更简单的架构，并且更容易在特定领域中找出问题。即使是轻微的违规行为（例如验证），也必须抛出异常。这可以防止在松散系统中普遍存在的级联类型的错误。

单元测试应进一步加强这一点，以验证我们定义的限制并验证是否抛出了正确的异常。应避免在代码中使用重试，因为它们会使调试异常困难，而重试的正确位置应在 OPS 层。为了进一步促进这一点，默认情况下超时应该很短。

避免连锁故障

故障不是我们可以避免、预测或完全测试的。我们唯一能做的就是在故障发生时减轻打击。通常，这种“减轻”是通过使用长期运行的测试来实现的，这些测试旨在尽可能地复制极端条件，目的是找到应用程序的弱点。但这很少足够。强大的系统通常需要根据实际生产故障修改这些测试。

故障保护的一个很好的例子是 REST 响应的缓存，它让我们即使服务中断也能继续工作。不幸的是，这可能会导致复杂的小问题，例如缓存中毒或被禁用户由于缓存而仍可访问的情况。

混合动力生产

故障安全最好只应用于生产/预发布和 OPS 层。这减少了生产和开发之间的变更量，我们希望它们尽可能相似，但这仍然是一个可能对生产产生负面影响的变更。然而，好处是巨大的，因为可观察性可以清楚地了解系统故障。

此处的讨论受我最近构建可观察云架构的经验影响。但是，同样的原则适用于任何类型的软件，无论是嵌入式软件还是云软件。在这种情况下，我们经常选择在代码中实现故障安全，在这种情况下，我建议在特定层中一致且有意识地实现它。

还有一种特殊情况，即库/框架经常提供不一致且记录不良的行为。我自己在某些工作中也犯过这种不一致的情况。这是一个很容易犯的错误。

最后的话

这是我关于调试理论系列的最后一篇文章，该系列是我关于调试的书/课程的一部分。我们经常认为调试是当出现故障时采取的措施。但事实并非如此。调试从我们编写第一行代码的那一刻就开始了。我们在编写代码时做出的决定将影响调试过程，通常我们只是在遇到故障之前才意识到这些决定。

我希望这篇文章和系列文章能帮助您编写出为未知做好准备的代码。调试本质上是处理意外情况的。测试无济于事。但正如我在之前的文章中所述，我们可以采取许多简单的做法来让准备工作变得更容易。这不是一个一次性的过程，而是一个迭代过程，需要在遇到失败时重新评估所做的决定。