流水线很强大，出事也很大
流水线自动跑，一旦配错或被人利用，后果被自动化放大了：坏代码自动部署上线、密钥泄漏、流水线被恶意触发。这一节讲流水线的安全与失败恢复。
自动化程度越高，安全与恢复越重要。
流水线的安全：先防三类风险
| 风险 | 后果 | 对策 |
|---|---|---|
| 密钥泄漏 | 模型 Key 暴露 | 用 Secret，别明文 |
| 坏代码上线 | 测试没拦住，自动部署 | 测试 + 门禁 + 人工确认 |
| 被恶意利用 | 流水线被乱触发 | 限制触发源、审核改动 |
三个风险，每一个都可能导致严重事故。
对 deploy-bot 这三条风险尤其重：它手里有部署密钥、它能把代码部署到生产、它也可能被恶意 PR 触发乱部署。每一条都要先防住，再谈效率。
安全实践清单
- 密钥进 Secret：模型 Key、凭据放平台 Secret，运行时注入
- 限制触发：只对可信来源（如受保护分支）开放自动部署
- 改动审查：流水线配置变更也走评审，别一个人悄悄改
- 最小权限：流水线用什么权限就配什么，别给超管
流水线配置本身，也要当「重要代码」对待。
对 deploy-bot，把这些落到部署场景：
deploy-bot 安全清单
- 部署密钥放 Secret，staging/production 分开，不落库
- 自动部署只对受保护分支（main）开放，其它分支不触发部署
- workflow 文件变更走 PR + 评审，别直接 push 主分支
- deploy-bot 用的 token 只给「部署 + 上报」最小权限，不给仓库写权限/超管
失败恢复：别让流水线「卡死一切」
流水线失败是常态，关键是失败后能恢复，而不是把所有人都卡住：
1. 失败要可定位
失败时要能快速看到「哪一步、为什么挂」——靠良好的日志和阶段划分。
对 deploy-bot：部署失败时，日志要能立刻指出「测试挂了 / 构建挂了 / staging 部署挂了 / production 挂了」哪一环。
2. 失败能回滚
部署坏了，要能回到上一个稳定版本，而不是卡在生产坏代码上。
对 deploy-bot 这是底线：每次部署前记录上一稳定版本，失败就触发回滚，别让线上一直跑着坏代码。
3. 失败别蔓延
一个环节失败，别让后续环节硬跑；关键发布，失败就停、别继续。
对 deploy-bot：production 部署失败，立即停止后续动作并告警，别让它在半坏的状态下继续叠操作。
一个失败恢复流程
流水线失败
→ 快速定位：哪一步挂的？（看日志）
→ 判断影响：是测试挂了，还是已经部署了？
→ 部署了坏了 → 回滚到上一稳定版
→ 修复问题 → 重新触发流水线
定位 → 判断影响 → 回滚/修复 → 重跑，一套流程。
放到 deploy-bot 的一次 production 事故上：
deploy-bot 部署 production 失败
→ 定位：staging 验收过了，production 部署这步挂了（看日志）
→ 影响：坏代码已部署到 production，线上在跑坏版本
→ 回滚：立即回滚到上一稳定版本，恢复线上
→ 修复：查清 production 部署失败原因，修好后再重新触发
灰度与小步
高风险发布，别一把梭：
- 灰度：先小范围部署，观察没问题再全量
- 小步：一次只发一部分改动，别堆一大坨上线
稳，比快重要。
对 deploy-bot 的 production 部署，灰度尤其该用：先部署给 10% 流量观察，没问题再全量。配合「回滚按钮」，真出问题也能快速退出。
常见坑：部署失败后不立即回滚，坏代码一直跑线上
失败恢复里最容易犯的坑，不是「没预案」，而是「预案不执行」——部署失败了，却放任坏代码继续在线上跑。
真实场景：deploy-bot 部署 production 时某步失败，但配置里没写「失败自动回滚」。你以为「先看看情况」，结果坏代码一直在生产线上被用户访问，问题越滚越大，最后只能仓促补救。
为什么：production 是高风险环境，「先观察」等于「让用户替你踩雷」。部署失败的那一刻，回滚窗口最宝贵，越拖代价越大。
怎么破：deploy-bot 的 production 部署默认失败即回滚到上一稳定版，把这写进脚本和流程，而不是靠人临时决定；回滚本身也要有验证（回滚后确认线上恢复正常）。把「失败→回滚」固化成自动动作，而不是一次性的临时操作。
小结
- 自动化放大后果：安全与恢复必须跟上
- 防三险：密钥泄漏、坏代码上线、被恶意利用
- 失败恢复：可定位、可回滚、别蔓延
- 高风险发布：灰度 + 小步，稳比快重要
下一模块进入「规模化与质量」。