Liora Friedberg：在生产环境中解谜

Ron Minsky 邀请 Jane Street 生产工程师 Liora Friedberg，讨论她的团队如何支持实时系统。Friedberg 解释说，公司运行的软件每天交易数十亿美元，因此需要有人及时发现异常，并在生产系统运行时做出响应。

支持是生产工程师职责中的重要组成部分。交易日内，轮值工程师要响应告警，以及发现异常的同事发来的报告。这不同于夜间或周末的待命工作，尽管软件工程师也会参与支持。

工作的另一部分是长期改进，让未来的问题更容易应对，或减少需要人工干预的情况。这可能包括构建 OCaml 应用，让用户自行处理请求，也可能是改进重大事件的响应流程。具体比例取决于个人和团队。

Minsky 将这个岗位与站点可靠性工程作比较：实时支持和改善支持工作的项目相辅相成。Friedberg 估计，生产工程师大约有四分之一到三分之一的时间在轮值，其余时间可以用于长期工作。

生产工程与软件工程之间没有明确的界线。Friedberg 说，软件工程师往往深入了解较少数量的系统；生产工程师通常对更广泛的系统及其连接建立扎实的工作模型。围绕同一个目标结合不同视角，能让团队受益。

Friedberg 学习过计算机科学和经济学，之后进入咨询行业，因为她想尝试不同类型的工作。她觉得问题很有意思，却希望找到不同的工作动力和更好的工作生活平衡，因此考虑重返技术领域。

她在一门 OCaml 课程中听说过 Jane Street，并申请了软件工程岗位。公司认为她的跨学科背景可能适合生产工程，于是建议她了解这个选择。在弄清工作内容后，她加入了团队，并在这个岗位工作了五年。

她最喜欢的是支持工作：感觉就像一场寻宝解谜。她在不同系统中收集证据、提出假设，有时会在解释突然清晰时获得满足感。帮助同事解决一天中遇到的问题，也能带来即时的成就感。

Minsky 补充说，这些谜题不局限于单个程序：它们可能涉及多个技术组件、人员和机构，包括交易所及清算公司。这种广度让调试更丰富，也要求工程师理解业务如何运作。

Friedberg 的团队负责接收、解析、规范化和归组公司的交易活动，再将结果送往下游。交易记录进入历史数据库、供订阅者使用的 Kafka 主题，以及与银行通信的系统。

面向银行的数据流很重要，因为银行需要这些信息完成相关的现实世界处理。下游系统也需要一致的中心数据源。交易员利用这些数据实时监控，并计算某个策略当前的盈亏等指标。

一种常见的支持问题是新交易类型进入流水线。Friedberg 所说的交易类型，是字段和值的特定组合，例如记账日期、交易对手和结算系统。此前从未出现的组合可能没有配置好的处理路径。

Minsky 指出，为新的结算流程配置路径有时需要做出实际的业务决策。Friedberg 的团队会与掌握相关背景的运营人员合作，把这些决策转化为系统能够理解的配置。团队也在努力让其中部分流程变成自助操作。

生产工程师不仅要了解技术，还要了解金融系统。Friedberg 喜欢这种多样性：她无法总是预料轮值当天会出现什么问题，也不知道调查过程中会学到什么。

更严重的一类事件会影响多个团队。Friedberg 回忆，有些交易的标识符曾被手动修改。应用尝试为它们生成错误信息，却在生成错误时崩溃，导致交易无法在下游入账。

团队找到了崩溃原因并恢复了系统。幸运的是，已有工具可以从实时数据流中移除特定交易，于是他们过滤掉格式错误的交易，随后复盘事件。这是流水线遇到意外数据时较为严重的一次案例。

在她的团队，通常有时间调查、寻找根因并向他人请教。其他团队面临的压力可能更加紧迫。订单引擎将内部交易意图连接到交易所或经纪商协议，因此故障可能立即阻止交易；Friedberg 提到的损失数字是假设示例，并非某次事件的实测值。

Minsky 澄清，直接的财务影响往往是机会成本：系统停机时无法完成交易。交易后处理有时可以在较长时间内修复，但监控是例外。如果关键监控不可用，就无法安全地继续交易。

Friedberg 以前负责过监控软件，其冗余、审查和发布流程尤其严格。她的团队每天都使用这套系统，对功能有很多想法，于是她加入了构建该系统的团队，代表这些需求。

