Qa Release Risk Governance

SKILL.md

---
name: qa-release-risk-governance
version: 1.6.0
description: >-
  当版本要发布了、需要决定"能不能发"、或者需要设计灰度/回滚方案时使用此技能。系统化评估变更风险（变更范围/影响面/回退成本），设计灰度发布策略（按用户/区域/流量比例），制定回滚方案和线上监控计划。不要问"这个版本稳不稳"——要问"如果出问题了，我们能在几分钟内发现并回滚"。产出发布风险评估报告和灰度发布方案。

when_to_use: 用户说"发布风险"、"灰度策略"、"回滚方案"、"风险评估"、"版本发布"、"紧急发布"、需要评估发布风险、大版本发布前风险评估时
allowed-tools: Read Grep Glob
related_skills:
  upstream:
    - qa-test-strategy-design    # 输入：测试策略
    - qa-risk-intuition          # 输入：风险评估
  downstream:
    - qa-quality-metrics         # 输出：发布数据用于质量度量
    - qa-shift-right
    - qa-stakeholder-communication
input_format:
  required:
    - name: 测试策略
      type: object
      description: 来自qa-test-strategy-design的测试策略
    - name: 风险评估
      type: object
      description: 来自qa-risk-intuition的风险评估
    - name: 发布计划
      type: string
      description: 发布时间线和范围
  optional:
    - name: 质量度量
      type: object
      description: 来自qa-quality-metrics的质量数据
output_format:
  traceability:
    - 每次发布评估带唯一ID（REL-XXXX）
  structure:
    - release_decision: 发布决策建议
    - risk_summary: 风险摘要
    - blocking_issues: 阻塞性问题清单
    - rollback_plan: 回滚方案
    - monitoring_recommendations: 上线监控建议
categories: ['Development','Testing','DevOps']
depth_requirement_quantification:
  reference_value: "根据发布规模调整评估深度：简单×1/中等×2/复杂×3"
  minimum: "至少覆盖变更风险、灰度策略、回滚方案、监控计划4项"
error_recovery_guidance:
  on_failure: "发布评估发现阻塞性问题时回退到测试策略补齐"
  retry_behavior: "修复阻塞问题后重新评估发布"
---
> **⚠️ 安全警告**：本技能的示例可能涉及发布决策、灰度方案和回滚操作。
> 实际使用时请勿直接执行发布或回滚，先确认审批权限、灰度比例和回滚预案。
> 本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

# 发布风险管理

## 核心原则

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

## 发布风险评估矩阵

### 维度1：变更特征分析

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

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

### 维度2：变更类型风险

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

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

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

### 维度3：业务影响评估

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

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

## 灰度策略设计

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

### 灰度维度

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

### 灰度监控指标

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

### 灰度回滚条件

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

## 回滚方案设计

### 回滚类型

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

### 回滚检查清单

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

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

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

## 线上验证方案

### 验证内容

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

## 发布检查清单

### 发布前

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

### 发布中

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

### 发布后

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

## 输出示例

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

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

## 检查清单

发布风险管理完成后检查：
- [ ] 变更特征是否分析？
- [ ] 业务影响是否评估？
- [ ] 灰度策略是否设计？
- [ ] 回滚方案是否准备？
- [ ] 线上验证是否规划？
- [ ] 监控告警是否配置？