课程大纲

课程大纲 · 选择一节课

为陌生系统构建证据地图

追踪一条给定记录在同步与异步流程中的流转，核对源代码与实际部署的版本，并判断日志和测试究竟能证明什么。在改动系统之前，先产出一份带有明确未知项的可行性说明。

28 分钟

作者：FDEInterviews · 更新于

文字稿

这是《前沿部署工程基础》的第七课。跟随一条代表性路径，核实实际运行的版本和配置，并对比日志、数据、测试、代码以及负责人的解释。每种信息源回答的问题各不相同。保留不确定性，而不是把一条不完整的追踪路径变成一份完整的架构图。

探索阶段已经确定了一个候选工作流及其前置条件。现在你需要对现有系统有足够的了解，以便判断某次集成或变更是否可行，而不是靠猜测那些隐藏的行为。

从你需要做出的决策出发。你手头可能有一个代码仓库、一个数据仓库、若干运维仪表盘，以及不同年代的文档。

先从问题入手，例如：这个数据源能否支持所需的时效性要求、身份在哪里发生变更、重试是如何处理的，或者在该环境内什么可以安全部署。带着明确问题做一次简短、有针对性的调查，比在形成问题之前试图读完每个文件更有用。

但这并不意味着代码是最后才用的手段。入口点、测试和 schema 往往是了解相关行为最快的途径，尤其是在无法访问运行时环境的情况下。

在移除一个无法解释的组件之前，先弄清它的用途、依赖关系和相关证据。它可能承载着某个重要约束，也可能早已过时——这两种结论都不能仅凭它的年代，或没有人记得它而得出。记录一个可验证的移除假设以及所需的检查项，而不是把每个老旧组件都奉为不可触碰之物。

现在追踪一条记录，并标注覆盖范围的边界。使用经过批准的合成记录或经过适当授权的记录。

追踪它的业务标识、操作 ID、转换过程、存储位置和消费方。当客户 ID 只在某个租户或数据源内唯一时，不要把它单独当作通用的关联键使用。

一条代表性路径有助于识别涉及的组件，但一条成功的记录不会覆盖替代分支、罕见故障、重试或其他租户。遥测数据的缺失也可能让某个组件变得不可见，因此在确认了常规路径之后，还要为重要的变体情况补充追踪。

下面是一条合成的货运路径，逐跳展示，每一跳都有一个故障问题。从门户到订单服务，要问客户端超时是否留下了未知结果；从订单服务到队列，要问即使确认丢失，消息是否已被接受；从队列到工作进程，要问重新投递是否会重复业务效果；从工作进程到发货存储，要问效果与去重证据是否一致；从导出到仓库，要问显示的结果是否是最新的且完整的。

每一跳都有可供检查的证据：请求标识、调用方范围和响应；然后是发布操作和代理确认；消息和操作标识以及投递次数；经过授权的状态变更及其回执；最后是源数据切片、批次清单和对账结果。

异步工作同样可能超时，因为发布、处理截止时间、租约过期和轮询都具有时间语义。异步意味着调用方不在同一次交互中等待完整的下游工作流，但这并不意味着投递或完成是有保证的。

OpenTelemetry 的追踪概念描述的是 span。每个 span 记录请求的一个步骤，带有开始和结束时间戳，除根 span 外还有一个父 span，并且包含用于关联异步工作的链接。插桩可以帮助连接路径，但缺少 span 本身并不能证明没有产生效果。

接下来，读取一份提供的时间线。一个完整的 Python 测试数据会按租户、订单和操作过滤一个小型合成事件日志。

共有七个事件。每个事件都带有偏移量、租户、订单、操作和消息。其中一个事件属于不同的租户和不同的操作，但订单号相同。过滤器只保留同时匹配这三个标识符的行。这些时间是来自同一个共享练习时钟的偏移量，而不是来自不同机器的墙上时钟。

六行数据保留下来。在 0 时，请求被接受。在 100 时，队列接受消息。在 200 时，客户端超时。在 500 时，工作进程启动。在 550 时，效果被提交并带有回执。在 900 时，一次重新投递返回了已有的回执。

日志记录了客户端停止等待之后产生的效果，还记录了一次返回回执的重复投递。在假设日志完整且真实的前提下，这支持了本场景中“单一效果”的结论。但它并不能证明该实现在所有崩溃或并发调用情况下都是正确的。

