pm-release

name	pm-release
description	Use when: 风险管控完成后准备上线发布、需要制定上线检查清单与回滚方案、正式发版流程 Do NOT use when: 上线流程已标准化且由运维自动化执行、仅需简单发布无需检查清单
allowed-tools	["Agent","Read","Write","AskUserQuestion","Bash"]

Preamble

bash "$(dirname "${BASH_SOURCE[0]}")/../../check-update.sh" 2>/dev/null || true
mkdir -p docs/04-风控管理

echo "🚀 上线执行方案制定工具已启动"

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。
2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。
3. 一次只问一个问题。
4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。
5. 不得在用户回答前生成文档、写入 docs。
6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 1: 确定上线策略

使用 AskUserQuestion:

📦 上线策略选择

选择本次上线的方式：

A) 全量发布（一次性上线所有用户） B) 灰度发布（逐步放开用户比例） C) 蓝绿部署（新旧版本并行） D) 金丝雀发布（小流量验证）

继续询问：

🌍 环境部署策略

需要在哪些环境部署？

A) 仅生产环境 B) 测试环境 → 生产环境 C) 开发环境 → 测试环境 → 预发布环境 → 生产环境 D) 自定义环境流程

步骤 2: 制定上线检查清单

使用 AskUserQuestion:

✅ 上线检查项

必须检查哪些项目？（可多选）

A) 功能测试（核心功能验证） B) 性能测试（压力测试、容量验证） C) 安全检查（漏洞扫描、权限验证） D) 兼容性测试（多端、多浏览器） E) 数据备份（数据库、配置文件） F) 监控告警（日志、指标、告警规则） G) 文档完备（用户手册、运维文档） H) 全部检查

步骤 3: 规划发布时间

使用 AskUserQuestion:

⏰ 发布时间窗口

选择合适的发布时间：

A) 工作日白天（便于快速响应问题） B) 工作日夜间（用户量少，影响小） C) 周末夜间（最低峰时段） D) 根据业务特点灵活选择

继续询问：

📅 发布节奏

发布频率是？

A) 单次发布（一次性完成） B) 分阶段发布（多个版本逐步上线） C) 持续发布（多次迭代，持续优化）

步骤 4: 设计回滚方案

使用 AskUserQuestion:

🔙 回滚触发条件

什么情况下需要回滚？

A) 严重Bug导致功能不可用 B) 性能严重下降（响应时间、错误率） C) 用户投诉激增 D) 数据异常（关键指标暴跌） E) 以上全部情况

继续询问：

⏱️ 回滚时间要求

从决定回滚到完成回滚，最长可接受时间：

A) 5分钟内（快速回滚） B) 15分钟内（标准回滚） C) 30分钟内（慢速回滚） D) 1小时内（可接受）

步骤 5: 规划通知机制

使用 AskUserQuestion:

📢 上线通知对象

需要通知哪些人？（可多选）

A) 内部团队（产品、研发、测试、运营） B) 管理层（项目发起人、部门负责人） C) 外部用户（发布公告、更新日志） D) 合作伙伴（第三方服务、渠道方） E) 客服团队（提前准备FAQ）

步骤 6: 生成上线执行方案

使用 Write 工具生成 docs/04-风控管理/上线执行方案.md。

---

Subagent 并行加速（v2.0.0 新增）

利用 Agent 工具并行执行独立子任务，大幅缩短总执行时间。

可并行子任务

当步骤1-3的用户信息收集完成后，以下两个任务可以并行执行：

子任务	说明
检查清单编排	基于上线策略和检查项，自动生成完整上线检查清单
回滚方案设计	根据回滚触发条件和时间要求，输出回滚操作步骤

触发方式

在步骤6生成文档前，使用 Agent 工具激活子任务并行执行。

V1 vs V2 对比

