⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

⚠️ 安全警告：本技能的示例可能涉及发布决策、灰度方案和回滚操作。 实际使用时请勿直接执行发布或回滚，先确认审批权限、灰度比例和回滚预案。 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

发布风险管理

核心原则

发布决策不仅仅是"Bug都修完了没"，而是综合判断变更影响面、灰度策略、回滚能力。

发布风险评估矩阵

维度1：变更特征分析

变更范围：
├─ 代码变更量：新增/修改/删除行数
├─ 文件影响面：涉及多少文件
├─ 模块影响面：涉及多少模块
├─ 接口影响面：涉及多少接口
└─ 数据影响面：涉及多少数据表

风险等级：
- 大变更：>1000行/>20文件/>5模块
- 中变更：500-1000行/10-20文件/3-5模块
- 小变更：<500行/<10文件/<3模块

维度2：变更类型风险

高风险变更：
├─ 数据库变更：表结构/索引/数据迁移
├─ 核心逻辑变更：支付/认证/权限
├─ 配置变更：生产环境配置
├─ 依赖变更：第三方库/服务升级
└─ 架构变更：服务拆分/合并

中风险变更：
├─ 业务规则变更：计算逻辑/流程
├─ 接口变更：入参/出参/协议
├─ UI变更：页面/交互/样式
└─ 性能优化：缓存/异步/并发

低风险变更：
├─ Bug修复：不影响主流程
├─ 文案修改：提示信息/文档
├─ 日志调整：日志级别/格式
└─ 测试相关：测试代码/配置

维度3：业务影响评估

影响范围：
├─ 用户影响：影响多少用户
├─ 功能影响：影响哪些功能
├─ 收入影响：是否影响交易
├─ 声誉影响：是否影响品牌形象
└─ 合规影响：是否影响合规要求

影响等级：
- 高影响：核心功能/大量用户/收入相关
- 中影响：次要功能/部分用户
- 低影响：边缘功能/少量用户

灰度策略设计

📌 本节与 qa-shift-right「阶段1：灰度发布」内容同步，修改时请同步更新两处。

灰度维度

灰度策略：
├─ 用户灰度：按用户ID/比例
│   ├─ 内部员工 → 白名单用户 → 10% → 50% → 100%
│   └─ 适用：新功能/高风险功能
│
├─ 流量灰度：按流量比例
│   ├─ 1% → 10% → 30% → 50% → 100%
│   └─ 适用：性能优化/算法变更
│
├─ 地域灰度：按地域
│   ├─ 某城市 → 某省份 → 全国
│   └─ 适用：地域性功能
│
└─ 时间灰度：按时间段
    ├─ 低峰期 → 高峰期
    └─ 适用：定时任务/批处理

灰度监控指标

监控指标：
├─ 业务指标：
│   ├─ 订单量/交易量
│   ├─ 转化率/成功率
│   └─ 用户活跃度
│
├─ 技术指标：
│   ├─ 错误率/异常率
│   ├─ 响应时间/吞吐量
│   └─ 资源使用率
│
└─ 用户反馈：
    ├─ 投诉量
    ├─ 客服咨询量
    └─ 社交媒体反馈

灰度回滚条件

回滚触发条件：
├─ 业务指标异常：
│   ├─ 订单量下降 > 20%
│   ├─ 成功率下降 > 5%
│   └─ 用户投诉增加 > 50%
│
├─ 技术指标异常：
│   ├─ 错误率 > 1%
│   ├─ 响应时间增加 > 50%
│   └─ CPU/内存使用率 > 80%
│
└─ 用户反馈异常：
    ├─ 投诉量激增
    └─ 负面舆情

回滚方案设计

回滚类型

回滚方式：
├─ 代码回滚：回滚代码版本
│   ├─ 适用：代码变更导致的问题
│   ├─ 步骤：git revert → 部署 → 验证
│   └─ 风险：可能影响数据兼容性
│
├─ 配置回滚：回滚配置
│   ├─ 适用：配置变更导致的问题
│   ├─ 步骤：恢复配置 → 重启服务
│   └─ 风险：配置丢失
│
├─ 数据回滚：回滚数据
│   ├─ 适用：数据变更导致的问题
│   ├─ 步骤：数据备份恢复 → 验证
│   └─ 风险：数据丢失
│
└─ 服务回滚：回滚服务版本
    ├─ 适用：服务升级导致的问题
    ├─ 步骤：部署旧版本 → 验证
    └─ 风险：版本兼容性

回滚检查清单

回滚前检查：
├─ [ ] 回滚方案确认
├─ [ ] 回滚权限准备
├─ [ ] 数据备份完成
├─ [ ] 相关方通知
└─ [ ] 回滚时间窗口

回滚执行：
├─ [ ] 执行回滚操作
├─ [ ] 验证服务状态
├─ [ ] 验证业务功能
├─ [ ] 验证数据一致性
└─ [ ] 监控系统指标

回滚后处理：
├─ [ ] 通知相关方
├─ [ ] 记录回滚原因
├─ [ ] 分析问题根因
├─ [ ] 制定修复方案
└─ [ ] 安排重新发布

线上验证方案

验证内容

验证清单：
├─ 功能验证：
│   ├─ 核心功能是否正常
│   ├─ 新功能是否生效
│   └─ 兼容功能是否正常
│
├─ 性能验证：
│   ├─ 响应时间是否正常
│   ├─ 吞吐量是否正常
│   └─ 资源使用是否正常
│
├─ 数据验证：
│   ├─ 数据写入是否正常
│   ├─ 数据读取是否正常
│   └─ 数据一致性是否正常
│
└─ 监控验证：
    ├─ 监控指标是否正常
    ├─ 告警是否正常
    └─ 日志是否正常

发布检查清单

发布前

• [ ] 代码Review通过
• [ ] 测试用例通过
• [ ] 性能测试通过
• [ ] 安全扫描通过
• [ ] 回滚方案就绪
• [ ] 灰度策略确认
• [ ] 监控告警配置
• [ ] 相关方通知

发布中

• [ ] 灰度发布执行
• [ ] 监控指标观察
• [ ] 异常情况处理
• [ ] 全量发布确认

发布后

• [ ] 线上验证通过
• [ ] 监控指标正常
• [ ] 用户反馈正常
• [ ] 发布记录归档

输出示例

用户说"这次发布风险大不大" → 风险评估矩阵逐维分析：

• 变更特征：变更20个文件，涉及支付核心模块（高风险）
• 变更类型：功能变更+数据库变更（高风险）
• 业务影响：支付失败=用户无法下单（严重） → 输出发布决策建议：灰度发布5%用户，监控24小时，准备回滚方案

发布前Checklist → 发布前：代码冻结检查，测试报告确认，变更审批 → 发布中：灰度发布，监控指标 → 发布后：线上验证，用户反馈收集

检查清单

发布风险管理完成后检查：

• [ ] 变更特征是否分析？
• [ ] 业务影响是否评估？
• [ ] 灰度策略是否设计？
• [ ] 回滚方案是否准备？
• [ ] 线上验证是否规划？
• [ ] 监控告警是否配置？