performance - 快速失败与稳健性

Question

我们的产品是一个分布式系统。我工作的模块是相当新的、相当严格的、经过良好测试的。它们的开发考虑了最近的最佳实践。其他模块可以被视为遗留软件。

虽然我对我负责的模块中发生的一切保持警惕，但我一直承受着处理从其他模块发送给我的不良数据的压力。从本质上讲，我是一个“快速失败”原则开发人员，因此，当出现问题时，我通常能够消除模块中出错的可能性。与其说是责备，不如说是为了避免在错误的地方追逐错误而浪费精力。

但我一直反对的论点是:“我们不能让这些东西在生产中失败，客户希望它能够工作，你为什么不解决这个问题”。这将是稳健性的一个论据:在你接受的东西上要自由，在你发送的东西上要保守。

我还应该注意，这些大多是间歇性问题。我们在集成测试中看到它们，但它们很难重现。涉及时间和并发性。

我很难在这两个原则之间取得平衡。部分原因是我担心如果我开始允许和传播异常数据，我会招来麻烦，而且我对我的系统不会有太大的信心。但是，即使其他模块向我发送了错误的数据，我也不能反对保持系统正常工作。其他模块没有得到修复的原因是它们太复杂和脆弱，而我的仍然看起来清晰和安全。但是，如果我不抗拒压力，我的模块将慢慢地背负我一直拒绝的相同问题。

我应该说系统在生产中没有“崩溃”，但我的模块可能只是向运算符(operator)显示错误并要求他们联系支持。崩溃将是一个大问题，但如果我清楚地报告错误，那么这不是正确的做法吗？我怀疑我的同行只是不希望客户看到任何问题。但是我的模块拒绝来自我们产品中其他模块的数据，而不是客户输入。所以在我看来，我们只是没有解决问题。

那么，我需要更加务实还是坚守自己的立场？

Answer 1

我分享“快速失败”的偏好/原则。不要认为这是原则上的冲突，更多的是理解上的冲突。您的对方有一些未说导出的要求(“不要向用户展示糟糕的时间”)，这意味着一些错过的要求。您没有机会事先考虑/实现此要求，因此该要求在您的嘴里留下了不好的味道。忘记这个观点，把它当作一个新项目来重新对待，你可以解决一个固定的需求。

也许最好的结果是像您显示的那样给出错误消息。但听起来你在得到对方的支持之前实现了它，当时他们可以选择接受它。关于你在做什么的早期沟通可能会解决类似的问题。

小心你如何阻止这些想法。不断提到其他系统“过于复杂和脆弱”可能会以错误的方式惹恼人们。简单地表达系统对您来说是新的，需要更长的时间才能理解。一定要花时间去理解它们，这样你就不会降低人们对你能力的期望。