维度	V1.1.0（串行）	V2.0.0（Subagent并行）	节省
检查清单	用户逐一确认检查项	Agent并行生成完整清单	约3轮交互
回滚方案	依次询问回滚细节	Agent自动输出回滚步骤	约2轮交互
通知机制设计	逐个问询通知对象	Agent并行编排通知方案	约2轮交互
总交互轮次	约12-15轮	约6-8轮	减少50%+
耗时估算	12-18分钟	6-9分钟	节省约8分钟

---

输出文件

上线执行方案 → docs/04-风控管理/上线执行方案.md

---

输出文档模板

# 上线执行方案

## 一、上线概况

- **上线策略**: [从步骤1提取]
- **环境部署**: [从步骤1提取]
- **发布时间**: [从步骤3提取]
- **回滚要求**: [从步骤4提取]
- **生成时间**: [当前时间]

---

## 二、上线策略

### 2.1 发布方式

**策略**: [从步骤1提取]

**选择理由**:
- [说明为什么选择此策略]
- [适用的场景]

### 2.2 灰度发布计划（如适用）

**阶段划分**:
- **阶段1**: 1% 用户（内部用户、白名单）
- **阶段2**: 10% 用户（观察期：24小时）
- **阶段3**: 50% 用户（观察期：12小时）
- **阶段4**: 100% 用户（全量发布）

**观察指标**:
- 错误率 < 1%
- 平均响应时间 < 500ms
- 用户投诉数 < 5起/小时

### 2.3 蓝绿部署方案（如适用）

**环境准备**:
- Blue环境：当前生产版本
- Green环境：新版本

**切换流程**:
1. 部署Green环境
2. 健康检查通过
3. 切换流量到Green
4. Blue环境待命（可快速回滚）

---

## 三、上线检查清单

### 3.1 功能测试

| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 核心功能验证 | 所有P0功能正常 | 测试负责人 | ⏳ 待测试 |
| 边界条件测试 | 异常情况处理正确 | 测试负责人 | ⏳ 待测试 |
| 兼容性测试 | 主流浏览器、设备正常 | 测试负责人 | ⏳ 待测试 |
| 回归测试 | 无严重Bug | 测试负责人 | ⏳ 待测试 |

### 3.2 性能测试

| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 压力测试 | 支持[XX]并发用户 | 性能工程师 | ⏳ 待测试 |
| 容量验证 | CPU < 70%，内存 < 80% | 运维工程师 | ⏳ 待验证 |
| 响应时间 | 平均 < 500ms，P99 < 2s | 性能工程师 | ⏳ 待测试 |
| 数据库性能 | 慢查询 < 1% | DBA | ⏳ 待验证 |

### 3.3 安全检查

| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 漏洞扫描 | 无高危漏洞 | 安全工程师 | ⏳ 待扫描 |
| 权限验证 | 越权访问测试通过 | 安全工程师 | ⏳ 待验证 |
| 数据加密 | 敏感数据加密存储 | 研发负责人 | ⏳ 待确认 |
| 日志脱敏 | 日志中无明文敏感信息 | 研发负责人 | ⏳ 待确认 |



| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 数据库备份 | 全量备份完成 | DBA | ⏳ 待备份 |
| 配置文件备份 | 配置已备份到Git | 运维工程师 | ⏳ 待备份 |
| 回滚脚本准备 | 回滚脚本验证通过 | 研发负责人 | ⏳ 待准备 |



| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 日志监控 | 日志正常输出 | 运维工程师 | ⏳ 待验证 |
| 指标监控 | Grafana面板配置完成 | 运维工程师 | ⏳ 待配置 |
| 告警规则 | 关键指标告警配置完成 | 运维工程师 | ⏳ 待配置 |
| 值班人员 | 上线期间有人值班 | 项目经理 | ⏳ 待安排 |



| 检查项 | 验收标准 | 负责人 | 状态 |
|--------|---------|--------|------|
| 用户手册 | 更新用户操作文档 | 产品负责人 | ⏳ 待完成 |
| 运维文档 | 更新部署、配置文档 | 运维工程师 | ⏳ 待完成 |
| API文档 | 更新接口文档 | 研发负责人 | ⏳ 待完成 |
| 更新日志 | CHANGELOG已更新 | 产品负责人 | ⏳ 待完成 |

