<!-- 由 BMAD™ Core 驱动 -->

# 风险概况

使用概率×影响分析，为故事实施生成全面的风险评估矩阵。

## 输入

```yaml
required:
  - story_id: '{epic}.{story}' # 例如, "1.3"
  - story_path: 'docs/stories/{epic}.{story}.*.md'
  - story_title: '{title}' # 如果缺少，则从故事文件的H1派生
  - story_slug: '{slug}' # 如果缺少，则从标题派生（小写，连字符连接）
```

## 目的

识别、评估和优先处理故事实施中的风险。根据风险级别提供风险缓解策略和测试重点领域。

## 风险评估框架

### 风险类别

**类别前缀：**

-   `TECH`: 技术风险
-   `SEC`: 安全风险
-   `PERF`: 性能风险
-   `DATA`: 数据风险
-   `BUS`: 业务风险
-   `OPS`: 运营风险

1.  **技术风险 (TECH)**
    -   架构复杂性
    -   集成挑战
    -   技术债务
    -   可扩展性问题
    -   系统依赖

2.  **安全风险 (SEC)**
    -   认证/授权缺陷
    -   数据泄露漏洞
    -   注入攻击
    -   会话管理问题
    -   加密弱点

3.  **性能风险 (PERF)**
    -   响应时间下降
    -   吞吐量瓶颈
    -   资源耗尽
    -   数据库查询优化
    -   缓存失败

4.  **数据风险 (DATA)**
    -   数据丢失的可能性
    -   数据损坏
    -   侵犯隐私
    -   合规性问题
    -   备份/恢复差距

5.  **业务风险 (BUS)**
    -   功能不符合用户需求
    -   收入影响
    -   声誉损害
    -   法规不合规
    -   市场时机

6.  **运营风险 (OPS)**
    -   部署失败
    -   监控差距
    -   事件响应准备情况
    -   文档不足
    -   知识转移问题

## 风险分析流程

### 1. 风险识别

为每个类别识别具体风险：

```yaml
risk:
  id: 'SEC-001' # 使用前缀：SEC, PERF, DATA, BUS, OPS, TECH
  category: security
  title: '用户表单输入验证不足'
  description: '表单输入未正确清理可能导致XSS攻击'
  affected_components:
    - 'UserRegistrationForm'
    - 'ProfileUpdateForm'
  detection_method: '代码审查发现缺少验证'
```

### 2. 风险评估

使用概率×影响评估每个风险：

**概率级别：**

-   `高 (3)`: 很可能发生 (>70%的几率)
-   `中 (2)`: 可能发生 (30-70%的几率)
-   `低 (1)`: 不太可能发生 (<30%的几率)

**影响级别：**

-   `高 (3)`: 严重后果（数据泄露、系统宕机、重大财务损失）
-   `中 (2)`: 中等后果（性能下降、轻微数据问题）
-   `低 (1)`: 轻微后果（外观问题、轻微不便）

### 风险评分 = 概率 × 影响

-   9: 严重风险 (红色)
-   6: 高风险 (橙色)
-   4: 中风险 (黄色)
-   2-3: 低风险 (绿色)
-   1: 极小风险 (蓝色)

### 3. 风险优先级排序

创建风险矩阵：

```markdown
## 风险矩阵

| 风险ID | 描述 | 概率 | 影响 | 评分 | 优先级 |
| --- | --- | --- | --- | --- | --- |
| SEC-001 | XSS漏洞 | 高 (3) | 高 (3) | 9 | 严重 |
| PERF-001 | 仪表板查询缓慢 | 中 (2) | 中 (2) | 4 | 中 |
| DATA-001 | 备份失败 | 低 (1) | 高 (3) | 3 | 低 |
```

### 4. 风险缓解策略

为每个已识别的风险提供缓解措施：

```yaml
mitigation:
  risk_id: 'SEC-001'
  strategy: '预防性' # 预防性|检测性|纠正性
  actions:
    - '实施输入验证库（例如，validator.js）'
    - '添加CSP头以防止XSS执行'
    - '在存储前清理所有用户输入'
    - '在模板中对所有输出进行转义'
  testing_requirements:
    - '使用OWASP ZAP进行安全测试'
    - '对表单进行手动渗透测试'
    - '验证函数的单元测试'
  residual_risk: '低 - 可能仍存在一些零日漏洞'
  owner: 'dev'
  timeline: '部署前'
```

