简街交易公司：在日交易数十亿美元的环境中进行生产工程实践，涵盖监控、预警、深度防御及内部沟通
总结：
简街交易公司的生产工程 (PE) 团队在日交易数十亿美元的复杂且高风险环境中运作。其核心实践包括：
- 极端风险意识: 每个订单都至关重要，任何错误都可能导致巨额损失和监管罚款（例如，瑞穗证券的“胖手指”事件和骑士资本事件）。
- 时间敏感性: 交易日具有特定的高峰期和依赖外部系统的关键窗口，需要快速响应。
- 事件驱动型警报: 侧重于事件驱动型而非传统基于服务水平目标 (SLO) 的警报，以确保对每个边缘案例的响应。
- 正交认知健康警报: 部署“fill-too-good”等特殊警报，通过检测异常现象来发现技术栈中广泛的故障。
- 深度防御与关键监控: 建立多层次冗余系统和警报，并视监控系统为最关键的基础设施。
- 业务背景与内部沟通: 生产工程师需要深入理解业务，并与交易员保持高带宽沟通，以在事件中快速做出高质量决策。
关于Mark Doss [00:00:05]
Mark Doss在简街交易公司工作近10年，主要从事生产工程领域的工作。他的职责类似于DevOps或SRE，专注于确保生产基础设施的可用性、可靠性和可扩展性，尤其是在出现问题时。
介绍与演讲概要 [00:00:27]
生产工程定义 [00:01:29]
- 生产工程旨在确保生产基础设施的可用性、可靠性和操作可扩展性。
- 特别关注在出现硬件故障、数据中心中断、网络连接问题、交易所问题以及软件缺陷等情况时，如何安全有效地响应生产问题。
交易基础 [00:02:24]
- 核心系统图 [00:02:30]
- 交易系统获取市场数据（订单、买卖价格等）。
- 通过订单入口（订单引擎）向交易所发送交易指令。
- 交易完成后，需要跟踪持仓并向监管机构报告。 图示：简街交易公司的基础交易系统图，包括交易系统、订单入口、市场数据订阅、交易所及清算与持仓模块。
- 订单构成 [00:04:21]
- 一个基本订单包含：方向（买/卖）、数量（例如1股）、标的（例如J-Com Co.）、价格（数量和货币）。
- 实际订单可能更复杂，涉及乘数、报价惯例等。
生产环境的特点 [00:05:29]
1. 每个订单都至关重要 [00:05:37]
- 与大多数Web服务不同，单个客户请求的失败可能导致灾难性后果。
- 经济影响：2005年12月8日，瑞穗证券（Mizuho）一名交易员因“胖手指”错误，以1日元的价格出售了60万股J-Com股票，而非以61万日元的价格出售1股，导致公司损失270亿日元。交易所未接受取消请求，交易被执行，日本股市主要指数下跌2%。
- 合规要求：美国证券交易委员会 (SEC) 等监管机构对交易的成功率要求接近100%，即使少量报告遗漏也会导致巨额罚款。
2. 交易充满风险 [00:08:38]
- 计算机程序连接到银行账户并以紧密循环方式操作，本身就具有高风险性。
- 领域复杂性：涉及符号错误、不同协议、众多市场、复杂金融工具（报价惯例、乘数）和复杂订单类型。
- 逆向选择：一旦系统发出错误的交易指令，其他市场参与者会迅速利用这些错误，导致损失迅速扩大。
- Knight Capital事件 [00:10:07]：2012年，Knight Capital因一个未正确部署的旧代码被触发，在45分钟内损失了约5亿美元并最终被竞争对手收购，成为行业内一个重要的警示案例。
3. 时间敏感性 [00:13:50]
- 交易日模式：系统遵循交易日，在市场开盘和收盘时出现巨大的交易量高峰，中间时段交易量较低。
- 特殊交易事件：有计划的事件（如FOMC会议纪要发布）和非计划的突发新闻（如政治事件）都会导致市场波动加剧。
- 外部系统依赖：大量外部系统依赖于时间锚定事件，例如在开盘前需要完成元数据下载、持仓加载等一系列任务。任何延迟都可能导致无法在市场开盘前准备就绪。 图示：描绘了交易量在一天内的变化，显示了系统启动、市场开盘、特殊交易事件（如FOMC会议、突发新闻）、市场收盘和系统关闭时的交易量高峰及外部系统的时间依赖性。
4. 内部用户 [00:16:03]
- 简街交易公司的所有技术用户都在公司内部，这使得在系统出现问题时，技术人员与用户之间能够进行高带宽、高信任度的直接沟通。这种沟通方式有助于在不担心声誉影响的情况下，高效地诊断和解决问题。
简街交易公司生产工程的意义 [00:17:07]
监控与预警 [00:17:14]
- 基于SLO的传统监控的局限性 [00:17:17]
- 传统上，Web服务可能使用SLO（例如，请求成功率低于0.01%即报警），但这对交易系统不适用。
- 原因在于“每个订单都至关重要”，0.01%的失败可能就是导致公司破产的关键订单。
- 同样，即使99.99%的仪表元数据准确，任何一个符号错误也可能造成灾难。
- 事件驱动型监控与预警 [00:18:35]
- 核心理念：在实时交易系统中，当特定条件发生时，代码会触发人类需要审查的警报。
- 优点：强制工程师思考每一个边缘案例，提供高保真的警报细节（直接指向具体代码位置和问题），从而实现快速诊断和修复。
- 缺点：工作量大，容易产生噪音，可能导致“部落知识”（特定团队对特定警报的理解），且修改警报逻辑需要深入理解代码库。
- 基于症状而非原因的预警 [00:22:17]
- 经典SRE信条：对症状报警而非原因报警（例如，对500错误报警，而不是数据库宕机报警）。
- 理由：500错误可能有多种原因，仅对数据库宕机报警会产生重复警报，且数据库宕机有时是计划内的维护，并无用户影响。用户关心的是服务中断的症状，而非底层原因。
- 解决方案：将数据库状态等诊断元数据附加到500错误警报中，或通过监控仪表盘显示，以便快速关联，避免额外警报。
对症状而非原因进行警报的经典SRE原则 [ 00:25:51 ]
- 正交认知健康警报（Orthogonal epistemic alerts） [00:26:14]
- 警报信噪比（Signal-to-noise ratio） [00:29:41]
- 简街交易公司将警报的信噪比视为公司文化的一部分，每个人都深刻理解噪音警报比无用警报更糟糕。
- 团队投入大量时间调整警报阈值和逻辑，处理每一个边缘案例，以确保警报能够提供真正有价值的信息。
深度防御 [00:30:41]
- 多层次冗余 [00:30:49]：为防止单个警报系统失效，公司采用深度防御策略，在不同系统、由不同团队编写的冗余警报来保护关键流程。
- 例如，交易系统、订单入口和外部风险执行器都有各自的风险检查，且这些系统由不同团队开发，尽量不共享底层元数据逻辑。
- 技术健康与交易影响监控 [00:32:16]
- 技术健康监控：由技术人员负责，关注软件/硬件问题、系统执行交易决策的能力以及外部连接问题。
- 交易影响监控：由交易员负责，关注市场影响是否符合预期、盈亏情况以及发送的订单是否符合意图。
- 两者互为补充：交易员发现的异常交易影响（例如“fill-too-good”）可以反过来提示技术人员检查技术健康问题。
技术健康与交易影响的深度防御并行监控 [ 01:03:56 ]
- 监控系统的重要性 [00:33:17]
- 监控在交易公司不是可选项，而是核心业务的强制性组成部分。
- 监控系统本身被设计为最健壮、经过严格测试且具有高度冗余（包括故障转移）的系统。公司宁愿交易系统宕机，也不愿监控系统宕机。
业务背景是关键 [00:34:08]
- 深层业务背景：生产工程师和所有响应生产问题的技术人员（实际上是所有人）都需要深厚的业务背景知识。反之，交易员也需要技术背景。
- 高带宽沟通：内部用户结构使得团队成员之间可以进行高效、高信任度的沟通。例如，交易员报告“spoos市场数据陈旧”，技术人员需要立即理解“spoos”指的是标普500指数期货，以及其在芝加哥商品交易所（CME）奥罗拉机房的交易位置，从而快速定位问题。
- 事件应对：深入的业务背景知识能够帮助团队在市场事件（如美联储会议纪要、突发新闻）发生时，快速理解其对不同交易台的影响，并做出相应的风险决策。
示例事件 [00:37:22]
这是一个基于多个真实事件的虚构示例，旨在具体说明生产工程的复杂性。
- 07:15：订单引擎的日常部署完成，新版本包含错误修复和价格序列化代码重构，所有测试通过。
- 09:31：多个交易台收到针对多个符号的“fill-too-good”警报。此时，单个交易员可能尚未意识到这是普遍问题。
- 09:32：订单引擎团队收到“太多fill-too-good”警报，订单引擎自动停止。该警报路由给订单引擎团队，因为它是交易到达交易所前的最后安全防线。
- 09:33：订单引擎团队启动事件响应，并开始调查价格序列化变更。
- 09:34：团队发现价格序列化变更已部署到比报警数量更多的订单引擎，讨论是否需要预防性地停止其他订单引擎。
- 09:36：交易员加入事件通话，报告市场数据“陈旧”（未更新，正在基于昨日收盘价进行交易）。
- 09:37：市场数据团队加入事件通话。
- 09:39：市场数据团队确认部分符号的市场数据确实陈旧，但系统未将其标记为陈旧，表明存在异常。
- 09:41：市场数据团队通过元搜索工具发现两周前收到交易所驱动的变更（EDC）通知，该通知要求将受影响符号的市场数据源进行拆分，但公司错过了此通知。
- 根本原因：公司错过了EDC通知，且处理分区逻辑存在bug，导致系统未能正确识别和标记陈旧数据。
- 09:45：配置变更（拆分数据源）发布，交易恢复正常，未再收到“fill-too-good”警报。
事件回顾与经验教训 [00:45:37]
- “fill-too-good”警报的价值：一个订单引擎的警报成功捕捉到市场数据系统中的问题，再次证明了正交认知健康警报的广泛防御能力。
- 时间敏感性：尽管团队响应迅速，但在9:31之前，由于错过了开盘前的关键窗口，大部分损失已发生。事后分析将侧重于如何能在开盘前20分钟或更早发现问题。
- 业务背景与沟通：交易员报告“市场数据陈旧”是本次事件的转折点，提供了关键洞察。技术人员和交易员之间的高效、高保真沟通对快速解决问题至关重要。
- 交易所驱动的变更（EDC）的处理：遗漏EDC是一个常见问题，即使有严格的流程，也可能因大量信息中的信噪比问题而发生。
简街交易公司的生产工程总结 [00:49:26]
- 在瞬息万变的业务环境中，正确、快速的响应能力至关重要。
- 依赖可操作的事件驱动型警报以实现快速响应。
- 正交认知警报能够防御广泛的故障类型。
- 监控系统至关重要，且必须是最健壮的系统。
- 实践深度防御策略，通过多层次、独立的系统来确保可靠性。
- 支持人员需要深厚的业务知识和卓越的内部沟通能力，以便在事件中快速做出高质量决策。
- 虽然本次演讲强调了简街交易公司生产工程的独特之处，但其许多实践也与其他公司相似，尤其是在非核心高频交易领域。
问答环节 [00:51:17]
- 交易所驱动变更的遗漏：尽管监控系统很重要，但像交易所通知邮件这样的外部信息仍可能被遗漏或误判。简街交易公司有专门的流程和工具（如LLM辅助解析），但由于大量非相关信息，信噪比问题依然存在，导致偶尔的疏忽。
- 事件驱动警报的集成：简街交易公司的每个软件工程团队都负责深入思考其软件可能出错的所有方式，并相应地集成事件驱动型警报。这虽然工作量大，但确保了警报的可靠性和鲁棒性，从而使得团队在其他方面可以快速行动。
- 警报乘数效应：当一个系统出现问题时，可能会引发多个下游警报。简街交易公司通过症状驱动型警报来缓解这个问题，因为每个警报都指向特定的用户影响或系统功能异常，而不是仅仅报告底层组件故障。