她添加的一项功能是暂缓告警，至今仍在使用。Minsky 解释，Oculus 是一套告警与工作流系统：出现问题时，它向相关人员呈现独立告警，帮助他们在可能很忙乱的时段协调工作并持续跟踪。

支持工程师往往是这些工具的资深用户，也可以修改工具。Friedberg 提到，有工程师在自动告警操作之上构建了有状态的层，让自动化更具表达能力。有时生产团队还会专门为自身需求开发工具。

其中一个工具会分析团队的告警历史，帮助回答有多少告警被处理、转发、暂缓或自动关闭，以及哪些系统产生了告警。有了这些证据，团队就能改善轮值工作的健康状况。

一种常见模式是告警闪烁：告警打开又关闭，期间没人采取操作。它仍然会消耗注意力，工程师甚至可能在告警消失前开始调查。团队可以检查触发告警的代码，调整阈值或修复告警本身，避免制造不必要的噪声。

Minsky 区分了应用代码主动发出的告警，与检查导出指标的监控。过去，系统可能发现内部出现意外情况后自行发出告警。因此，修复嘈杂告警可能需要追查应用代码，而不仅是修改集中告警系统。

一项较新的功能可以让工程师从告警直接跳转到代码库中触发它的位置。Friedberg 说，告警统计还可以显示无人干预便关闭的短暂告警，以及接手、转发和暂缓等操作。

反复暂缓也是值得调查的信号。推出这项功能时，团队考虑过它是否会鼓励人们忽略问题，但最终选择相信同事会审慎使用。频繁转发的告警也许一开始就该交给另一个团队；经常暂缓的告警可能触发得太早。

Minsky 担心人们把告警当成电子游戏：只顾按按钮清空屏幕，却不理解问题。Friedberg 认为，好的生产工程需要反思，而不仅是清空队列。要问告警是否有必要触发、能否减轻影响、信息能否更清楚，以及部分响应是否可以自动化。

自动化和筛选可以提高信噪比，让人们认真对待有意义的告警。但 Minsky 指出另一方向的风险：复杂过滤可能有 bug，也可能压制真实问题。如果故障表现为什么都没发生，就很难发现被过度静默的告警。

Friedberg 说，应用通常通过命令行工具暴露内部状态，让熟悉系统的用户检查和编写自动化。对于过度自动化，她并不认为有简单答案。代码审查有所帮助，团队也会讨论分诊和优先级。

在她的团队，工程师每天结束轮值时会写一份总结。遇到的问题经常引发关于改进方案的讨论，获得最多支持的想法会被推进。Minsky 强调，支持自动化是真正的软件，其正确性很重要。

过滤不足会让人们应接不暇，最终不再注意；过滤过度则可能隐藏重要信息。两种失败都会削弱监控。塑造工程师对生产环境认识的工具，值得严肃的工程投入和审查。

除了告警，支持工作还依赖调试和内部状态检查。Friedberg 提到，相对较近的一项工作是集中化日志管理。此前，工程师往往要通过 SSH 连接生产机器，在每台主机上读取或解析日志文件。

Jane Street 还把大量数据保存为 S 表达式，因此人们会构建共享工具来提取信息。Minsky 说，与其他公司的工具相比，内部环境有时更好，有时更差，也常常只是不同。

集中日志是更广泛可观测性工作的组成部分，其中还包括分布式追踪。同时，一些专用工具已经使用多年：带有精确时间戳的高度详细的数据包捕获，可以帮助团队以极细的时间粒度重建交易系统中的事件。

新工具仍然需要有人采用。Friedberg 指出，工程师可能对新工具很兴奋，但迁移必须与其他许多优先事项竞争。Minsky 警告，当大多数人已经习惯新方式后，长期存在的一小部分旧系统可能增加复杂度和风险。

安排时间淘汰旧方式，有助于工程师在 Jane Street 庞大的单体代码库中查看不熟悉的部分。生产工程师经常要阅读触发告警的代码；共享且保持更新的工具，能让他们和软件工程师更容易开展调查。

并非每个生产工程项目都以编程为主。Friedberg 举例说，为一种新交易做准备时，工程师可能要与交易团队沟通、阅读规格、编写部分代码，并与下游客户协调。这个人连接各团队和系统，让新流程得以运行。

Minsky 认为，这种运营工作与支持之间有联系。了解新交易对手、周边系统和配置细节，能够帮助工程师在新流程上线第一天出现意外故障时做出响应。