---





: [YYYY-MM-DD]
: [HH:MM]
: [XX]小时

:
 [为什么选择这个时间]
 [用户访问低峰期/业务低峰期]



| 时间 | 任务 | 负责人 | 预计时长 |
|------|------|--------|---------|
| T-2h | 最终检查清单确认 | 项目经理 | 30分钟 |
| T-1h | 团队就位，最后一次同步 | 项目经理 | 15分钟 |
| T-0 | 开始上线 | 运维工程师 | - |
| T+0.5h | 环境部署、配置更新 | 运维工程师 | 30分钟 |
| T+1h | 功能验证（冒烟测试） | 测试负责人 | 30分钟 |
| T+1.5h | 监控指标观察 | 运维工程师 | 30分钟 |
| T+2h | 发布通知 | 产品负责人 | 15分钟 |
| T+4h | 灰度放开至10%（如适用） | 运维工程师 | - |
| T+24h | 全量发布完成 | 项目经理 | - |

---





（红色预警）:
 ✅ 严重Bug导致核心功能不可用
 ✅ 错误率 > 5%
 ✅ 响应时间 > 5s
 ✅ 数据丢失或损坏

（黄色预警）:
 ⚠️ 性能下降明显（响应时间 > 1s）
 ⚠️ 用户投诉 > 10起/小时
 ⚠️ 关键指标下降 > 20%

发现问题 → 评估严重程度 → 决定是否回滚 ↓ 通知相关人员（项目经理、技术负责人） ↓ 执行回滚操作 ↓ 验证回滚成功 ↓ 复盘分析

### 5.3 回滚操作步骤

#### 方式1：代码回滚

