北京
周三下午两点，一个微服务团队的合并请求亮起绿灯。流水线检查全部通过，代码整洁，单元测试覆盖率达到要求。主分支接受了这次变更，然后整个组织的其他团队开始在这个假设上构建：这段新代码能够正常工作。他们从它分支，在它之上部署，用自己的故障排查逻辑去调试，深信前一步是可靠的。没有人停下来问一句：那个绿色对勾到底保证了什么？
这种模糊曾经可以忍受。因为代码是以人的速度抵达的，写代码的人脑子里装着全部上下文，合并之后还会留在旁边。现在，这两个条件都消失了。编码代理正在成倍地增加 PR 数量，越来越多的变更由没有任何持久上下文的“东西”写出来。GitLab 最近的调查已经揭示了后果：85% 的受访者说，瓶颈已经从写代码转移到了审代码。
合并就是一份合同。一次变更落入主分支的那一刻，意味着一个承诺：这个模块行为正确，边界清晰，不会拖垮依赖它的服务。然而，大多数工程组织从来没有把这份合同写下来。他们有一条运行检查的流水线，检查覆盖了什么，合并就承诺了什么。你如果去问，一个 PR 上的绿色对勾到底保证了哪些事情，很少能得到精确的回答。
把工具剥离掉，一次变更在组织可以在其上构建之前，需要建立四层信心。
第一层，它形态良好。能编译，通过代码风格检查与静态分析，产出可部署的制品。第二层，它内部逻辑正确。单元测试确认逻辑符合作者的意图，在隔离状态下、用桩替换掉依赖来验证。第三层，它在边界上兼容。遵守消费者依赖的 API 合约，符合生产者发出的数据模式。
第四层，也是分布式系统中最要紧的一层：它在真实系统中行为正确。这不仅包括功能行为——返回正确结果、遵循相邻服务预期的流程；也包括非功能行为——在真实流量下的延迟、错误率、资源消耗、向后兼容性。这一层的检查不是针对模拟对象或录制的固定数据，而是针对它调用的服务的实时版本和调用它的服务的实时版本，带着真实的数据形态和真实的故障模式。
前三个层级的检查很便宜。不需要环境，可以轻松并行，几分钟内就能完成。第四层是昂贵的，因为它需要一个真实运行的地方。而恰恰是这第四层，才能捕获那类在微服务架构中真正造成伤害的缺陷：局部正确，但在系统层面是错误的变更。
当编码代理把 PR 的产量推向新高，模糊的合同变得不再可行。组织开始意识到，如果不在合并之前明确那份合同到底包含什么，每一个绿灯都可能只是一个局部正确的假象。85% 的人卡在审查上，不是因为审查的人力不够，而是因为想要手动补齐第四层信心的成本太高。流水线自动覆盖的前三层，已经无法满足分布式系统对稳定性的要求。
这份四层信心模型给出了一个清晰的方向。如果团队能把第四层检查也做进自动化流水线里——用真实服务的临场环境而不是模拟——那么合并合同就可以被显式定义下来。到那时，一个绿色对勾不再是一句模糊的承诺，而是一份精确的保证：它形态良好、内部正确、边界兼容，并且在真实系统中行为正确。这会让审查的瓶颈大幅收窄，因为人工不再需要去猜测系统级影响。
从人的速度，到代理的速度，行业的工程实践正在经历一次基础设施级别的洗牌。把合并合同显式地写下来，诚实地审视今天的流水线在哪些地方达不到这份合同，正是接下来必须做的工作。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
