qa-release-risk-governance

SKILL.md

---
name: qa-release-risk-governance
description: >-
  当版本要发布了、需要决定"能不能发"、或者需要设计灰度/回滚方案时使用此技能。系统化评估变更风险（变更范围/影响面/回退成本），设计灰度发布策略（按用户/区域/流量比例），制定回滚方案和线上监控计划。不要问"这个版本稳不稳"——要问"如果出问题了，我们能在几分钟内发现并回滚"。产出发布风险评估报告和灰度发布方案。 触发场景：发布风险、灰度策略、回滚方案、风险评估、版本发布、紧急发布、大版本发布前风险评估时。 Use when the user asks about: release readiness assessment — canary rollout, rollback planning, release risk evaluation, and production monitoring thresholds.
license: MIT
allowed-tools: Read Grep Glob
metadata:
  display-name: "Release Risk Governance"
  version: "1.8.0"
  when-to-use: "用户说\"发布风险\"、\"灰度策略\"、\"回滚方案\"、\"风险评估\"、\"版本发布\"、\"紧急发布\"、需要评估发布风险、大版本发布前风险评估时"
  related-skills: "{\"upstream\":[\"qa-test-strategy-design\",\"qa-risk-intuition\"],\"downstream\":[\"qa-quality-metrics\",\"qa-shift-right\",\"qa-stakeholder-communication\"]}"
  references: "[\"references/canary-rollout.md\"]"
  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\":\"上线监控建议\"}]}"
  error-recovery-guidance: "{\"on_failure\":\"发布评估发现阻塞性问题时回退到测试策略补齐\",\"retry_behavior\":\"修复阻塞问题后重新评估发布\"}"
  categories: "[\"Development\",\"Testing\",\"DevOps\"]"
  depth-requirement: "{\"reference_value\":\"根据发布规模调整评估深度：简单×1/中等×2/复杂×3\",\"minimum\":\"至少覆盖变更风险、灰度策略、回滚方案、监控计划4项\"}"
---
> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

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

# 发布风险管理

## 核心原则

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

## 发布风险评估矩阵

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

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

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

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

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

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

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

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

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

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

## 加载时机

| 什么时候读 | 读哪个 |
|-----------|--------|
| 设计灰度放量阶梯与回滚阈值时 | [`references/canary-rollout.md`](references/canary-rollout.md) |

> `灰度策略设计`的完整内容已下沉至 `references/canary-rollout.md`，避免每次触发都占用上下文。

## 回滚方案设计

### 回滚类型

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

### 回滚检查清单

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

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

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

## 线上验证方案

### 验证内容

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

## 发布检查清单

### 发布前

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

### 发布中

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

### 发布后

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

## 输出示例

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

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

## 检查清单

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