Architecture Risk Assessment

SKILL.md

# Skill 3：架构风险评估

## 功能概述

对架构设计方案进行系统性风险评估，识别性能瓶颈、单点故障、扩展性瓶颈和安全漏洞，输出量化的风险矩阵和缓解方案。

## 输入与输出

| 项目 | 内容 |
|------|------|
| **输入** | 架构设计方案（来自Skill 2） |
| **输出** | 风险评估报告（含风险矩阵、缓解方案、残余风险） |

## 执行流程

### Step 1：风险维度识别

从以下4个维度系统性评估架构风险：

| 维度 | 评估项 | 典型问题 |
|------|--------|---------|
| **性能瓶颈** | 并发能力、响应时间、资源消耗 | 数据库连接池是否足够？缓存是否命中率高？是否有热点数据？ |
| **单点故障** | 可用性、故障转移、灾备 | 是否有单一节点/服务不可替代？是否有冗余备份？故障切换机制？ |
| **扩展性瓶颈** | 水平扩展、垂直扩展、数据扩展 | 数据库分片方案？服务无状态化？消息队列积压能力？ |
| **安全漏洞** | 认证授权、数据安全、API安全 | API是否有速率限制？敏感数据加密？SQL注入/XSS防护？ |

### Step 2：风险识别方法

针对架构方案中的每个模块和组件，逐一检查：

**检查清单**：

#### 2.1 性能瓶颈检查
- [ ] 是否有单数据库实例承担所有读写？
- [ ] 缓存策略是否合理（穿透/击穿/雪崩防护）？
- [ ] 是否有CPU密集操作未做异步处理？
- [ ] 是否有大量数据未分页直接传输？
- [ ] 外部API调用是否有超时和熔断机制？

#### 2.2 单点故障检查
- [ ] 关键服务是否有至少2个副本？
- [ ] 数据库是否有主从/集群部署？
- [ ] 是否有统一的配置中心？
- [ ] 网关是否有双活或多活部署？
- [ ] 是否有全局唯一ID生成器的降级方案？

#### 2.3 扩展性瓶颈检查
- [ ] 服务是否可独立水平扩展？
- [ ] 数据层是否支持分库分表？
- [ ] 文件存储是否有容量上限？
- [ ] 是否有服务间循环依赖？
- [ ] 消息队列是否支持消费者水平扩展？

#### 2.4 安全漏洞检查
- [ ] 认证token是否防止重放攻击？
- [ ] 接口是否做了速率限制？
- [ ] 用户输入是否做了防注入处理？
- [ ] 敏感数据是否加密存储/传输？
- [ ] 审计日志是否完整覆盖关键操作？

### Step 3：风险量化评估

对每个识别的风险，按以下公式量化：

**风险等级 = 发生概率 × 影响程度**

#### 概率分级

| 等级 | 描述 | 赋值 |
|------|------|------|
| 低 | 特定条件下可能发生 | 1 |
| 中 | 正常条件下可能发生 | 2 |
| 高 | 大概率会发生 | 3 |

#### 影响程度分级

| 等级 | 描述 | 赋值 |
|------|------|------|
| 低 | 性能轻微下降，不影响可用性 | 1 |
| 中 | 部分功能不可用，影响用户体验 | 2 |
| 高 | 系统不可用/数据丢失/安全事件 | 3 |

### Step 4：生成风险矩阵

```markdown
### 风险矩阵

| 风险ID | 风险描述 | 所属模块 | 类型 | 概率(P) | 影响(I) | 风险等级(P×I) | 缓解方案 |
|--------|---------|---------|------|---------|---------|--------------|---------|
| R-001 | 单数据库实例读写 | 数据层 | 单点故障 | 3 | 3 | 9 (极高) | 启用读写分离+主从切换 |
| R-002 | ... | ... | ... | ... | ... | ... | ... |
```

#### 风险等级分类

| 等级 | 分值范围 | 应对策略 |
|------|---------|---------|
| 🔴 极高 | 7-9 | 必须缓解，否则方案不可接受 |
| 🟡 高 | 4-6 | 强烈建议缓解 |
| 🟢 中 | 2-3 | 可接受，但建议关注 |
| ⚪ 低 | 1 | 可接受，持续监控 |

### Step 5：缓解方案设计

对于每个高等及以上风险，给出详细的缓解方案：

```markdown
### R-001：单数据库实例读写

| 属性 | 内容 |
|------|------|
| **风险等级** | 🔴 极高 (9) |
| **缓解方案** | 读写分离 + 主从切换 |
| **方案详述** | 部署1主2从MySQL集群，写操作路由到主库，读操作路由到从库。使用ProxySQL或HAProxy做自动读写分离和故障切换。 |
| **实施成本** | 中（增加1-2台数据库服务器和Proxy层） |
| **残余风险** | 主库单点仍然存在，但RTO缩短到30秒内 |
| **替代方案** | 使用分布式数据库（如TiDB）彻底消除单点 |
```

### Step 6：输出风险评估报告

```markdown
# 架构风险评估报告

## 1. 评估概述
[简要描述评估范围和主要发现]

## 2. 风险矩阵总览
| 风险ID | 描述 | 类型 | 等级 | 状态 |
|--------|------|------|------|------|
| ... | ... | ... | ... | ... |

## 3. 关键风险详述
[详细描述每个高等级风险和缓解方案]

## 4. 风险分布统计
- 性能瓶颈：X个
- 单点故障：X个
- 扩展性瓶颈：X个
- 安全漏洞：X个
- 合计：X个

## 5. 未缓解的残余风险
[标注哪些风险的残余风险仍然存在]

## 6. 架构改进建议
[基于风险评估的架构优化建议]
```

## 质量检查清单

- [ ] 是否覆盖了4个风险维度（性能/单点/扩展/安全）？
- [ ] 风险矩阵是否量化（概率×影响）？
- [ ] 所有高等级风险是否都有缓解方案？
- [ ] 是否标注了残余风险？
- [ ] 是否有基于风险评估的架构改进建议？