队列等待时间为 400 毫秒，介于消息被接受和工作进程启动之间；从工作进程启动到记录的提交为 50 毫秒。在真实追踪中把所有时长加起来可能会重复计算重叠或嵌套的工作，因此应使用路径和时间戳语义，而不是简单累加任意的 span 时长。

现在删除提交和回执条目。剩下四行，最后一行是 "worker started"。日志现在显示工作在调用方放弃之后才开始，却没有任何关于它如何结束的信息。这正是未受保护的重试可能重复应用该效果的状态。客户端超时并不能在没有效果的情况下确立失败。

回到完整日志，仅按订单过滤，而不是按租户和操作。计数变为七，在精简日志上为五，因为租户 B 对同一订单号的无关操作也加入了追踪。将结果记录为未解决，并寻找源状态或其他权威的操作记录。不要仅仅因为某次写入缺少成功日志就重放它。

现在验证实际运行的内容。将仓库修订版本与已部署的制品、配置、计划任务和已启用的路由进行比较。

main 分支中的代码路径可能尚未部署，已部署的功能可能已被禁用，计划任务可能从不同的镜像运行。假设仓库包含在修订版 R2 中添加的超时，而部署清单标识的是 R1。你不能声称生产环境具有 R2 的超时。

通过授权的读取路径验证实际的发布版本和生效的配置。反过来，仅凭清单可能已过时，因此要将其与正在运行的工作负载或可信的发布记录关联起来。检查配置名称和来源，但不要将机密值复制到调查笔记中。区分源码构建、制品晋升和运行时配置，并记录哪些证据是可用的。这足以识别差距，而不会在只读过源码的情况下假装已检查过生产环境。

将工作负载和成本作为线索。高流量的端点、大表和高开销的作业可以帮助确定重要的调查目标。

它们本身并不能定义重要性。一个低频的紧急路径，或一张小型访问控制表，可能是关键所在。而一个告警可能已过时或选择不当。要问这个工作负载服务于什么、谁依赖它的输出、失败代价是什么，然后比较平均与峰值行为、积压和新鲜度。在确认查询语义之前，不要优化一个高开销的查询，因为让错误的报告运行得更快并不能让它变得正确。

最后，把测试当作可执行的断言。测试针对所演练的输入和实现陈述了一个预期。

测试可能源自需求、假设的失败、缺陷报告或生产事故。具体的日期或工单是一条调查线索，而不是事故存在或其严重程度的证明。

尽早阅读相关测试，当它们能澄清契约时；并在检查依赖和影响之后，仅在合适的环境中运行它们。测试通过并不能证明已部署版本通过，而且模拟可能省略你需要评估的集成边界。

将测试、问题历史、负责人的解释和代码注释结合起来理解推理逻辑。当它们相互矛盾时，记下冲突点以及下一步的验证步骤。不要假定某一种来源永远高于其他所有来源。

该你了。在此处暂停视频。运行时间线，移除两条最终结果记录，然后写下哪些是已知的、哪些是未知的。仅按顺序过滤，并说明为什么无关租户的事件会污染这条追踪。解释为什么业务身份和操作身份都很重要。然后创建一张包含五列的证据表：断言、来源、修订或观察时间、覆盖范围限制和下一步检查。包含 R1 和 R2 的部署不匹配，以及一个历史来源不明的具体测试。对于你选择的一个获准项目，追踪一个请求和一个重要的失败分支，并将你的证据表与架构文档进行对比。如存在实际差异，如实记录，但不要因为练习预期旧文档是错的就凭空编造矛盾。

总结一下。围绕一个具体的决策展开，使用多个证据来源。一条追踪只覆盖一条路径，而异步工作仍然存在超时和不确定的结果。在断言源代码行为已上线之前，先验证已部署的修订版本和生效的配置。成本和流量有助于排定优先级，但关键的低流量路径依然重要。测试证明的是被验证过的预期，而不是自动的生产历史或完整的安全性。

这就是第七课。本系列下一课将明确每个边界上的所有权、信任、网络和含义。完整课程及其练习和演练见 fdeinterviews.com。

TL;DR： 跟踪一条有代表性的路径，验证实际运行的修订版本和配置，并对比日志、数据、测试、代码和负责人的解释。每种来源回答的问题不同；保留不确定性，而不是把一条不完整的追踪变成一套完整的架构。

