现象:同一份代码,构建结果时好时坏
未改任何代码,重跑一次 CI 就能过,这种“随机失败”比固定报错更难排查,因为很多人下意识会去查代码逻辑,而真正的误因往往在运行环境。
为什么“随机失败”最难排查
三个定位技巧
第一,把失败的 job 重跑 5-10 次,看失败比例与失败时间段是否集中,如果集中在特定时段,大概率是链路拥堵;第二,逐行看日志时间戳,定位失败步骤前后的耗时是否异常拉长,一般依赖下载、镜像拉取这类步骤最容易受网络影响;第三,为关键步骤单独加细粒度 timeout 和重试日志,把“整体超时”拆解成“具体哪一步超时”。
网络抖动是常见误因之一
使用自托管 Runner 时,Runner 机器自身的出口链路质量直接决定了拉取依赖、拉取镜像、访问外部 API 的稳定性;即便用 GitHub 自带的托管 Runner,不同地区的 Runner 访问企业自建的区域专用 API 网关等内部服务时也会有延迟差异,这些都会表现为“有时过有时不过”。
优化方案对比
| 方案 | 解决什么 | 局限 |
|---|---|---|
| 关键步骤加自动重试 | 容忍偶发性超时 | 不解决根本网络问题,只是掉包重试 |
| 换本地镜像源 | 减少部分依赖拉取耗时 | 私有包、访问外部API仍需要国际出口 |
| 提升自托管Runner出口链路质量 | 从根上降低丢包与延迟波动 | 需要接入稳定专线,自建宽带可能不够 |
NasaCode 对自托管 Runner 的优化
如果团队自建了 self-hosted Runner,建议让 Runner 机器接入 NasaCode 的国际专线,把拉取依赖、访问外部 API 这类对延迟丢包敏感的环节放在低丢包链路上,能明显降低因网络抖动导致的构建随机失败比例。
常见问题
GitHub 自带的 hosted Runner 也会受网络影响吗?
会。它自身到 GitHub 基础设施的链路很稳,但它再去访问你企业自建的内部服务或非主流镜像源,还得经过国际链路,同样会受影响。
重试机制会不会掩盖真实的代码问题?
会。重试只应用在确定与代码无关的网络依赖步骤上,如果测试本身的失败也被自动重试遮盖,会造成缺陷漏网。
