导语：
截至 2026 年 3 月 15 日，后端平台团队最需要警惕的，不是某个组件单独升级，而是多个基础设施窗口正在重叠。Kubernetes v1.35.3 已在 3 月 11 日发布；GitHub 对 self-hosted runner 的最低版本要求将在 3 月 16 日正式生效，必须不低于 v2.329.0；而 GitHub Actions runners 默认转向 Node24 的节奏也已经进入执行期。
这意味着从 3 月中旬开始，很多平台问题看上去像“某个 CI 任务失败”，本质上却可能是 runner 版本、构建脚本、Node 运行时和平台补丁叠加导致的。
1. 为什么这种窗口期最容易出事故
- 因为基础设施变更由不同团队分别推进，缺乏统一台账。
- 因为很多仓库的 workflow 和 action 版本并不透明。
- 因为平台团队往往先看到构建报错，业务团队最后才看到交付延迟。
2. 现在最适合采用的联合治理框架
- 版本台账统一
Kubernetes、runner、Node 运行时、基础镜像必须放到同一看板。 - 流水线回放统一
核心 workflow 要能在候选环境预演，而不是直接等线上爆。 - 回滚路径统一
任何平台升级都要保留旧版本镜像和替代 runner 池。
3. 推荐执行流程
- 拉齐 self-hosted runner 清单。
- 找出低于 v2.329.0 的节点并优先替换。
- 检查依赖 Node20 的自定义 action 与脚本。
- 在预发集群验证 Kubernetes 1.35.3 升级副作用。
- 对关键流水线做真实样本回放。
- 监控构建失败率、排队时长、缓存命中率和业务发布时延。
- 为高风险仓库预设快速切回方案。
4. 值得直接执行的检查清单
- Runner 是否还能自动更新，还是需要重建镜像。
- 自定义 action 是否隐式绑定旧 Node 版本。
- 平台补丁是否影响网络策略、存储挂载或调度性能。
- 计费模型变化是否导致 runner 调度策略需要重写。
5. 指标建议
- 旧 runner 清理完成率。
- 关键流水线成功率与平均时长。
- 队列等待时间。
- 平台升级后的业务发布延迟。
- 回滚成功率和恢复时长。
6. 结语
后端平台在窗口期最怕的不是升级本身，而是“分散升级”。把 Kubernetes、runner、Node 和构建镜像合并成同一个变更单元，才是 2026 年 3 月中旬平台团队该有的工作方式。
参考资料
- Kubernetes: v1.35.3 is now available（2026-03-11）
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md#v1353 - GitHub Changelog: Self-hosted runner minimum version enforcement extended（2026-02-05）
https://github.blog/changelog/2026-02-05-github-actions-self-hosted-runner-minimum-version-enforcement-extended/ - GitHub Changelog: Deprecation of Node 20 on GitHub Actions runners
https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
