本文是《执行缝隙》The Execution Gap的作者手记。 它不是书籍正文的摘要或重写而是围绕本章问题、工程背景与写作之后的进一步思考。做系统久了以后“定位问题”几乎已经变成一种固定动作。遇到异常先列出涉及的服务、模块、接口、节点再沿着日志和调用链逐个检查。哪一个接口报错了哪一个状态没有更新哪一段代码走到了错误分支哪一个实例在那个时间点出现了异常通常都可以一点一点被缩小。这种方法之所以成为工程师的本能是因为它确实有效而且现代软件系统本身就是按照这种方式被组织出来的。代码有模块系统有服务服务有实例实例有指标和日志每一个对象都有明确的名字和边界。监控系统天然围绕这些对象工作事故复盘也天然围绕它们展开。于是当我们问“哪里出了问题”时实际上早已经悄悄限定了答案可能出现的位置问题应该在某一个已经被划出来的对象里面。第三章真正让我开始警惕的就是这个前提。因为有一些执行偏差在把所有组件逐个检查完以后依然没有消失。上游收到的输入可以是对的中间系统按照自己的规则处理也没有异常下游接收到的数据可以完整执行端的状态也没有报错甚至每一段都有日志能够证明当时到底发生了什么。可当这些材料全部放在一起时最终现实结果仍然和最初已经成立的对象对不上。这时候继续问“还有哪个组件没查到”有时只是让我们在同一个搜索空间里不断提高分辨率而不是改变问题本身。我们能看见对象却不一定能看见对象之间的东西现代工程体系对“对象内部”已经非常擅长。一个服务内部发生了什么我们可以增加日志一个调用到底耗时多久可以加入 tracing一个状态为什么变化可以记录状态迁移一个模块是否出现异常可以增加指标、告警和更细粒度的观测。这些手段都很重要我从来不认为它们应该被削弱。但有一个问题是它们大多数仍然是在告诉我们这个对象内部发生了什么。假设上游产生了一个判断下游接收了它并继续完成执行。上游日志可以证明自己为什么做出这个判断下游日志也可以证明自己接收到了什么并按照什么规则行动可这两份日志放在一起并不会天然证明一件事情下游接收到的那个对象是否仍然完整保留着上游判断成立时所依赖的含义和条件。这就是我写这一章时越来越在意的地方。我们很容易因为两边都没有报错就默认中间的关系没有问题。但“左边成立”和“右边成立”只能证明两个端点分别成立并不能自动证明把它们连接起来的那件事也成立。这一点在软件里尤其容易被忽略因为系统架构图已经替我们画好了那些连接。两个服务之间有一条箭头一个 API 把它们连起来一段消息进入队列以后被另一个消费者读取。从视觉上看它们已经被连接因此我们也很容易顺手认为那个连接所承载的意义也已经被建立。可箭头只是表示数据从这里去了那里。它不一定证明语义完整地过去了也不一定证明原来成立的条件在另一个时刻仍然成立更不证明两个系统所指向的对象始终是同一个对象。这种差别在系统正常运行时并不显眼因为大部分时候两端确实吻合。真正困难的是一旦它们第一次分开我们通常首先去检查两个端点而不是检查那个从来没有被当成独立检查对象的“之间”。有些东西是在传递过程中丢掉的第三章里用了“转换、时差、接缝和关系”几个词我当时很刻意地没有把它们做成新的故障分类。因为如果把它们变成四个框工程师很快又会得到另一张故障清单然后继续问这次属于转换问题还是时差问题还是接缝问题那样其实没有真正改变思维方式。这几个词真正想表达的是同一件事情有些偏差不是藏在一个对象内部而是在两个分别成立的对象之间出现。其中最容易理解的是转换。一个对象从一个系统进入另一个系统时通常不会原封不动地过去。业务意图会被变成参数审批结果会被变成状态策略判断会被变成ALLOW或DENY现实条件会被抽象成机器可以读取的字段。转换本身不是错误它恰恰是系统能够协作的基础。问题在于任何表示方式都有自己的边界。上游的一个判断可能是在若干前提同时成立时得出的可当这个判断继续向下传递时下游真正收到的可能只剩一个最终结论。那个结论没有错上游的判断也没有错下游按照这个结论继续行动同样没有违反自己的规则可原来让这个结论成立的某些条件已经没有一起过去。这类问题很难被传统日志直接标成“错误”因为没有任何一个字段一定非法也没有任何一个组件一定异常。它更像是一种意义在跨越边界时发生了变化。时间会让这个问题更明显。一个审批在上午十点成立一个动作在下午三点才真正发生。上午十点时成立的现实条件并没有承诺自己到了下午三点仍然保持不变。如果系统只记录“审批通过”这个结果却没有继续关心它成立时依赖的状态那么五个小时之后的执行仍然可能在形式上拥有一个完全有效的审批。这时候审批系统没有错执行系统也未必有错。真正需要问的是当初使这个审批成立的东西在执行发生时是否仍然成立这个问题既不完全属于审批对象内部也不完全属于执行对象内部。它存在于两者之间而且跨越了时间。我认为这也是“执行缝隙”这个词真正开始变得有意义的地方。所谓 gap并不一定意味着中间有一个看得见的洞也不一定意味着某个组件失效。它可能只是表示两个端点仍然分别正确而连接它们所依赖的那个条件已经没有继续成立。更多日志不一定能够回答这个问题这一点对工程直觉其实有些不友好。当事故没有解释清楚时最自然的动作就是增加观测。日志不够就加日志trace 不够就增加 span服务太大就继续拆状态不清楚就记录更多中间状态。这些措施常常是必要的但我后来越来越不愿意把“观测得更多”直接等同于“就能知道发生了什么”。因为观测密度和问题类型是两件事。如果问题真的藏在一个组件内部那么提高内部观测能力当然会帮助我们找到它。但如果问题来自两个对象之间没有被明确建立的关系那么两边日志都增加十倍也可能只是让我们更加确定左边确实成立右边也确实成立。至于为什么左边成立以后右边却没有保持我们原本以为应该保持的含义仍然没有被回答。这让我想到一个在工程实践里很容易出现的错觉只要数据足够多事实就会自己浮现出来。其实未必。数据能够告诉我们已经被记录的对象发生了什么但它不能替我们决定哪些对象之间原本应该保持什么关系。如果这条关系从来没有被定义过、检查过或者留下证据那么再完整的对象内部日志也只能让我们更加清楚地看见两个端点。中间缺失的东西仍然缺失。因此第三章真正改变的并不是排查工具而是排查对象。过去我们主要问“哪个组件坏了”现在必须再增加一个问题“哪一个原本应该保持成立的关系没有继续成立”这两个问题并不冲突。组件当然会坏服务会宕机代码会写错配置会错误硬件也会失效。这些传统故障没有因为 Execution Gap 的出现而消失。真正需要补上的是组件检查完成以后仍然无法解释结果时我们还剩下什么语言继续往下查。我不想把“关系”再变成一个新组件写到这里其实还有一个很容易掉进去的坑。既然关系这么重要那是不是应该把“关系”本身做成一个新的正式对象然后给它定义状态、字段、分类再像检查组件一样检查关系我在这一章里没有这么做。因为一旦这样处理我们可能只是把原来的问题换了一层名字。过去我们寻找一个坏掉的组件现在改成寻找一个坏掉的“关系对象”过去有组件清单之后又会出现关系清单。看起来理论变复杂了但搜索方式没有真正变化我们仍然希望所有问题最终都能被压缩成一个明确的点。而这一章真正想保留的恰恰是另一种可能性一次偏差未必只有一个唯一断点。同一个现实失败里可以同时存在多段关系变化。某个条件在转换时被压缩了一次在等待过程中又因为现实状态变化而失效进入下一系统时还可能再次经历一次重新解释。到最后很难说“真正的问题就是这一点”。第三章使用那十七个经过事实核验的案例并不是为了证明理论而是因为这些现实失败不断提醒我现实系统中的偏差往往不像教科书里的单点故障那样干净。多个分析维度可以同时成立同一个事故也未必能稳定收缩到一个唯一故障位置。这并不意味着事故永远无法定位。它只是意味着定位不一定等于找到一个唯一的坏点。有时候真正需要解释的是一段关系为什么没有继续成立以及这种变化如何沿着多个系统逐步传播最后变成现实结果。到这里问题反而开始变大第一章拆掉了“每一环都对所以整体也应该对”的推论第二章又把“执行了”拆成了一组不能默认等同的对象。到了第三章我们再往前走了一步即使这些对象本身都分别成立也仍然不能假设它们之间的关系天然成立。这一步让我开始意识到一个更麻烦的问题。如果我们把视线从对象内部移到对象之间搜索空间会突然变得非常大。一个复杂系统里有很多对象理论上任意两个对象之间都可能存在某种联系。如果只是笼统地说“检查关系”那实际上没有什么工程意义因为我们最后会得到一个几乎无限扩张的关系网络。所以“偏差可能存在于关系中”还不是答案。它只是改变了我们应该往哪里看。真正能够把这件事继续推进下去的是下一步必须回答另一个更严格的问题在一条从意图走向现实执行的链路里究竟有哪些关系是真正承担必要条件的哪些关系一旦不再成立就会使上游已经成立的对象无法继续为下游执行提供依据只有这个问题被回答以后“关系”才可能从一种观察方式变成真正可以用于工程判断的边界。所以第三章写到最后我并没有感觉我们已经找到了解决方案。恰恰相反我们只是第一次把排查范围从方框里面移到了方框之间。而当所有方框都正常、所有日志都完整、所有组件都能够证明自己没有出错时真正应该继续追问的已经不再是“还有哪个地方没查到”而是在这些分别成立的对象之间究竟有什么东西必须一直成立这也是《执行缝隙》接下来真正要进入的问题。关于《执行缝隙》《执行缝隙》The Execution Gap是Execution Engineering Trilogy第一卷。本书讨论一个基础而关键的问题从人的意图到机器最终改变现实世界中间究竟发生了什么在线阅读繁體中文版 執行縫隙 | Havenlon ResearchEnglish Edition The Execution Gap | Havenlon ResearchAmazon Kindle https://www.amazon.com/dp/B0HKYLBK3BAmazon Paperback The Execution Gap: The Structural Discontinuity Between Intent and Action (Execution Engineering Trilogy): Wang, Lin, Wu, Mengting, Zhang, Yong, Deng, Jiang: 9798177903347: Amazon.com: Books© 2026 Lin Wang / Havenlon.本文为作者手记与《执行缝隙》正式书籍正文相互独立。 未经授权请勿全文转载或用于商业再出版。 引用请注明作者及出处。