Mark Doss：高风险交易中的生产工程

我是 Mark Doss。在 Jane Street 近十年的时间里，我大部分时候从事的是我们现在称为生产工程的工作。我想讲讲在交易环境中运行软件时会遇到哪些挑战，尤其是出问题的时候。

生产工程与 SRE 和 DevOps 有重叠。我们的软件运行在会发生故障的计算机上，数据中心可能出现制冷问题，网络电缆可能被切断，交易所也会有自己的问题。我们还会部署包含缺陷的软件。问题在于，如何从技术和运营两方面管理这一切。

一个简单的交易模型从人工或自动化策略接收市场数据开始：交易所提供最近的订单和成交信息。策略决定采取什么行动，再通过连接交易所的订单录入端口，也就是订单引擎，发送订单。交易所会确认或拒绝订单，并报告成交情况。

成交后，公司必须跟踪持仓，并把这些信息反馈给策略。公司还要向监管机构、清算公司和其他各方报告交易。一笔简单订单包含买卖方向、数量、交易品种、价格和货币，但真实订单的约定可能复杂得多。

这个环境的第一个重要特点是每笔订单都重要。在普通网络服务中，一次请求缓慢或失败可能只是带来不便；在交易中，即使只有一笔订单的方向、数量、品种或价格出错，也可能造成灾难性后果。

假设把数量和价格颠倒：本来要以大约 61 万日元卖出一股，却提交了一笔以 1 日元卖出 61 万股的订单。这并非纯粹的假设。2005 年，Mizuho 的一位交易员就犯了这样的错误，而交易所没有接受撤单。Doss 说，公司损失了 270 亿日元，通过诉讼只追回了所要求损失的一部分。

合规也很重要。监管机构可能要求报告每一笔订单；即使成功率达到 99.99%，仍可能遗漏数千份报告。自动化交易尤其令人紧张，因为能动用资金的软件会在紧密循环中运行，小错误重复许多次就可能变成大问题。

逆向选择让错误更加危险：只要你提供了一笔对自己不利的交易，其他市场参与者就有动力迅速与你成交。Knight Capital 在 2012 年的事件说明，技术故障有多快可能威胁一家公司的生存。

Knight 有一段旧代码，如果收到某个配置标志就会亏钱，但这个标志此前没有被使用。公司重新利用该标志实现新功能，并开始发送它。八个实例中有七个升级成功，一个失败，而失败通知邮件被忽略了。

开盘后开始亏损，工程师确定了出问题的系统，并以为是新部署造成的，于是执行回滚。实际上问题来自没有升级的实例，因此回滚其他实例反而加快了亏损。Doss 说，公司在 45 分钟内损失了约 5 亿美元；其中的细节值得单独做一次完整复盘。

下一个特点是时机。交易量在开盘和收盘时会大幅攀升，美联储公告等预定事件也可能非常重要。突发新闻同样会推动波动。同一个故障在不同时间发生，影响可能截然不同。

外部依赖也遵循时间表。公司可能在早上 7:30 下载元数据，将它加载到一个系统，再加载到另一个系统，同时处理其他数据源。开盘前可能只有几个小时准备好一切，因此任何延迟都可能迫使大家紧急处理。

我们的用户大多在公司内部。这使沟通格外直接、高效：工程师可以准确说明哪里出了问题，交易员也可以不受外部客户关系的约束，描述实际影响。这改变了我们应对故障的方式。

考虑一种传统 SLO 告警：错误率超过 0.01% 时触发。我们在实时交易系统中较少使用这类告警。如果你无法撤销的那一笔订单会让公司破产，整体成功率就没有多少安慰作用。每笔订单的每一个经济细节都很重要。

相反，我们高度依赖基于事件的监控。代码运行到某个位置时，特定条件可以触发错误，让人来调查。这迫使我们列举边界情况，明确决定每种情况是否需要告警、安全失败，还是采用其他处理方式。

这种方式的好处是具体：告警可以指向准确的代码路径，并提供详细背景。代价是需要投入大量工程工作。遗漏边界情况可能产生噪声和只掌握在少数人手中的经验；修改告警也可能需要理解并修改底层逻辑，而不只是调整 SLO 阈值。