你现在的位置。 探索阶段已确定了一个候选工作流及其前提条件。你现在需要对现有系统有足够的了解，以便在不猜测隐藏行为的情况下判断集成或变更。

你需要做的决策优先

你可能有一个代码仓库、一个数据仓库、运维仪表盘以及不同年代的文档。从你需要回答的问题入手：这个数据源能否支持所需的时效性；身份在哪里发生变化；重试是如何处理的；或者在该环境内可以安全部署什么？

简短而有针对性的调查胜过在形成问题之前试图读完每一个文件，但这并不意味着代码是最后才用的手段。入口点、测试和模式（schema）可能是了解相关行为的最快途径，尤其是在无法访问运行时的情况下。

在移除一个原因不明的组件之前，先查明它的用途、依赖关系和相关证据。它可能承载着一项重要约束，也可能已经过时——这两种结论都不能仅凭其存在年限或无人记得它而得出。应记录一个可验证的移除假设以及所需的检查项，而不是把每个老旧组件都奉为不可触碰之物。

一条记录，并标注其覆盖范围限制

使用经批准的合成记录或经过适当授权的记录，并跟踪其业务标识、操作 ID、转换过程、存储位置和消费方。当客户 ID 仅在某个租户或数据源内唯一时，不要将其单独用作全局连接键。

一条代表性路径有助于识别涉及的组件，但一条成功的记录并不能覆盖其他分支、罕见故障、重试或其他租户，而且缺失的遥测数据可能让某个组件完全隐身。在建立常规路径之后，应为重要的变化情形补充追踪。

合成货运路径中的一跳需检查的证据故障问题
门户请求到订单服务请求标识、调用方范围和响应客户端超时是否导致了结果未知？
订单服务到队列发布操作和代理确认即使确认丢失，消息是否已被接受？
队列到工作进程消息/操作标识和投递次数重复投递是否会重复产生业务效果？
工作进程到发货存储经授权的状态变更和回执效果与去重证据是否一致？
导出到数据仓库数据源截断点、批次清单和对账展示的结果是否最新且完整？

异步工作同样会超时：发布、处理截止时间、租约过期和轮询都具有时间语义。“异步”意味着调用方不在同一次交互中等待完整的下游工作流，并不意味着交付或完成是有保证的。

OpenTelemetry 的追踪概念描述了 span（请求中每个计时的步骤，带有开始和结束时间戳，除根 span 外还有父 span）及其相互关系，包括用于关联异步工作的链接。插桩有助于串联一条路径，但缺失某个 span 本身并不能证明没有产生效果。

一份提供的时间线

这个完整的 Python 测试数据按租户、订单和操作过滤一个小型合成事件日志。时间戳是相对于同一个共享演练时钟的偏移量，而非来自不同机器的墙上时钟，因此该测试数据无法说明真实分布式时钟是否同步。

events = [
    (0, 'A', 'O1', 'op-7', 'request accepted'),
    (100, 'A', 'O1', 'op-7', 'queue accepted message'),
    (200, 'A', 'O1', 'op-7', 'client timeout'),
    (300, 'B', 'O1', 'op-8', 'unrelated tenant operation'),
    (500, 'A', 'O1', 'op-7', 'worker started'),
    (550, 'A', 'O1', 'op-7', 'effect committed with receipt'),
    (900, 'A', 'O1', 'op-7', 'redelivery returned existing receipt'),
]
selected = [row for row in events if row[1:4] == ('A', 'O1', 'op-7')]
for offset, tenant, order, operation, message in sorted(selected):
    print(offset, message)
assert len(selected) == 6
assert sum(row[4] == 'effect committed with receipt' for row in selected) == 1
# 0 request accepted
# 100 queue accepted message
# 200 client timeout
# 500 worker started
# 550 effect committed with receipt
# 900 redelivery returned existing receipt

所提供的日志记录了客户端停止等待之后产生的一个效果，以及一次返回了回执的重复投递。在假设日志完整且真实的前提下，这支持了本场景中“仅产生一次效果”的说法；但它并不能证明该实现在所有崩溃或并发调用情况下都是正确的。

队列等待时间为 400 ms，即从接受到 worker 启动的时间，而 worker 启动到记录提交的时间为 50 ms。在真实追踪中把每段时长简单相加可能会重复计算重叠或嵌套的工作，因此应使用路径和时间戳语义，而不是随意累加 span 长度。

