agentleFS
KokxiKokxi/qa-test-skills/skills/qa-release-risk-governance/SKILL.md

qa-release-risk-governance

Skill31 starsChanged 48 days agoMITView on GitHub

当版本要发布了、需要决定"能不能发"、或者需要设计灰度/回滚方案时使用此技能。系统化评估变更风险(变更范围/影响面/回退成本),设计灰度发布策略(按用户/区域/流量比例),制定回滚方案和线上监控计划。不要问"这个版本稳不稳"——要问"如果出问题了,我们能在几分钟内发现并回滚"。产出发布风险评估报告和灰度发布方案。 触发场景:发布风险、灰度策略、回滚方案、风险评估、版本发布、紧急发布、大版本发布前风险评估时。 Use when the user asks about: release readiness assessment — canary rollout, rollback planning, release risk evaluation, and production monitoring thresholds.

The file

Files
SKILL.md

⚠️ 本技能单独使用效果有限,建议配合完整技能集(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:业务影响评估

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

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

加载时机

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

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

回滚方案设计

回滚类型

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

回滚检查清单

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

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

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

线上验证方案

验证内容

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

发布检查清单

发布前

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

发布中

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

发布后

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

输出示例

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

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

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

检查清单

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

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.