Shipping Launch Zh

---
name: shipping-launch-zh
description: 上线发布、生产部署前检查、灰度放量、特性开关生命周期、监控与回滚、错误预算门禁。当用户说「明天要上线，要准备什么」「给我一份发布前清单」「怎么灰度」「回滚方案怎么写」「上线后第一小时看什么」「错误预算用完了还能发吗」时使用。内容：发布前六类清单（代码质量、安全、性能、无障碍、基础设施、文档）；开关生命周期（部署关着 → 内部 → 5%→25%→50%→100% → 两周内删）；放量决策阈值表（错误率/P95/客户端错误/业务指标的绿黄红）；何时立即回滚；监控三层与错误上报；上线后一小时六件事；错误预算门禁；回滚方案模板与时间预期。改编自 addyosmani/agent-skills 的 shipping-and-launch（MIT）。
author: Captain
version: 0.1.0
display_name: "上线发布（清单·灰度·回滚）"
display_name_en: "Shipping & Launch (zh)"
description_zh: "可逆、可观测、渐进地发布：六类发布前清单、开关生命周期、灰度放量的绿黄红阈值、立即回滚条件、上线后一小时检查、错误预算门禁、回滚方案模板。"
description_en: "Ship reversibly, observably and incrementally: six pre-launch checklists, flag lifecycle, green/yellow/red rollout thresholds, immediate-rollback triggers, first-hour checks, error-budget gate, rollback plan template."
examples_zh:
  - "周四上线新的结算流程，帮我列发布前检查和回滚方案"
  - "灰度到 25% 时错误率涨了 30%，该继续还是停"
  - "写一份这个功能的回滚方案"
examples_en:
  - "We ship the new checkout Thursday, give me the pre-launch checks and rollback plan"
  - "Error rate is up 30% at 25% rollout, advance or hold"
  - "Write the rollback plan for this feature"
metadata:
  { "openclaw": { "requires": { "bins": [] }, "os": ["darwin", "linux", "windows"], "emoji": "🚀" } }
---

# 上线发布

目标不只是部署，是**安全地**部署：监控就位、回滚就绪、成功有定义。每次发布都应可逆、可观测、渐进。（与本系列「上线检查清单」的区别：那个从 diff 生成本次变更的影响面清单；这个是发布过程本身的通用纪律。）

## 发布前清单
- **代码质量**：单元/集成/E2E 全过；构建无警告；lint 与类型通过；已评审；无该上线前解决的 TODO；无调试输出；错误处理覆盖预期失败。
- **安全**：无密钥入库；依赖审计无严重/高危；面向用户端点有输入校验；认证授权就位；安全头；鉴权端点限流；CORS 限定。
- **性能**：Web Vitals 达标；关键路径无 N+1；图片优化；包体积在预算内；查询有索引；静态资源与重复查询有缓存。
- **无障碍**：键盘可达；读屏可理解；对比度 4.5:1；弹窗与动态内容焦点管理；表单错误与字段关联；axe/Lighthouse 无警告。
- **基础设施**：生产环境变量；迁移已应用或就绪；DNS 与证书；CDN；日志与错误上报；健康检查端点。
- **文档**：README 新的安装要求；API 文档；ADR；changelog；用户文档。

## 特性开关
部署与发布解耦。生命周期：**部署（开关关）**→ **内部/beta 启用** → **渐进 5% → 25% → 50% → 100%** → **每阶段监控** → **全量后两周内删除开关与死代码**。规则：每个开关有负责人与过期日；不嵌套开关（组合爆炸）；CI 同时测开与关两种状态。

## 分阶段放量
1. 部署预发：全量测试 + 关键流程手工冒烟。2. 部署生产（开关关）：健康检查、无新错误。3. 团队启用：内部用 24 小时。4. 金丝雀 5%：对比错误率、时延、行为，24–48 小时，阈值全绿才前进。5. 25% → 50% → 100%，每步同样监控，随时可回到上一比例。6. 全量后观察一周，清理开关。

**放量决策阈值**

| 指标 | 前进（绿） | 暂停调查（黄） | 回滚（红） |
|---|---|---|---|
| 错误率 | 基线 ±10% | 高于基线 10–100% | > 2 倍基线 |
| P95 时延 | 基线 +20% 内 | +20–50% | > +50% |
| 客户端 JS 错误 | 无新错误类型 | 新错误 < 0.1% 会话 | 新错误 > 0.1% 会话 |
| 业务指标 | 持平或上升 | 下降 < 5%（可能是噪声） | 下降 > 5% |

**立即回滚**：错误率 > 2 倍基线；P95 > +50%；用户反馈激增；数据完整性问题；发现安全漏洞。

## 监控
应用：错误率（总与分端点）、响应时间 p50/p95/p99、请求量、活跃用户、关键业务指标。基础设施：CPU/内存、连接池、磁盘、网络、队列深度。客户端：Web Vitals、JS 错误、客户端视角的 API 错误率、页面加载。错误上报：前端错误边界上报（组件栈、用户、页面）；服务端错误中间件上报（方法、URL、用户）并对用户只返回通用错误。
**上线后一小时**：健康检查 200 → 错误看板无新错误类型 → 时延无回退 → 手工走关键流程 → 日志在流动且可读 → 回滚机制可用（能演练就演练）。

## 错误预算门禁
剩余 > 20% → 正常发布、密切监控；0–20% → 只允许慢放量、不上高风险变更；耗尽 → 冻结功能工作、全力可靠性；恢复后按正常节奏并把恢复它的修复固化。金丝雀期间**燃烧率**高于基线是暂停信号，即使单项阈值都绿。

## 回滚方案模板
```
## <功能/版本> 回滚方案
触发条件：错误率 > 2×基线 / P95 > Xms / 用户报告 <具体问题>
步骤：1. 关开关（如有）或部署上一版本  2. 验证：健康检查、错误监控  3. 通知团队
数据库：迁移 X 有回滚命令；新功能写入的数据 保留/清理
预期耗时：开关 < 1 分钟；重新部署 < 5 分钟；数据库回滚 < 15 分钟
```

## 合理化借口对照

| 借口 | 现实 |
|---|---|
| "预发好的，生产也会好" | 生产的数据、流量、边界不同；部署后监控 |
| "这个不用开关" | 每个功能都受益于一个急停键 |
| "监控是负担" | 没监控就是靠用户投诉发现问题 |
| "监控以后加" | 上线前加；看不见的东西没法排查 |
| "回滚等于承认失败" | 回滚是负责任的工程；发布坏功能才是失败 |
| "错误率看着还行，继续发" | 看燃烧率不只看当前值；比基线烧得快就是暂停信号 |

## 红灯
没有回滚方案就部署；生产无监控与错误上报；大爆炸式发布；开关无过期无负责人；上线后第一小时没人盯；生产配置靠记忆不靠代码；"周五下午，发吧"；错误预算耗尽功能工作照旧。

## 验收
部署前：清单全绿；开关已配置；回滚方案已写；监控看板就位；团队已通知。
部署后：健康检查 200；错误率正常；时延正常；关键流程可用；日志流动；回滚已测或就绪。
每个服务：有错误预算策略，知道低于 20% 与耗尽时各做什么。

---
改编自 [addyosmani/agent-skills](https://github.com/addyosmani/agent-skills) 的 `shipping-and-launch`（MIT）。改动见 ATTRIBUTION.md。