从测试数据中移除提交和回执条目后，剩下的客户端超时就无法告诉你是否产生了任何效果。剩下四行，最后一行是 "worker started"：日志现在显示工作在调用方放弃之后才开始，却没有任何关于它如何结束的信息，这正是未受保护的重试可能重复应用效果的典型状态。回到完整日志，如果只按订单而不是按租户和操作过滤，计数会变成七（在精简日志中为五），因为租户 B 对同一订单号的不相关操作也加入了追踪。将结果记录为未解决，并寻找源状态或其他权威操作记录；绝不要仅仅因为成功日志缺失就重放一次写入。

实际运行的内容

将仓库版本与已部署的制品、配置、定时任务和启用的路由进行对比。某个代码路径存在于

main

中但可能并未部署；某个已部署的功能可能被禁用；某个定时 worker 可能运行自不同的镜像。

假设仓库在版本 R2 中添加了超时，而部署清单标识的是 R1。你不能声称生产环境具有 R2 的超时；应通过授权的读取路径验证实际发布版本和生效配置。反过来，仅有清单也可能是过时的；应将其与正在运行的工作负载或可信的发布记录关联起来。

检查配置名称和来源时，不要将机密值复制到调查笔记中。区分源码构建、制品晋级和运行时配置，并记录哪些证据是可用的。这足以识别差距，而不必在只读了源码的情况下假装检查过生产环境。

工作负载与成本作为线索

高流量端点、大表和高开销任务可以指向重要的调查目标，但它们本身并不能定义重要性。一个低频的紧急路径或一张小型访问控制表可能至关重要，而某个告警可能已过时或选择不当。

询问该工作负载服务于什么、谁依赖其输出以及失败的代价是什么，并比较平均与峰值行为、积压与新鲜度。在确认查询语义之前不要优化高开销的查询；让错误的报告变得更便宜并不能使它变正确。

测试作为可执行的断言

测试针对所执行的输入和实现陈述一个期望，它可能是根据需求、假设的失败、缺陷报告或生产事故编写的。具体的日期或工单是调查线索，而不是事故及其严重性的证明。

当相关测试能澄清契约时，尽早阅读它们，但只有在检查了它们的依赖关系和影响之后，才在合适的环境中运行它们。测试通过并不能证明已部署版本也能通过，而且 mock 可能会省略你需要评估的集成边界。

综合运用测试、问题历史、负责人的解释和代码注释来理解推理过程。当它们相互矛盾时，写下冲突之处和下一步验证步骤，而不是假设某一种来源总是高于其他来源。

上面的主线就是按顺序展开的调查过程，覆盖范围限制之所以单独作为一步，是因为一条忘记它的追踪路径会变成一个无人验证过的架构。

在继续之前先做这些

运行时间线，去掉两条最终结果记录，写下哪些信息仍然已知、哪些未知。然后仅按顺序过滤，并说明为什么无关的租户事件会污染追踪路径。解释为什么业务身份和操作身份都很重要。

创建一张包含五列的证据图：论断、来源、修订或观察时间、覆盖范围限制和下一步检查。包含 R1/R2 部署不匹配的情况，以及一个历史来源不明的具体测试。

对于你选择的一个获准项目，追踪一个请求和一条重要的失败分支。将你的证据图与架构文档进行比较，并记录任何实际差异；不要因为练习预期旧文档是错的就凭空编造矛盾。

深入了解

核心要点

  • 围绕一个具体决策，运用多种证据来源进行分析。
  • 一次追踪只覆盖一条路径；异步工作仍然存在超时和不确定的结果。
  • 在断言源代码行为已上线之前，先核实已部署的修订版本和生效的配置。
  • 成本和流量有助于排定优先级，但关键的低流量路径同样重要。
  • 测试证明的是被验证过的预期，而不是自动获得的生产历史或完整的安全性。

自我检测

先作答再看答案。回忆才能让知识牢固，认出来不行。

  • 1客户端在 200 ms 时超时；worker 在 550 ms 时提交。超时是否阻止了该效果？
  • 2main 分支包含一个 R2 超时修复，但部署记录显示是 R1。你能断言什么？
  • 3一个测试引用了某个工单和日期。这能证明它的来源是什么？

免费登录以保存进度，之后可以回到本课继续学习。