大多数 Production Bugs 不在你的代码中，而是存在于系统之间。
发布: (2026年3月13日 GMT+8 08:23)
5 分钟阅读
原文: Dev.to
Source: Dev.to
为什么最难的问题出现在系统之间
每个人都喜欢谈论写代码——干净的代码、快速的代码、AI 生成的代码、无锅炉代码。
但在许多真实系统中，最难的问题并不出现在你上周写的控制器、存储过程或 API 方法里。它们出现在系统之间。
一个请求在系统 A 中可能是合法的，在中间件中被转换，在系统 B 中部分丰富，在系统 C 中被静默拒绝，随后因为状态标记在错误层面看起来正常而向业务报告为“已完成”。这种类型的失败让生产问题难以解释：因果分散在分布式组件中，故障并不明显。
可观测性和分布式追踪
OpenTelemetry 的可观测性文档 将分布式追踪描述为一种观察请求在复杂分布式系统中传播的方式，帮助调试在本地难以复现的行为。
同样的思路也出现在企业集成平台中。SAP 的文档指出，消息处理日志会存储已处理消息及各个处理步骤的数据，消息监控则允许你在租户上检查单条消息。换句话说，逐步了解消息流是必不可少的。
事故期间需要提出的关键问题
当出现故障时，考虑：
- 实际发生了什么？
- 哪个系统是事实真相的来源？
- 是负载本身错误，还是转换错误？
- 接收系统是拒绝了它、忽略了它，还是接受后在后续阶段失败？
- 我们面对的是业务流程故障还是仅仅是误导性的状态？
回答这些问题需要一种不同的思维方式：先暂停构建者的思考，转而像调查员一样思考。
追踪故障的关键数据
- 时间戳
- 关联 ID
- 负载版本
- 处理步骤
- 重试历史
- 副作用
- 上下文传播
OpenTelemetry 描述了上下文传播，它是让追踪、指标和日志等信号在分布式边界之间关联的机制。如果你的系统无法向前传递上下文，调试将变得更加困难。
为什么 “在我的机器上可以运行” 不足以说明问题
在本地通常缺少：
- 异步重试
- 中间件转换
- 环境特定的凭证
- 下游校验规则
- 系统之间的竞争条件
- 过期的参考数据
- 工作流引擎做出与预期不同的决策
当故障进入生产环境时，它往往是可观测性、系统思考或交接问题，而不是代码本身的问题。
结论
高级工程师不仅仅是构建系统，更是解释系统如何失效。
能够跨边界追踪故障的工程师会成为最棘手事故的首选人物——不是因为他们写了最花哨的代码，而是因为他们懂得如何在系统边界之间追寻真相。