文化与工具同样重要。Friedberg 说，人们应当能够放心承认错误，包括生产环境中的错误，并及时提出，让团队减轻影响。事后复盘记录发生了什么、帮助大家学习，而不是归咎个人。

Minsky 说，个人有时确实需要改变自己的行为，但反复发生的错误也要求改变系统：降低犯错概率，或缩小影响范围。事后复盘记录经过、原因和解决方式，再确定具体改进。

这些改进可能包括更快联系受影响的用户，也可能是技术上的改变。坦诚记录仍可能令人不安，尤其是几个不同的人在一连串故障中各自犯了错误。事件当事人应该有机会解释发生了什么。

Friedberg 说，新人会通过阅读复盘、观察别人承认错误后仍受尊重来学习。涉及某人的事件发生后，团队也应直接支持当事人，确保其感到自在，并让讨论保持审慎。

Minsky 对复盘模板的看法比较复杂。时间线、做得好与不好之处以及经验教训等结构有帮助，但也可能让作者只顾填表，而不退一步思考事件有多严重，以及组织应该学到什么。

Friedberg 同意模板可能限制思考，但认为它对第一次在令人紧张的事件后撰写复盘的人很有帮助。随着经验增加，人们可能需要更大的空间。团队讨论和事件后的交流同样重要；文档不应成为唯一的反思工具。

随着系统变得更可靠，训练也更困难。Minsky 回忆，以前生产故障频繁发生，工程师有很多学习机会。如今，即使严重事件较少发生，团队仍需让人们做好调试准备。

一种方法是桌面事件模拟。培训者提出场景，受训者选择操作，再由培训者描述接下来会发生什么。讨论涵盖技术响应、影响缓解、向相关方通报，以及如何思考不断变化的局面。

一些团队还用 Overcooked 或 Keep Talking and Nobody Explodes 等游戏，在人为制造的压力下练习沟通。游戏很有趣，但也要求队友在紧张情境中保持冷静、清晰思考并协调行动。

另一种方法是故意破坏系统的非生产版本，让受训者用真实工具调查。Minsky 认为这接近理想方案，但它需要逼真的平行环境，也需要有人设计有意思的故障。Friedberg 见过这种训练，但普及程度没有她希望的那么高。

她回忆起一次名为 Training Wheels 的全公司练习：一个小系统会出现故障，工程师即使没有事先了解，也可以探索规模适中的代码库和文件系统来修复问题。多年来出现过这样的练习，但不是每个团队都有。

新生产工程师和软件工程师一样参加 OCaml 训练营，也参加生产岗位专属培训和课程。剩余很多训练因团队而异：经验丰富的同事会陪伴新人几周，一起处理问题并提供反馈。Minsky 将其称为师徒式培养。

一些团队采用更有结构的训练方式，尤其是在支持工作风险较高的地方。岗位需要较强的调试能力、细心、冷静和清晰沟通，但不同团队的实际工作差异很大。

招聘也反映了这种多样性。学生往往申请软件工程岗位，却不知道还有生产工程，因此 Jane Street 可能主动介绍这个选择，并提供侧重生产工作的面试。有经验的候选人可能已经知道自己喜欢哪种运营工作。

Friedberg 强调沟通能力：生产工程师连接不同团队，而团队成员可能使用不同的心智模型和词语来描述同一笔交易。调查式调试、在生产环境中保持谨慎，以及压力下头脑冷静也尤其重要。不同人适合不同的紧迫程度。

Minsky 说，有些人觉得救火令人振奋，另一些人则觉得不愉快；Friedberg 补充，解决困难事件可能特别有成就感。两人都不认为制造紧急情况是好事，吸引人的是事件发生时能够妥善应对。

候选人会回答软件工程问题，也会完成面向生产工作的练习。其中一个例子要求他们使用代码、命令行工具和数据调查故障。练习基于 Friedberg 团队过去反复执行的一项工作，后来团队为它构建了自助网站。

这个练习是人为设计的，但面试官可以观察候选人如何提出假设、选择步骤并解释推理。Friedberg 说，过程很重要：只看最后的代码，不足以充分判断一个人如何开展调查。

Minsky 也认为，能展示双方如何合作的面试，比单纯判断谜题是否解开更有价值。生产工作需要协作并与其他工作相连。Friedberg 补充，对于编程相对较少的岗位，面试也应让合适的候选人有机会展现优势。