我们仍然使用基于指标的告警，尤其是在没有直接风险的场景，以及衡量系统长期健康状况时。但对许多系统来说，我们更倾向于针对症状告警，而不是针对推测的原因。以一个连接数据库的 Web 应用为例：数据库停机似乎是显而易见的告警对象。

但你还需要检测用户遇到的 HTTP 500 错误，因为数据库停机并不是唯一可能的原因。两者都告警会产生重复信息。随着时间推移，“数据库停机必然影响用户”这一假设也可能不再成立：故障切换或维护可能让停机没有影响，而不断为例外静音只会层层打补丁。

用户关心的是失败的请求，而不是孤立的数据库状态。为了方便调试，可以把数据库状态附在症状告警中，或放在仪表盘上。这样既保留了有用的诊断信息，又不会因为例行维护叫醒值班人员。

我们最喜欢的一些告警关注我所谓的“认知健康”：它们不指出哪项服务坏了，而是告诉我们对世界的认识出现了矛盾。“成交好得令人怀疑”告警意味着一笔交易看起来赚了太多钱。

这个信号可以发现市场数据问题、错误的品种定义、订单引擎故障、策略缺陷或人为错误。另一个例子是我们的交易量通常占市场的 3%，却突然占到 60%。即使还不知道问题在哪里，异常结果也提示可能出了问题。

告警还需要有人接收。如果“成交好得令人怀疑”可能意味着技术栈任何位置出现故障，应该由哪个团队接收？这没有普遍正确的答案，但这个问题很重要，因为必须有人能够调查并采取行动。

我们还非常重视信噪比。交易员、开发人员和生产工程师都需要明白，充满噪声的告警比没有用更糟糕。人的注意力有限，因此我们会花时间调整逻辑、阈值和边界情况；事件告警依赖这种共同的文化习惯。

纵深防御应对的是任何单一告警或检查都可能出错的情况。交易系统、订单录入端口和外部风险执行系统可以运行由不同团队开发的相关检查。我们尽量避免共享过多实现或元数据，降低故障相关联的可能性。

共同依赖是这种方式的弱点，需要仔细检查；有时也需要独立版本。技术人员监控软件、硬件和连接状况，交易员则监控市场影响、盈亏，以及是否发出了预期订单。任一视角都可能发现另一方遗漏的问题。

监控对我们不是可选项。一般来说，没有监控我们就不交易，因此监控系统是我们最可靠、测试最充分、冗余程度最高的系统之一，还配有故障切换机制。我们宁可交易系统停机，也不愿失去监控它的能力。

业务背景对技术响应人员至关重要，交易员也需要技术背景。只有双方能够互相理解，直接沟通才有帮助。了解业务语言，可以让我们在故障中省去一连串查询。

例如，交易员说“Spoos 市场数据看起来过期了”，了解标普 500 期货及其交易地点的工程师，几秒钟就能找到相关数据源。不了解这一背景的人，则需要先弄明白术语，再查找交易所，并将其对应到正确的系统。

工程师还需要知道哪些预定或突发事件对交易台重要。突然发布的政策可能解释异常的市场数据，而在重要经济消息发布前立刻部署系统可能是个糟糕的决定。背景知识会同时影响诊断和风险决策。

下面的示例事件是根据几起事件综合而成的，并不是对单一事件的逐字记录。早上 7:15，一个订单引擎完成例行升级，包含缺陷修复和一次小规模价格序列化重构；测试全部通过。

9:31，交易员收到多个品种各自的“成交好得令人怀疑”告警。9:32，订单引擎团队收到汇总告警，引擎自动停止。单笔告警可以发给受影响的交易策略，而更广泛的告警则交给负责交易所前最后一道安全关卡的团队。

9:33，团队启动故障处理，并使用“发生了什么变化”工具检查代码、配置和元数据的变更。价格序列化重构看起来很可疑。不到一分钟，响应人员发现这个变更也部署到了其他没有告警的订单引擎上。

