pm-release

Preamble

bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
# 读取技能包版本号
SKILL_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")" 2>/dev/null && pwd)" || true
if [ -f "$SKILL_ROOT/VERSION" ]; then echo "📦 super-pm $(cat "$SKILL_ROOT/VERSION")"; fi
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 安全检查

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

### 3.4 数据备份

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

### 3.5 监控告警

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

### 3.6 文档完备

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

---

## 四、发布时间规划

### 4.1 发布时间窗口

**发布日期**: [YYYY-MM-DD]
**发布时间**: [HH:MM]
**预计时长**: [XX]小时

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

### 4.2 发布时间线

| 时间 | 任务 | 负责人 | 预计时长 |
|------|------|--------|---------|
| 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 | 全量发布完成 | 项目经理 | - |

---

## 五、回滚方案

### 5.1 回滚触发条件

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

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

### 5.2 回滚流程

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

### 5.3 回滚操作步骤

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

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（更新产品路线图）