上个月一个朋友跟我吃饭，他在一家中型公司带基础架构团队。饭桌上他抱怨了一件事：他们的 CI 流水线在过去半年里，构建时间从 8 分钟涨到了 47 分钟，而且每周至少挂两次。他换了构建工具、加了并行度、优化了依赖缓存——效果都是暂时的，过几周又慢回去了。

我问他："你们这半年加了多少个微服务？"

他想了想说，大概从 12 个涨到了 30 多个。

"团队呢？"

"从 3 个组变成了 7 个组，有两个是新拆出来的。"

这就对了。他的 CI 不是被代码拖慢的，是被组织拖慢的。每次构建要拉 30 多个仓库的依赖、跑 7 个团队的集成测试、等 3 个不同审批流的门禁检查。流水线变慢，不是因为代码多了——是因为能影响构建的人多了，而没有人对"整条流水线"负责。

CI 的问题，十有八九是组织问题。

康威定律说过很多次了——系统的架构会映射组织的沟通结构。但很少有人注意到，CI/CD 流水线其实是一面更诚实的镜子。代码架构可以精心设计、可以假装解耦得很好，但流水线不会骗人。哪个模块和哪个模块真正独立、哪个团队和哪个团队其实绑在一起，看一遍 CI 的依赖图就知道了。

我后来帮他梳理了一下构建失败的原因，发现了一个很典型的模式：70% 的失败不是因为提交代码的那个团队，而是因为另一个团队的变更。A 组改了公共 SDK 的类型定义，B 组的编译就挂了。C 组升级了数据库 migration 脚本，D 组的集成测试就超时了。

这个模式在技术上叫"扇出依赖"。但从管理角度看，它暴露的是一个组织问题：没有人对集成点负责。每个团队对自己的模块负责，但模块之间的交接区是盲区。出了问题，A 说"我改了接口但没改你的调用"，B 说"你没通知我"。CI 挂了，大家的第一反应不是修，是看跟自己有没有关系。

这件事让我开始想一个问题：技术管理者是不是应该把 CI 当作一个组织诊断工具来用？

不是看"绿不绿"——那是工程师的事。而是看"在哪里挂"、"谁和谁总是一起挂"、"挂的时候大家在说什么"。

我整理了几种我见过的"CI 坏味道"，以及它们背后可能对应的组织问题：

坏味道一：构建时间持续膨胀。代码量增长是线性的，但构建时间如果是指数增长，说明耦合度在增加。不是代码层面的耦合——那个编译器和 linter 会告诉你。是组织层面的耦合：一个构建需要拉太多团队的上下文才能跑通。每多一个需要"顺便验证"的模块，就多一个隐性的协调成本。

坏味道二：频繁出现"不是我的错"型失败。CI 挂了，提交者说"我这边本地是好的"。然后查半天发现是另一个仓库的变更影响了公共依赖。这种失败模式如果每周出现超过两次，基本可以确定：团队之间的接口契约没有被管理起来。不是缺工具，是缺沟通机制。

坏味道三：没人敢说"可以跳过"。有些 CI 步骤已经失效了——比如某个安全扫描规则误报率 80%，但没人敢关掉它，因为"万一出事谁负责"。流水线越来越长，不是因为每个步骤都有价值，而是因为每个步骤背后都有一个不想承担风险的部门。CI 的臃肿，本质上是组织风险偏好的映射。

坏味道四：修复 CI 的人总是同一批。如果每次流水线挂了，最终去修的都是基础架构团队的某两个人，那说明 CI 的维护责任没有下沉到业务团队。这跟运维早期的"NOC 困境"很像——所有人都会制造问题，但只有少数人负责解决。时间一长，这批人要么离职，要么摆烂。

回到我朋友那个案例。他后来做了一件事，我觉得挺有意思的：他没有继续优化 CI 工具，而是拉了 7 个团队的 lead 一起看了一次 CI 失败的完整链路。不是复盘某次具体失败，而是把过去一个月的失败记录摊开来看——哪些是单团队内的失败（编译错误、单测失败），哪些是跨团队的失败（集成测试、依赖冲突）。

结果发现，跨团队失败占了 60%，但没有任何一个流程在处理这种失败。它就这么悬在那里，靠个人关系和即时通讯解决。

他后来设了一个"集成负责人"的轮值角色——每周一个人，不管来自哪个团队，专门处理跨团队的 CI 问题。不是什么高大上的架构治理，就是一个人盯着看板，发现跨团队失败了就拉相关人解决。三个月后，构建时间从 47 分钟降到了 22 分钟，每周失败次数从两次变成了偶尔一次。

有意思的是，这个轮值角色的副作用比预期大得多。不同团队的工程师第一次看到了"别人怎么用 CI"，也开始理解为什么自己的某些改动会影响别人。组织沟通的改善，居然是从修 CI 开始的。

我后来看了一些关于 DORA 指标的资料，发现四个指标里最容易被管理者忽略的不是部署频率或变更失败率，而是"恢复时间"（MTTR）。恢复时间长的团队，往往不是技术能力差，而是出了问题不知道该找谁。这跟 CI 的"不是我的错"型失败，其实是同一个组织问题。

还有一个数据让我印象挺深的。Gartner 2024 年的一个报告提到，在调研的企业中，超过 40% 的 CI/CD 故障与"非代码因素"有关——配置漂移、环境不一致、权限变更、依赖版本冲突。这些"非代码因素"，几乎每一项都跟组织协调有关。

所以我现在有一个不太成熟的判断：如果一个技术管理者想快速了解自己团队的健康度，不用做 360 评估，不用搞匿名调研——去看看 CI 流水线的失败日志就行了。失败集中在哪里，组织的裂缝就在哪里。

当然这个判断有局限性。CI 只能反映跟代码交付相关的协作问题，团队协作还有很多维度是 CI 看不到的——比如决策效率、信息透明度、跨职能沟通。但 CI 的好处是它不会骗人：代码可能写得漂亮但架构是假的，文档可能很完整但内容是空的，但流水线挂了就是挂了，没法包装。

那个朋友现在每次开技术管理周会，第一件事不是看业务指标，是看上周的 CI 失败分布。他说这比任何管理仪表盘都诚实。我不确定这个做法适合所有团队，但我觉得他这个思路方向是对的——流水线是一面镜子，照的不是代码，是人。