如果告警完全可靠，那么重构可能只是误导性的线索，或者它只影响某一种协议。如果告警并不完美，其他引擎也可能正在亏损，只是尚未发现。团队需要在不确定性和风险之间权衡，讨论是否预先停止其他引擎。

随后交易员加入电话会议，报告市场数据看起来过期了：本应每秒或更快更新的价格没有变化。调查因此从价格序列化转向其他方向。市场数据团队加入后确认，部分品种自前一日收盘以来就没有更新，却没有被标记为过期。

搜索发现，交易所两周前宣布要拆分数据源：把部分品种从原有的四个分区移到第五个分区。公司遗漏了这一变更，没有读取新分区；仍关联到旧分区的品种，虽然数据已经过期，却可能因为旧分区本身是最新的而显示为实时数据。

市场数据团队建议继续停止受影响的引擎，并部署配置变更。变更后交易恢复，“成交好得令人怀疑”告警也停止了。进一步调查发现有两个故障：一是遗漏了交易所驱动的变更，二是用于将迁移品种标记为过期的代码存在缺陷，这条代码路径此前从未执行过。

订单引擎告警在不知道原因的情况下发现了市场数据问题。其他独立信号也可能发现问题，例如一笔成交没有出现在市场数据源中。这说明针对结果的告警为什么能够防范许多不同的故障。

时间线也说明了时机的重要性。尽管响应人员在几分钟内采取了行动，开盘时刻已经错过。复盘应当追问，盘前交易或其他检查能否提前 20 分钟暴露问题。美联储会议纪要等预定事件也会影响紧迫程度和风险决策。

转折点是一位交易员指出数据看起来不对。从技术角度看，系统似乎健康；业务层面的观察让正确的团队参与进来。技术和交易岗位之间清晰的沟通，能大幅提高故障处理的效率。

总结一下，我们在实时交易中使用事件告警和独立的结果告警，让监控系统尤其可靠，并实践纵深防御。技术响应人员需要业务知识。不过，我在这里强调的是差异：Jane Street 的许多生产工程工作与其他地方类似，尤其是在紧密交易循环之外。

一位观众问为什么会漏掉交易所邮件。Doss 说，交易所驱动的变更很常见，大多数不需要采取行动，因此人们必须筛选大量通知。公司使用流程和工具，包括大语言模型，来帮助提高信噪比；但有时人们读过通知后，仍会错误地判断它与自己无关。

另一个问题是，昨天的数据怎么会看起来像实时数据。Doss 说，交易场所差异很大：在通常流动性不足的交易所，某个品种没有新更新并非不合理。在启发这个例子的事件中，一个平时冷清的市场因新闻变得异常活跃，因此故障产生了严重影响。

订单引擎并没有直接识别出市场数据过期；它检测到的是一笔好得令人怀疑的交易。被问及由谁将事件告警集成到软件中时，Doss 说，团队通常负责监控自己开发的系统。工程师必须想清楚故障模式，以及收到告警的人会如何响应。

他说，这项工作成本很高，但可靠的告警也能让团队在其他方面行动更快，因为大家更有信心及时发现问题。提问者指出，深入集成事件告警很难避免产生过多噪声。

一位观众问各团队是否共享日志和告警标准，因为术语不一致会拖慢跨系统诊断。Doss 说，公司有通用库和日志级别，但自上而下的强制规定很少；具体术语和约定可能因团队而异。许多基础设施由不同交易台共享，这也带来了一定的一致性。

被问及全公司总体风险是在单一关卡同步检查，还是异步监控时，Doss 说两种方式都有。超过特定限额时，自动化系统可能停止活动；交易员则监控更广泛的全公司风险，并在较长时间范围内作出决策。

最后一个问题涉及数千条告警的级联，以及引擎停止期间订单会怎样处理。Doss 说，停止的订单引擎会拒绝交易系统发出的订单；交易系统必须决定是否重新发送。

关于告警数量激增，Doss 坦言公司也有同样的问题，而且解决得并不特别好。在组合案例中，没有任何单项服务看起来出了故障，因此结果告警没有引发服务故障的级联。下游服务确实故障时，基于症状的告警仍有价值，因为它们能指出受影响的用户，以及需要如何改变行为。