从 Docker Machine 退役说起：GitLab CI Runner 弹性架构与缓存治理的 7 个生产决策
概述 凌晨 1 点，你收到告警：GitLab CI 流水线队列堆积了 47 个 pending job。开发群炸了——“代码推了 40 分钟还没跑起来"“是不是 Runner 挂了"“赶紧加机器啊”。你登录控制台一看，3 个 Runner 全部满载，每个并发 10 个 job，30 个 slot 全占满了。加机器？Docker Machine 执行器拉起新 EC2 要 3 分钟，等机器 Ready 又要 2 分钟。5 分钟过去了，队列又涨了 20 个。 这不是假设。2025 年我在某出行项目做 CI/CD 平台重构时，就遇到过这个场景。当时的 Runner 架构是经典的 Docker Machine + AWS EC2 自动伸缩，高峰期排队 30-40 分钟是常态。后来我们迁移到 Kubernetes Executor + HPA 弹性伸缩，排队时间降到 30 秒以内。这中间踩了不少坑，也做了不少架构决策。 本文不讲 .gitlab-ci.yml 基础语法（那些 CSDN 上够多了），只聊 7 个真正影响生产效率的工程决策：执行器选型、资源规划、弹性伸缩、缓存设计、流水线编排、节点隔离、监控告警。每个决策都附实测数据和踩坑细节。 如果你在评估 CI/CD 平台选型，可以参考我之前的文章 相关文章：别让 Jenkins 决定你的发布节奏：用 Go 自研 DAG 调度引擎的架构决策与踩坑实录，里面对比了 Jenkins、GitLab CI 和自研调度引擎的差异。...