策略 | Optiver的软件可靠性

软件生态系统不同部分的错误对公司暴露于自动化风险的程度差异很大。例如，自动交易系统订单管理逻辑中的错误比桌面工具中向交易者显示市场成交数据的错误更危险。因此，我们明确承认我们的系统中存在各种各样的错误偏好。这意味着我们不需要采用相同的策略来确保所有软件组件的软件可靠性。

明确地说，承认对某些错误的容忍并不意味着我们会放任草率的软件开发。相反，它允许技术领导者适当地将时间和资源集中在确保最关键的软件组件的可靠性上。此外，它并不意味着其余软件系统完全不存在可靠性问题：它只是促进采用不同的实践，更好地实现快速创新和正确性之间的正确平衡。

特别是考虑到监管机构制定的新规则和指导方针，软件测试正受到广泛关注。我们承认测试的重要性，但我们坚定地认为它只是对软件可靠性问题的众多攻击角度之一。明确地说，构建可靠和健壮的软件一直是业界的挑战。迄今为止，还没有任何已知的方法能对正确性提供可靠的保证。特别是，由于有大量失败的项目，其中一些非常突出，软件测试方法不能声称是一致成功的。简而言之，软件可靠性并不是一个可以解决的问题：工业界和学术界仍在努力解决这个问题。

然而，我们承认现代的最佳实践是可行的，我们总是试图用它们来指导我们自己的思考。我们强调这种思维的连续性：最佳实践不断发展，我们的质量保证方法和具体测试方法将相应地发生变化。

这些原则的一个很好的例子来自我们的自动化交易系统（ATS）工程团队。几年前，我们正在发布一些新的交易应用程序。我们连续发布了几个版本，在我们的风险检查代码中有一些小错误。

我们的风险检查代码是系统中最关键的组件之一。这个系统的这一部分中的错误被认为是非常严重的，并且这一系列的事件非常令人担忧。

为了解决这个问题，我们采取了非常激进的方法：

对于每个交易策略，ATS工程师都创建了一个与风险检查相关的所有功能的列表。然后，我们的技术运营团队对该列表进行了审查，以确保它涵盖了他们预期的领域。

对于每一个版本，不管它有多小或多么微不足道，ATS工程师都会测试这个列表中的功能。

测试需要“端到端”的二进制文件的生产就绪版本。使用存根代码“模拟”应用程序功能的单元测试或测试是不够的。

每一个版本都将包含一个声明，声明已经执行了该测试。

技术操作团队检查了声明，以确保在每次发布之前完成测试。

除了预发布测试之外，我们的技术运营团队还将在生产中进行与风险相关的功能“消防演习”，以了解其在现实世界中的工作情况。他们定期这样做，尤其是当我们的系统发生重大功能变化时。这给了我们更多的保证，我们的风险检查限额系统的功能继续按预期运行。

最后，每年Optiver办公室都会进行“同行评估”，其中一组工程师会前往每个Optiver办公地点，对该办公地点的风险程序的选定方面进行深入分析。

正如您所看到的，围绕风险限制，软件测试只是广泛的、公司范围的、可靠性策略的一部分。

然而，我们对软件可靠性的方法在其他领域（如用户界面）是完全不同的。因为在这些系统中几乎没有自动化交易风险，所以我们的策略更容易接受错误，并且减少了对全面性的需求。我们仍然坚持我们的总体开发原则，并实践各种各样的规程，如TDD、代码评审和测试版测试。但是，这些系统中出错的主要风险是生产力的损失，因此可靠性策略可能不那么全面。