## 输出

### 输出1：门禁YAML块

生成用于粘贴到门禁文件的`risk_summary`下的内容：

**输出规则：**

-   仅包括评估的风险；不要输出占位符
-   在输出最高风险和任何表格列表时，按分数（降序）对风险进行排序
-   如果没有风险：总数全为零，省略最高风险，保持建议数组为空

```yaml
# risk_summary（粘贴到门禁文件）：
risk_summary:
  totals:
    critical: X # 评分 9
    high: Y # 评分 6
    medium: Z # 评分 4
    low: W # 评分 2-3
  highest:
    id: SEC-001
    score: 9
    title: '个人资料表单上的XSS'
  recommendations:
    must_fix:
      - '添加入口清理和CSP'
    monitor:
      - '为认证端点添加安全警报'
```

### 输出2：Markdown报告

**保存到：** `qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`

```markdown
# 风险概况：故事 {epic}.{story}

日期：{date}
审查员：Quinn（测试架构师）

## 执行摘要

-   已识别风险总数：X
-   严重风险：Y
-   高风险：Z
-   风险评分：XX/100（已计算）

## 需要立即关注的严重风险

### 1. [ID]：风险标题

**评分：9（严重）**
**概率**：高 - 详细理由
**影响**：高 - 潜在后果
**缓解**：

-   需要立即采取行动
-   要采取的具体步骤
  **测试重点**：需要的具体测试场景

## 风险分布

### 按类别

-   安全性：X个风险（Y个严重）
-   性能：X个风险（Y个严重）
-   数据：X个风险（Y个严重）
-   业务：X个风险（Y个严重）
-   运营：X个风险（Y个严重）

### 按组件

-   前端：X个风险
-   后端：X个风险
-   数据库：X个风险
-   基础设施：X个风险

## 详细风险登记册

[包含所有风险、评分和缓解措施的完整表格]

## 基于风险的测试策略

### 优先级1：严重风险测试

-   严重风险的测试场景
-   所需的测试类型（安全、负载、混沌）
-   测试数据要求

### 优先级2：高风险测试

-   集成测试场景
-   边缘情况覆盖

### 优先级3：中/低风险测试

-   标准功能测试
-   回归测试套件

## 风险接受标准

### 生产前必须修复

-   所有严重风险（评分9）
-   影响安全/数据的高风险

### 可以在有缓解措施的情况下部署

-   有补偿控制的中等风险
-   有监控的低风险

### 已接受的风险

-   记录团队接受的任何风险
-   包括适当授权的签字

## 监控要求

部署后监控：

-   PERF风险的性能指标
-   SEC风险的安全警报
-   运营风险的错误率
-   业务风险的业务KPI

## 风险审查触发器

在以下情况下审查和更新风险概况：

-   架构发生重大变化
-   添加了新的集成
-   发现了安全漏洞
-   报告了性能问题
-   法规要求变更
```

## 风险评分算法

计算总体故事风险评分：

```text
基础分 = 100
对于每个风险：
  - 严重 (9)：扣20分
  - 高 (6)：扣10分
  - 中 (4)：扣5分
  - 低 (2-3)：扣2分

最低分 = 0（极度危险）
最高分 = 100（风险极小）
```

## 基于风险的建议

根据风险概况，建议：

1.  **测试优先级**
    -   首先运行哪些测试
    -   需要哪些额外的测试类型
    -   测试环境要求

2.  **开发重点**
    -   代码审查重点领域
    -   需要额外的验证
    -   要实施的安全控制

3.  **部署策略**
    -   对高风险更改进行分阶段推出
    -   对有风险的功能使用功能标志
    -   回滚程序

4.  **监控设置**
    -   要跟踪的指标
    -   要配置的警报
    -   仪表板要求

## 与质量门的集成

**确定性门映射：**

-   任何风险评分≥9 → 门 = 失败（除非豁免）
-   否则，如果任何评分≥6 → 门 = 关注
-   否则 → 门 = 通过
-   未缓解的风险 → 在门中记录

### 输出3：故事钩子行

**打印此行以供审查任务引用：**

```text
风险概况：qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
```

## 关键原则

-   尽早并系统地识别风险
-   使用一致的概率×影响评分
-   提供可操作的缓解策略
-   将风险与具体的测试要求联系起来
-   跟踪缓解后的剩余风险
-   随着故事的发展更新风险概况