发布流水线流量增长前要补哪些防线
发布系统在流量增长时，承受的不只是构建次数增加。代码仓库、构建运行器、制品库、镜像仓库、部署控制器和集群 API 都可能成为瓶颈。没有容量边界，某次高峰提交或事故期间的紧急修复，会让本该帮助恢复的流水线先陷入排队。
入口要分级和限额
区分常规构建、合并后的发布、定时任务和紧急变更。为每类任务设置并发、队列长度和超时，并明确队列满时是延迟、拒绝还是由人工处理。构建任务应可以取消；已经不对应当前提交的任务不要继续消耗运行器。针对同一分支或环境，合并重复触发能避免无意义的资源竞争。
concurrency: group: deploy-production cancel-in-progress: false生产发布通常不应随意取消进行中的步骤，但这个配置并不取代互斥与状态核对。部署前后都要确认目标版本和环境状态，避免两个流水线同时修改同一资源。对可并行的测试，则可以采用独立的并发组和资源配额。
保护供应链和部署入口
运行器默认不应持有生产权限。构建使用短期凭据，制品使用摘要标识，部署只接受经过签名或受控仓库批准的版本。依赖下载、镜像拉取和漏洞扫描也应设超时、缓存与失败策略；缓存键必须包含依赖锁文件，不能让旧依赖悄悄进入新构建。
部署控制器需要限制单次变更范围，配合就绪检查、灰度和回退。数据库迁移、消息格式和权限变更要有单独的发布顺序，不能指望应用滚动更新自动解决兼容性。紧急通道应保留，但要求更严格的审计与事后复核，而不是绕过全部检查。
让队列状态可见
监控等待时间、取消率、运行器利用率、构建失败分类、制品下载失败和部署持续时间。报警后能够回答任务卡在哪个依赖、是否可安全取消、由谁处理。定期用高提交量、制品仓库慢和集群 API 限流的场景演练，验证队列恢复后不会错误发布过期版本。
流水线的价值是稳定交付，不是让每个触发都立刻运行。先保护生产环境、控制副作用，再追求更快的吞吐，增长才不会把交付链路变成新的风险点。
还要处理依赖的公平性：一个大型仓库或错误配置的循环触发不能长期占满全部运行器。按项目、环境或优先级设置配额，并把排队位置展示给提交者。这样团队在紧急修复时知道该等待、取消还是走受控的升级流程。
定期清理过期制品、废弃环境和临时凭据，但清理动作同样需要范围限制和审计。容量增长不是只增加机器；不受控的历史数据与权限，也会让发布平台越来越脆弱。
恢复演练结束后核对已发布版本与队列状态，避免恢复阶段意外执行过期任务。
记录结果。