```bash
# 1. 切换到稳定版本分支
git checkout [稳定版本tag]

# 2. 重新构建
npm run build

# 3. 部署
kubectl set image deployment/app app=[新镜像]

# 4. 验证
curl -I https://app.example.com/health

方式2：数据库回滚

# 1. 停止应用写入
kubectl scale deployment/app --replicas=0

# 2. 恢复数据库
mysql -u root -p < /backup/backup_YYYYMMDD.sql

# 3. 验证数据完整性
mysql -u root -p -e "SELECT COUNT(*) FROM users;"

# 4. 重启应用
kubectl scale deployment/app --replicas=3

方式3：配置回滚

# 1. 恢复配置文件
kubectl rollout undo deployment/app

# 2. 验证配置
kubectl get configmap app-config -o yaml

# 3. 重启应用
kubectl rollout restart deployment/app

5.4 回滚时间要求

目标: [从步骤4提取]

快速回滚清单:

• 回滚脚本已准备并验证
• 数据库备份可快速恢复
• 配置文件版本化管理
• 回滚演练已进行

---

六、通知机制

6.1 上线前通知

通知时间: 上线前[XX]小时

通知对象: [从步骤5提取]

通知内容:

【上线通知】
项目：[项目名称]
版本：[版本号]
时间：[YYYY-MM-DD HH:MM]
变更内容：[简要说明]
影响范围：[用户/功能]
联系人：[姓名+电话]

6.2 上线中通知

通知节点:

• 上线开始
• 关键步骤完成
• 遇到问题
• 上线完成

通知渠道:

• 项目群（实时同步）
• 邮件（重要节点）
• 短信（紧急情况）

6.3 上线后通知

通知时间: 上线完成后[XX]小时内

通知对象:

• 内部团队（项目群）
• 管理层（邮件）
• 外部用户（公告、推送）
• 客服团队（FAQ文档）

通知内容:

【上线成功通知】
项目：[项目名称]
版本：[版本号]
上线时间：[YYYY-MM-DD HH:MM]
新增功能：[功能列表]
优化改进：[改进点]
问题修复：[修复内容]
已知问题：[如有]
反馈渠道：[联系方式]

---

七、监控与告警

7.1 监控指标

应用层:

• 请求量（QPS）
• 错误率（5xx比例）
• 响应时间（P50、P95、P99）
• 并发数

系统层:

• CPU使用率
• 内存使用率
• 磁盘I/O
• 网络流量

业务层:

• 用户活跃数
• 核心功能使用率
• 转化率
• 客单价

7.2 告警规则

指标	阈值	级别	通知方式
错误率	> 1%	黄色	项目群
错误率	> 5%	红色	电话+项目群
响应时间	> 2s	黄色	项目群
CPU使用率	> 80%	黄色	项目群
内存使用率	> 90%	红色	电话+项目群

7.3 监控面板

监控工具: Grafana / 阿里云监控 / 自建监控

监控看板:

• 实时流量看板
• 错误监控看板
• 性能监控看板
• 业务指标看板

---

八、应急响应

8.1 应急联系人

角色	姓名	电话	职责
项目经理	[姓名]	[电话]	总协调
技术负责人	[姓名]	[电话]	技术决策
运维负责人	[姓名]	[电话]	系统运维
测试负责人	[姓名]	[电话]	质量保障
产品负责人	[姓名]	[电话]	业务决策

8.2 应急响应流程

发现问题 → 初步评估（5分钟内）
  ↓
通知相关人员 → 问题定位（15分钟内）
  ↓
制定方案 → 方案执行（30分钟内）
  ↓
验证结果 → 问题解决
  ↓
复盘总结

8.3 问题分级

P0 - 致命问题:

• 核心功能不可用
• 数据丢失
• 安全漏洞

响应: 立即处理，所有人停下手头工作

P1 - 严重问题:

• 主要功能异常
• 性能严重下降
• 影响大量用户

响应: 1小时内处理，指定专人负责

P2 - 一般问题:

• 次要功能异常
• 影响少量用户

响应: 24小时内处理，排入迭代计划

---

九、上线复盘

9.1 复盘时间

复盘会议: 上线后[XX]天内

参与者:

• 项目经理
• 技术负责人
• 测试负责人
• 产品负责人
• 运维负责人

9.2 复盘内容

过程回顾:

• 上线流程是否顺畅
• 检查清单是否完备
• 协作是否高效

问题分析:

• 遇到了哪些问题
• 问题原因分析
• 如何避免类似问题

改进措施:

• 流程优化建议
• 工具改进建议
• 文档完善建议

9.3 复盘输出

复盘报告:

• 上线概况
• 问题清单
• 改进措施
• 经验总结

---

十、下一步建议

建议执行：

1. /pm-change（建立变更管理机制）
2. /pm-retro（进行迭代复盘）
3. /pm-roadmap（更新产品路线图）

---

输出质量对比

✅ Good 示例：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

❌ Bad 示例：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

---

常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

误区	正确做法
使用"应该"、"大概"、"看起来"做结论	必须基于实际数据和验证
未运行检查就声称已完成	先验证，再陈述
因时间紧迫跳过关键步骤	没有例外，时间紧更要严格
"这次应该没问题"的想法	每次都要重新验证

---

产出质量检查 / Verification Checklist

• 前置依赖已满足（输入文档/数据已收集）
• 核心步骤已全部执行
• 输出文档已生成到 docs/ 目录
• 每个判断都有数据/证据支撑
• 已推荐 2-3 个后续 skill

⚠️ 任何一项未通过 → 补全后再标记完成。

---

项目状态: 上线执行方案已制定 生成时间: [时间戳] 生成工具: super-pm

---

## 推荐下一步

执行完成后，输出：

✅ 上线执行方案已生成！

🎯 建议下一步：
1. /pm-change（建立变更管理机制）
2. /pm-retro（进行迭代复盘）
3. /pm-roadmap（更新产品路线图）